Every site migration we have ever been involved with started with a confident dev team telling us “the redirects are sorted, you do not need to worry”. And every site migration we have ever been involved with had at least one preventable issue we caught in the audit. Not because dev teams are bad. Because the failure modes are non obvious until you have seen them happen.
Here is the pre-flight checklist we use. It will not catch everything, but it has caught enough that we keep using it.
Phase 1: before any code moves
Crawl the live site
Full crawl with Screaming Frog or Sitebulb. Export everything. URL list, status codes, internal links, canonical tags, meta data. This is your source of truth for the rest of the project. If you do not have this, you cannot validate anything.
Map your top 200 pages by traffic and revenue
Pull from GSC, GA4, and your revenue platform. Export them. These are the pages that have to land cleanly. Everything else is secondary.
Map every redirect already in place
Most sites have legacy redirects from previous migrations. If you do not preserve them through the new migration, you are creating chains and breaking equity that took years to consolidate.
Phase 2: in staging
Crawl staging with the bot blocked
Set staging to noindex and password protect it. Then crawl it as if you were Google. Compare the URL list against your live site. Anything missing is a future 404.
Build the redirect map page by page
Spreadsheet. Old URL, new URL, redirect type, status. No regex unless absolutely necessary, and even then, document it. Every URL in your top 200 must have a verified one to one redirect.
Schema, canonical tags, hreflang, structured data
Half of the migration failures we have seen were not the redirects. They were the schema getting wiped, the hreflang getting truncated, or the canonical tags pointing at staging URLs that 404 in production. Verify all of them in staging before launch.
Phase 3: launch day
Pick the day carefully
Tuesday or Wednesday morning. Never Friday. Never the day before a long weekend. Never the day before a major commercial period. You want as much team availability as possible in the 72 hours after launch, when you will be diagnosing and fixing in real time.
Submit the new sitemap immediately
Submit the new XML sitemap to GSC the moment the new site is live. Resubmit the old sitemap so Google sees the redirects.
Validate the redirects with a live crawl
Run a fresh crawl against the production URL list within an hour of launch. Anything 404ing or 500ing gets fixed before lunch.
Phase 4: the next 14 days
Most migrations look fine on day one and degrade over the next two weeks as Google re-crawls. Watch:
- Coverage report in GSC. Indexed page count should hold steady or grow. A drop is a problem.
- Crawl stats. Sudden spikes in crawl errors mean something broke.
- Top 200 pages report (yours, not Google). Rankings should hold within 1 to 2 positions.
- Server logs. Are bots actually crawling the new URLs?
When it goes wrong
Sometimes it goes wrong despite all of this. Usually because of a thing nobody documented. A legacy server rule. A CDN cache. A subdomain nobody remembered.
When that happens, do not panic, do not blame the dev team, and do not roll back unless it is genuinely catastrophic. Most “we lost 30% of traffic on launch” stories resolve themselves inside two to three weeks if the redirects are clean and the content survived. Patience and a calm root cause investigation beats a panicked rollback every time.