Website Migration SEO Checklist: Before, During, and After Launch

Moving from Squarespace to WordPress, rebuilding WordPress in Webflow, or replacing WordPress with a custom site can change more than the design. URLs can move, page templates can lose metadata, internal links can disappear, and forms or tracking can stop working.

This checklist covers what to check before the new site goes live, when you switch it over, and after Google starts visiting it. It applies to platform changes, redesigns, URL restructures, domain moves, and custom frontends.

The main question is not which platform you are leaving. It is what changes during the move: the URLs, the content, the domain, the way pages are rendered, or all of them.

No checklist can guarantee unchanged rankings or traffic. It can help you avoid the common mistakes that make an established site harder for visitors and search engines to understand.

Start by figuring out what is actually changing

Most website moves fit one or more of these situations.

The platform is changing, but the URLs stay the same

This is usually lower risk than changing the URL structure, but it is not risk-free. The new platform still needs to preserve the page content, headings, metadata, canonicals, internal links, images, and indexability of the old site.

The URL structure is changing

This is where redirects become important. Every valuable old URL needs either the same URL, a direct redirect to the closest replacement, or a deliberate 404 or 410 when there is no relevant replacement.

The domain or subdomain is changing

This is a full site move. You need the old and new properties verified in Search Console, redirects between the domains, a new sitemap, and the correct Change of Address process where it applies.

The frontend or rendering system is changing

This includes moving from WordPress to Next.js or another custom frontend. The page may look correct in a browser while important content, links, metadata, or structured data are missing from the HTML delivered to crawlers. Routes, dynamic pages, pagination, canonicals, robots rules, and sitemap generation need to be handled deliberately.

If several of these changes are happening at once, write them down separately. A platform change, URL change, redesign, and content rewrite can all create different problems, even when they go live on the same day.

Keep the URLs that are already working

If an existing URL receives search impressions, organic visits, external links, or useful internal links, keeping that URL is usually safer than changing it for cosmetic reasons.

Do not change URLs simply because the new platform has a different preferred structure. A WordPress site does not need new slugs just because it is moving to Webflow. A redesign does not need a new /about path just because the page looks different.

Change a URL when there is a clear reason, such as a better content structure, a duplicate page, a retired service, or a move to a new domain. When you do change it, record the old and new paths before the new site is built.

Google recommends mapping current URLs to their new locations, updating internal links and sitemaps, and using permanent server-side redirects where possible. Google’s site-move guidance explains the process in detail.

Make a list of what exists before you rebuild

The main navigation is not a complete list of a website. Important URLs can live in old blog archives, sitemaps, search results, PDFs, image files, campaign pages, filtered directories, and links from other websites.

Before changing the current site, collect:

• The current sitemap and every URL in it.
• Pages and queries from Google Search Console.
• Organic landing pages and conversions from analytics.
• A CMS export of posts, pages, categories, authors, media, and custom content.
• Existing redirects.
• Important forms, downloads, images, and videos.
• Search, filtering, directories, archives, and other experiences that are not obvious from the navigation.
• High-value external links, where that information is available.

Combine these lists and remove duplicates. You do not need a perfect spreadsheet before starting. You do need enough information to avoid rebuilding only the pages that are visible in the menu.

For a smaller site, a simple spreadsheet is enough:

• Current URL
• New URL, if it will change
• Page purpose
• What happens to it
• Redirect destination, if needed
• Person checking the result

Record the current site before changing it

Save the current state while the old site is still available. This gives you something to compare after the new version goes live.

At minimum, save:

• Search Console clicks, impressions, queries, pages, and average positions.
• Analytics landing pages, organic conversions, and form completions.
• Current page titles, descriptions, headings, canonicals, and indexability.
• Status codes, internal links, and existing redirects.
• The current sitemap and its last-modified values.
• A basic performance check for important page types.

Use the longest useful comparison period available. A short snapshot can miss pages that receive occasional visits or search demand that changes with the season.

The goal is not to create a perfect report. It is to know which pages and actions mattered before the move, so you can tell whether the new site changed them.

Decide what happens to every important page

Every old page needs a decision before the new site replaces it.

Keep the page and URL

Use this when the page still serves the same purpose and the address already works.

Keep the page but move it to a new URL

Use this when the content remains useful but the site structure needs to change. Create the redirect before the new site goes live.

Combine it with another page

Use this when several pages answer the same question or the new site has one stronger replacement. Make sure the replacement actually covers the useful information from the old pages.

Replace it with a better page

Use this when the old page is thin, outdated, or no longer reflects what the business offers. Do not remove search-relevant information before deciding what will replace it.

Remove it without a replacement

Use a 404 or 410 when the page is genuinely gone and there is no relevant destination. Do not redirect every retired page to the homepage just to avoid seeing errors.

Keep the important parts of each page

A page can keep its URL and still lose search visibility if the new version changes too much of what made the page useful.

For important pages, compare the old and new versions for:

• The main heading and page purpose.
• The body content and important supporting details.
• The title tag and meta description.
• The canonical URL.
• Internal links to related pages.
• Images, captions, alt text, PDFs, and other assets.
• Structured data, where the page genuinely uses it.
• The response status and indexability.

Do not assume an import brought everything across. Open important old pages and their new versions side by side. Check the content, links, images, metadata, and downloadable files.

Make sure the new site still does the work the old site did

SEO is only one part of an established website. The new version also needs to support the tasks visitors and the business relied on before.

Check that:

• Forms reach the right inbox or system.
• Analytics records submissions and other important actions.
• Images, documents, and downloads still load.
• Internal links lead to the right pages.
• Search and filtering still return useful results.
• Related articles, authors, locations, or resources are still connected.
• Editors can still publish and update content.
• Login, gated content, payment, or account features still work if they apply.

A site can have the same page count after a move while losing the filters, forms, related content, or routing that made those pages useful.

Create and test redirects

For every URL that changes:

• Send the old URL directly to the closest relevant new page.
• Use a permanent redirect for a permanent move.
• Avoid redirect chains.
• Update internal links so they point directly to the new URL.
• Use a 404 or 410 when no relevant replacement exists.
• Test the old URL itself, not only the new destination.

For example:

The old URL should redirect directly to /website-rebuild. It should not go through another old path first, and it should not go to the homepage unless the homepage is genuinely the closest replacement.

Google recommends permanent redirects for moved URLs and warns against long redirect chains. Read the current Google redirect guidance.

Check the private version before making it public

Most platforms give you a private or preview version of the new site. Use it to find problems before visitors and search engines see the new pages.

Check the new site on more than the homepage:

• A normal page.
• A blog post or article.
• A category, author, location, or archive page if the site uses them.
• A page with a form.
• A page with images, downloads, or embedded content.
• A page that depends on search, filtering, or dynamic data.

For each example, check:

• The content is present.
• The heading and page purpose are still clear.
• The title, description, and canonical are correct.
• Internal links work.
• Images and files load.
• The page is not accidentally blocked by a password, noindex, or robots rule.
• The page works on a phone.
• Important forms, search, and integrations work.

If the new site is a custom frontend, also check that important content, links, metadata, and structured data are present in the rendered HTML rather than appearing only after browser JavaScript runs.

When the new site goes live

The exact order depends on the platform, but the essential checks are the same:

1. Save the final list of old URLs.
2. Publish the new site on the intended domain.
3. Activate the redirects.
4. Remove password and noindex restrictions that were only needed for the private version.
5. Confirm canonicals, robots rules, and sitemap URLs.
6. Test important old URLs and their new destinations.
7. Submit forms and confirm that routing and notifications work.
8. Check analytics and conversion tracking.
9. Submit the new sitemap in Search Console.
10. Inspect several important new URLs in Search Console.

If the domain or subdomain changed, verify both properties and use Change of Address in Search Console where it applies. Change of Address is not needed for a CMS change, an HTTPS move, or a path change within the same domain.

Check what changed after the switch

Compare the old and new site by page, query, and important business action. A change in traffic is a signal to investigate, not an explanation by itself.

Old URLs return 404 errors

Check whether they were included in the URL list and whether each one has the right redirect or intentional removal decision.

New pages are not being indexed

Check noindex, robots rules, canonicals, sitemap inclusion, response codes, and whether the important content is available in the rendered page.

Impressions fall

Compare the affected pages and queries in Search Console. Check whether the page content, title, internal links, URL, or search intent changed.

Impressions remain but clicks fall

Review the title, description, visible page purpose, and whether the new result still matches what the searcher expected.

Organic traffic remains but leads fall

Test forms, analytics events, routing, thank-you pages, CRM connections, and other conversion paths.

Pages load but navigation is broken

Check internal links, templates, breadcrumbs, category paths, search, filters, and dynamic routes.

Google recommends using Search Console pages and queries, indexing reports, and URL Inspection when investigating traffic changes. Read Google’s traffic-drop guidance.

There is no fixed number of days after which a migration is automatically finished. Keep comparing the important old and new URLs while Google recrawls the site and while the new pages, queries, and forms are being checked.

You can also read why organic traffic drops and what to check when website traffic drops after a redesign.

Common ways website moves go wrong

• Changing URLs because the new platform uses different defaults.
• Rebuilding only the pages visible in the main navigation.
• Assuming a CMS import moved all media, metadata, and relationships.
• Changing the page copy, headings, URLs, and templates at the same time without recording the old version.
• Redirecting unrelated old pages to the homepage.
• Leaving a private-site password or noindex rule active after the switch.
• Forgetting image, document, or downloadable-file URLs.
• Losing forms, analytics, search, filters, or lead routing.
• Testing only the homepage and a few manually chosen pages.
• Deleting the old site before the new routes and redirects have been checked.
• Assuming a stable ranking or traffic level is guaranteed after the move.

The safest migrations are not necessarily the ones with the newest platform. They are the ones where the owner knows what is changing and checks the pages, paths, and workflows that already matter.

If your site has more moving parts

The checklist above is enough for many small and medium website moves. Add more planning if the site includes membership, account areas, a large archive, a course or resource catalog, multiple locations, search and filtering, gated content, payment, or several connected systems.

In those cases, make a separate list of the content, routes, permissions, forms, data relationships, and integrations that need to survive. Do not let a successful page import stand in for a working website.

For a move that is specifically changing the CMS, continue with the CMS migration checklist. Platform-specific guides for common moves should answer their own questions rather than making this general checklist longer.