Most migrations I’ve watched go badly have done so for the same reason. The redirect map got built from the URLs the team could list, and the traffic was sitting on URLs nobody listed. Everything else (CMS choice, launch date, which vendor won the replatform pitch) is noise by comparison.
What follows is a sequence rather than a menu. The pre-launch work runs to weeks rather than days on a large estate, the launch window itself is a few hours, and the monitoring runs 90 days. Compressing the first is how organizations end up doing the third in a crisis, in front of the finance director.
This holds whether you’re changing domain, changing URL structure, replatforming, or folding four regional sites into one. The technology changes. The failure mode doesn’t.
Build the URL inventory from every source and reconcile it
You need every URL that exists, every URL that earns and every URL with a link pointing at it. No single export has all three, so build from several sources and reconcile the differences rather than trusting whichever arrives first.
Export every URL from the CMS database directly, including unpublished, archived and redirect-target records, because the admin UI filters out content types that are still live and indexed.
Pull every XML sitemap, including ones nobody has touched in three years, plus any sitemap index robots.txt still references.
Run a full crawl with a high URL limit and no depth cap, seeded from the homepage, the sitemaps and the CMS export.
Export the full Search Console page history available to you, plus two years of analytics landing pages. That’s the only way to find URLs that still earn but have no internal link left pointing at them.
Export the top 10,000 URLs by referring domains from your link tool, so external equity aimed at dead campaign pages survives the move.
Reconcile all of it into one sheet with a source column, then investigate every URL appearing in one source and not the others. That’s the actual work, and it’s where the PDFs, the legacy landing pages and the old blog taxonomy turn up.
Expect the reconciled list to come back much larger than the one the project team started from. If it comes back the same size, you’ve missed a source.
Why rule-based redirect mapping misses the URLs that earn
Rules are the right tool for the bulk of the estate. A pattern mapping /products/{sku} to /shop/{sku} handles tens of thousands of URLs in one line of configuration, and hand-mapping them would waste a month.
The problem is what rules systematically miss, which is every URL that doesn’t follow the pattern. And a URL off the pattern is, almost by definition, one a human made deliberately. The hand-built campaign landing page. The microsite from a 2019 product launch. The gated PDF that quietly collected links for years. The vanity URL printed on the packaging. Those carry a disproportionate share of the links and often of the revenue.
So apply rules to the bulk, then take the top 500 URLs by organic revenue and the top 500 by referring domains and map each one by hand. Check every destination is genuinely equivalent in content rather than merely adjacent. Google’s site move guidance is direct about it: don’t redirect many old URLs to one irrelevant destination such as the new homepage, because it confuses users and Google might treat it as a soft 404. A product page redirecting to a category page is the same mistake at smaller scale.
Use permanent redirects, server-side. Google’s redirect documentation explains why the distinction matters: with a permanent redirect the indexing pipeline treats the target as canonical, while with a temporary one it doesn’t, and the old URL keeps showing. Redirect in one hop. Keep the rules from previous migrations alive rather than collapsing them, unless somebody has verified the chains resolve in a single step.
Staging parity testing proves the new site stays machine-readable
The point of staging isn’t checking whether the new site looks right. It’s proving the new site reads the same way to a machine as the old one did, while the change can still be undone.
Crawl staging with rendering enabled and diff it against the production crawl, template by template: title, headings, canonical, body word count, internal link count, structured data type.
Confirm staging blocks crawlers correctly and, more to the point, that somebody removes the block at launch. A noindex header surviving go-live is a common catastrophic migration error, and the one nobody checks because it feels too basic. Google’s documentation adds a wrinkle you’d rather know beforehand: a noindex rule only works when robots.txt isn’t blocking the page, and undoing one isn’t instant, because Googlebot may take months to revisit it.
Test the redirect map against staging in bulk over the full inventory, checking status code, hop count and final destination. Re-run it after every deployment, because deployments quietly undo redirect configuration.
Verify structured data survives the template rewrite, particularly Product, Organization and BreadcrumbList markup somebody bolted into the old templates by hand.
Compare staging performance against production field data on throttled mobile. A front end that pushes LCP past 2.5 seconds at the 75th percentile is a business decision, and somebody senior should take it knowingly rather than find out in week three.
hreflang and canonicals across a multi-market migration
If the site serves several markets, the migration is roughly twice the work, because hreflang annotations reference URLs and they’re all changing at once. Google is unambiguous about the consequence: if two pages don’t both point to each other, the tags get ignored. Break one side of a pair and the cluster falls back to whichever version Google prefers, usually the English one.
Regenerate the entire hreflang set from the new URL map rather than find-and-replacing the old one. Confirm every pair returns and that x-default points somewhere sensible.
One nuance that a lot of migration advice overlooks is that Google treats the three implementation methods (HTML tags, HTTP headers and sitemap annotations) as equivalent, so choosing one over another buys you nothing in Search. The reason I still prefer sitemap annotations during a migration is operational: you can regenerate them wholesale and validate them in bulk, which is what you want when every URL moves in one release.
Carry canonical behaviour across explicitly. A template that self-canonicalized on the old site needs verifying on the new one, not assuming. This is the point where multi-market structure stops being a strategy question and becomes a deployment question.
The launch window, rollback criteria and the first 90 days
Launch mid-week, in the morning, in the timezone of your largest market. Friday evening launches exist so that nobody discovers the problems until Monday.
In the first two hours, confirm the noindex has gone, render a dozen URLs per template in URL Inspection, and submit the new sitemaps. Then spot-check fifty redirects from the hand-mapped list, and watch error rates and response times in the CDN dashboard rather than in analytics, which lags. If you’re changing domain or subdomain, submit the Change of Address in Search Console.
Agree on the rollback threshold before launch, in writing, with a number in it. Nobody has ever agreed on a fair rollback criterion at 11pm during an incident.
A workable threshold reads like this. A sustained 5xx rate above an agreed percentage, or checkout conversion down more than an agreed amount for two hours, triggers a rollback. Organic traffic is explicitly not a trigger in week one, because it will move and the movement means nothing yet.
Then the monitoring. Traffic almost always dips, so the question isn’t whether it dipped but whether recovery matches the shape you should expect. Google sets that expectation for you. Visibility may fluctuate temporarily during a move and settles down over time, and a medium-sized site can take a few weeks or more before Google starts showing the new URLs instead of the old ones. Larger sites take longer than that.
- Day 1 to 7: crawl errors, redirect failures in the logs, Googlebot hit rate on new URLs.
- Day 7 to 30: index coverage on the new URL set against the old, which Google expects to show the old count dropping as the new one climbs, plus the first movements on head terms.
- Day 30 to 60: organic revenue by template against the pre-launch baseline, and the long tail, which recovers slowest.
- Day 60 to 90: the honest read on whether you’re back, and a written list of what you’d do differently.
Keep the redirects. Google’s own floor is at least a year, and the practice I’d argue for is never taking them down.
What to do first on a site migration
Build the reconciled inventory before anybody agrees on a launch date. It takes about a week on a large estate, everything downstream depends on it, and you can’t rebuild it once the old site has gone.
If the migration is already booked and the inventory doesn’t exist, that’s this week’s conversation, and it’s the first thing I do on a migration engagement.