Website migration SEO checklist: how to move a site without losing search visibility

The damage from a badly handled migration is rarely visible on launch day. It shows up three weeks later as a quiet, unexplained decline, by which point the cause is much harder to trace.

Every URL you have ever published may have links pointing at it, rankings attached to it and analytics history behind it. Change the address without a redirect and all three disappear at once.

What follows is the checklist we work through. It is deliberately boring. The boring parts are what protect everything else.

Before you touch anything

Nothing about the new site should be designed until this stage is finished. You cannot protect what you have not counted.

1. Export every URL. Crawl the existing site and pull the full list. Then add the URLs that a crawl will not find: pages reachable only from campaigns, old landing pages, PDFs, paginated archives.
2. Pull the search performance baseline. Twelve months of impressions, clicks and positions by page and by query. Without this you cannot tell afterwards whether something moved.
3. Identify the pages that earn links. These are the ones where a redirect mistake is most expensive.
4. Export all metadata. Titles, descriptions, canonical tags, structured data, heading structure.
5. Record the analytics configuration. Goals, events, filters, and which of them you would notice breaking.

This inventory is the single most valuable artefact in a migration. It takes real time and is not worth rushing.

Decide what happens to every page

With the inventory in hand, each URL gets one of four decisions, and every decision should be explicit rather than emergent.

• Keep the URL exactly. Safest option, always preferred where the new structure permits it.
• Move it to a new URL, with a 301 redirect.
• Merge it into another page, with a 301 to the page that absorbed it.
• Retire it deliberately, accepting the loss, usually with a redirect to the most relevant parent.

The failure mode is a fifth, unspoken option: pages that simply stop existing because nobody noticed they were there. That is what the inventory prevents.

Build the redirect map as a reviewable document

Not as a config file written during deployment. A spreadsheet, two columns, every old URL and its new destination, reviewed and signed off before anything is deployed.

• Use 301 (permanent), not 302, unless the move genuinely is temporary.
• Redirect to the closest equivalent page, never blanket-redirect everything to the homepage. A mass redirect to the homepage is treated as a soft 404 and loses the value you were trying to keep.
• Avoid chains. Old A should point at final C directly, not at B which points at C.
• Check for loops before launch, not after.
• Remember protocol and subdomain variants, and trailing-slash consistency.

Carry the metadata across

Titles and descriptions are easy to lose in a content migration because they live outside the visible page content and nobody notices them missing.

• Migrate title tags and meta descriptions, and improve them deliberately rather than accidentally.
• Review canonical tags on the new site: self-referencing on every indexable page.
• Migrate structured data, and re-validate it — schema that was valid three years ago may not be now.
• Check Open Graph data, or your pages will look broken when shared.

Fix internal links properly

Redirects handle external links. Internal links should point at the new URLs directly.

Leaving internal links pointing through redirects works, technically, but it wastes crawl budget, slows the site marginally, and creates chains as the site evolves. Update them in the content, not just in the redirect table.

Pay particular attention to navigation, footers and any hard-coded links inside body content.

Before the cutover

1. Confirm the staging site is not indexable, and confirm the production site will be. A noindex left on at launch is the most common self-inflicted migration wound.
2. Test a meaningful sample of redirects against the staging environment.
3. Verify analytics and conversion tracking fire on the new templates.
4. Check that forms actually submit and the submissions actually arrive.
5. Prepare the new XML sitemap.
6. Agree who is watching, and for how long, after launch.

At launch

• Remove any crawl blocking from the production site and confirm robots.txt is what you intended.
• Submit the new sitemap in Search Console.
• Run the full redirect list against production and check the status codes, not just that the pages load.
• Request indexing for the most important pages.
• Spot-check the pages that carried the most traffic before the move.

For the weeks afterwards

This is the part that gets abandoned once the launch celebration is over, and it is where problems are still cheap to fix.

• Watch crawl errors in Search Console daily for the first fortnight.
• Watch indexation: is the number of indexed pages moving toward what you expected?
• Compare impressions and clicks against the baseline you exported, by page and by query.
• Watch Core Web Vitals — new templates often regress in ways staging did not reveal.
• Keep the redirect map maintained. It is not a launch artefact; it is infrastructure.

What nobody can promise you

You will see agencies promise no ranking loss. Treat that as a reason for caution rather than reassurance.

Search results shift for reasons no agency controls, and a migration is a large change made during an environment that was already moving. What a proper method gives you is not the absence of movement — it is that if something does move, you see it within days rather than discovering it a quarter later.

The goal is not that nothing moves. It is that nothing moves without you knowing.

The condensed version

If you are planning a move, our redesign and migration page describes how we run this, and SEO covers the ongoing work afterwards.