Website migration SEO checklist: how to change platforms, URLs or domains without losing search traffic

What counts as a migration

Search engines treat any significant change to how a site is addressed or built as something to reprocess. That includes:

• A new platform or CMS, even when the design looks the same.
• Changed URLs, including a new folder structure or dropped file extensions.
• A new domain, a merger of two sites, or a move from a subdomain to a folder.
• A switch to HTTPS, or a change in whether the site uses www.
• Adding a language version, or restructuring an existing bilingual site.
• A redesign that removes, merges or substantially rewrites pages that currently rank.

Each of these breaks the link between what search engines have indexed and what now exists. The checklist below is how you rebuild that link deliberately instead of hoping it rebuilds itself.

This is not the same job as a technical audit. Our technical SEO audit checklist covers the ongoing health of a site that is staying put. A migration checklist is about a single change event, and it is time-boxed: most of the work happens in the weeks either side of launch.

Before you start: inventory and baselines

You cannot protect what you have not listed. Build a complete inventory of current URLs from several sources, because no single one is complete:

• A crawl of the current site.
• The current XML sitemap.
• Landing pages from your analytics over at least the last year (longer for seasonal businesses, so you capture the peak).
• Pages with impressions or clicks in Google Search Console.
• Pages that other sites link to, from whatever backlink tool you use.
• PDFs, images and other files that receive traffic or links.

Then capture baselines you will compare against after launch: organic sessions and conversions by landing page, the queries and positions for your most important pages, the number of indexed pages, and Core Web Vitals. Export them. You will not be able to pull pre-launch data from a site that no longer exists. If Search Console is not something your team uses regularly, our Google Search Console masterclass covers the reports you need.

Finally, rank the URLs by value. A short list of pages typically carries most of the organic traffic, conversions and links. Those pages get the most care through the migration: content preserved, URLs kept if possible, and individual checks after launch.

URL mapping and redirects

The redirect map is the heart of the migration. It is a spreadsheet with two columns, old URL and new URL, covering every URL in the inventory.

Rules for a good map

1. Keep URLs where you can. The safest redirect is the one you do not need. If the new platform can preserve a valuable URL, preserve it.
2. Map one to one, to the closest equivalent. An old service page goes to the new service page on the same topic, not to the homepage. Redirecting everything to the homepage is treated much like removing the pages.
3. Use permanent redirects. A 301 (or 308) tells search engines the move is permanent and they should transfer their understanding of the old page to the new one. Temporary redirects send a different signal.
4. Avoid chains. If an old URL already redirects somewhere, point it straight to the final destination. Chains slow crawling and lose clarity at each hop.
5. Retire deliberately. For pages with no equivalent and no value, a redirect to the closest relevant parent page is usually better than a 404. Pages that are genuinely gone with no relevant destination can return a 404 or 410.
6. Cover the variants. HTTP and HTTPS, www and non-www, trailing slashes and old file extensions should all resolve to a single version of each URL.

Test the map before launch on staging, and again on production immediately after. A crawler fed the list of old URLs should return a single redirect to a page that loads, for every row.

Keep the redirects in place for the long term. Old links in emails, PDFs, directories and other sites will keep arriving for years.

Canonicals, metadata and structured data

Redirects tell search engines where a page moved. The on-page signals tell them it is still the same page. Carry these across for every page that matters:

• Title tags and meta descriptions. New platforms often generate defaults. Do not let a template overwrite titles that were earning clicks.
• Headings and body content. Substantially rewriting a high-value page during a migration makes it harder to tell whether a ranking change came from the move or the rewrite. Where you can, migrate first and rewrite later.
• Canonical tags. Each page should carry a canonical pointing to its own final, absolute URL on the new site. A common launch bug is canonicals still pointing to the staging domain or to the old URLs.
• Hreflang. On bilingual sites, every page should reference itself and its counterpart at their new addresses, reciprocally. See bilingual website planning for Atlantic Canada for the setup.
• Structured data. Organization, local business, article, FAQ, product or event markup on the old site should exist on the new one, validated and with updated URLs. It matters for rich results and for how AI systems understand your organization; structured data and AI citations explains why.
• Image alt text and file names for images that bring in traffic.

Staging controls and launch day

Staging sites leak. A search engine finds a link to the staging domain, indexes it, and you end up with a duplicate copy of your new site competing with the real one before it even launches.

Protecting staging

• Put staging behind authentication (a password or an IP allowlist). This is the reliable control.
• A noindex directive or a robots.txt block can be added as a backup, but on its own a robots.txt block does not reliably keep a URL out of the index.
• Do not link to staging from anywhere public, including shared documents that may be indexed.

Launch day checklist

1. Remove staging blocks from production: no site-wide noindex, no robots.txt that disallows everything. This single mistake causes more migration disasters than any other.
2. Deploy the redirect map and test a sample of the highest-value URLs by hand.
3. Update internal links to point directly at the new URLs, not through redirects.
4. Publish a new XML sitemap containing only live, canonical, indexable URLs, reference it in robots.txt, and submit it in Search Console.
5. If the domain changed, verify the new property in Search Console and use its change of address process.
6. Confirm analytics and conversion tracking are firing on the new site, and that forms submit end to end.
7. Update the URLs you control elsewhere: Google Business Profile, social profiles, directory listings, email signatures and ad destinations.

Launch early in the week, outside your busiest season, with the people who can fix things available for the following days. A Friday afternoon launch before a long weekend is a choice you will regret.

Post-launch monitoring

Expect some movement. Search engines need time to recrawl the site, follow the redirects and reassess pages, and rankings commonly fluctuate during that period. The job is to tell normal fluctuation from real damage, and fix the damage quickly.

First days

• Crawl the old URL list again and confirm every redirect still resolves correctly.
• Watch server logs or a monitoring tool for 404 errors and redirect the ones that matter.
• Check Search Console for crawl errors and for pages unexpectedly marked as excluded or blocked.
• Spot-check the top pages in search results to see the new URLs appearing.

First weeks and months

• Compare organic sessions and conversions by landing page against the baseline, using the same period last year for seasonal businesses.
• Track positions for the queries tied to your highest-value pages.
• Watch indexing in Search Console as old URLs drop out and new ones are picked up.
• Confirm structured data and rich results have carried across.

If a valuable page loses visibility and does not recover, check the basics in order: does the old URL redirect to the right page, is the new page indexable, is the canonical correct, and did the content change materially? Most problems sit in one of those four places. If conversions dropped but traffic held, the problem is probably on the page or in tracking, not in search; how to diagnose a drop in website conversions covers that path.

Who owns the checklist

The single biggest predictor of a clean migration is whether one named person owns this list from inventory to monitoring. Not the designer, who is focused on the new site. Not the developer alone, who may not know which pages earn the business money. Someone who understands both.

When we run website builds, redirects, Search Console and tracking are part of launch rather than a follow-up project, and the stabilization period afterwards exists precisely for this monitoring. If you are planning a redesign and want to see where the migration fits in the wider project, the website redesign planning guide puts it in sequence.