The site migration SEO checklist
Site migrations are where SEO careers are made and unmade. Across replatforms, domain changes, URL restructures, and combinations of all three, the pattern is consistent: migrations rarely fail because of one big mistake. They fail because of five small ones nobody checked.
This is the checklist that catches those five, phase by phase, in the order the phases should run. Adapt the details to your stack; do not skip the phases.
Before anything, benchmark like you will need to prove it
After launch, someone will ask 'is this normal or are we dying?' and you can only answer with a baseline. Capture it while the old site is still live:
Search Console performance export: 16 months of clicks, impressions, and queries, broken down by page. The regex filters will not save you retroactively.
Top pages by organic traffic and revenue from analytics, so you know which 200 URLs actually matter.
A rank tracking sample across head terms and representative long tail.
A full Screaming Frog crawl of the old site, saved. This becomes your reference for titles, metas, canonicals, structured data, and internal linking after the old site no longer exists.
CrUX and PageSpeed Insights baselines for key templates, including LCP, INP, and CLS.
A backlink export with target URLs, so your redirect map protects the pages that earn links.
A structured data inventory: which templates emit which schema types.
One more thing: keep the old Search Console property verified forever. If the domain changes, you will want both properties reporting through the transition.
This is also the moment to pick the launch window. Migrate in your quietest season, never ahead of your biggest one, and never on a Friday. You want engineers at their desks and a full business week of data before the weekend hides a problem from you.
URL mapping, the core deliverable
The redirect map is the migration. Everything else is supporting material.
Build the complete inventory of old URLs from every source you have: the crawl, Search Console (both performance data and indexed pages), analytics history, server logs, and the backlink export. Each source catches URLs the others miss; logs in particular surface old URLs Google still visits that nothing links to anymore.
Map every old URL to its single best new equivalent, one to one wherever the new site allows it.
Tier the map: pages with traffic, rankings, or backlinks get hand-checked; the long tail can be mapped by pattern rules.
Where a true equivalent does not exist, map to the closest relevant parent, not the homepage. Mass redirects to the homepage get treated as soft 404s, and the equity evaporates.
Let genuinely dead content die with a clean 404 or 410. Redirecting garbage to good pages helps nobody.
Get the map reviewed by someone who knows the content, not just the URLs. Pattern rules produce confident nonsense at scale.
Redirect strategy
Use 301s. Not 302s that someone promises to change later, not JavaScript redirects, not meta refreshes. Server-side 301s.
One hop. Old URL straight to final destination. Chains leak crawl efficiency and patience, and they compound with every future migration.
Flatten history: if previous migrations left redirect layers, update those old rules to point directly at the new final URLs. This is the tidiest moment you will ever get for it.
Handle query strings deliberately: parameters that select content must survive the redirect; tracking parameters should pass through unharmed.
Preserve case and trailing-slash handling, two classic sources of accidental redirect loops.
Plan to keep the redirects for years. Google has said signals consolidate after roughly a year of a redirect being live, but users, browsers, and backlinks do not run on Google's clock. Redirects are cheap; keep them.
Test the entire map on staging before launch: script it with curl or run the old URL list through Screaming Frog in list mode against the staging host, and verify final status and destination for every row.
Staging and the noindex booby trap
Every experienced SEO has a version of this story. Staging was blocked from indexing, correctly. Then launch day arrived, someone copied the environment to production, and the blocks came along for the ride. The noindex meta tag shipped. Or robots.txt still said Disallow: /. Or every canonical on the live site pointed at staging.example.com.
Two defenses. First, protect staging with authentication rather than robots directives; a password cannot accidentally ship to production the way a meta tag can. Second, treat the reverse check as a launch blocker: an automated test that fails the deploy if production serves noindex, a blocking robots.txt, or staging hostnames in canonicals. This failure mode is common enough that it belongs in the first five minutes of any post-migration triage, and it earns that slot depressingly often.
While staging is up, run the parity check that catches everything else: crawl staging with Screaming Frog and diff it against your saved crawl of the live site. Compare titles, meta descriptions, canonicals, structured data, indexability, and internal link counts template by template. Every unexplained difference is either an approved change or a bug, and launch day is a terrible time to find out which.
Launch-day checks
The first hours matter. Run this list top to bottom before anyone opens the champagne:
Fetch robots.txt with curl: status 200, correct content, no stray Disallow: /.
Check key templates for noindex, in both the HTML source and the X-Robots-Tag response header. Header noindex is the one everyone forgets to look for.
Run the redirect map sample: a few hundred prioritized old URLs through list mode, confirming one-hop 301s to the intended targets.
Verify canonicals on every template point to the live production URLs, correct protocol and hostname included.
Confirm internal links point directly at new URLs rather than bouncing through the redirect layer. Navigation, footers, and hardcoded module links are the usual offenders.
Generate and submit new XML sitemaps. Temporarily keeping a sitemap of old URLs available helps Google process the redirects faster.
Spot-check structured data on key templates with the Rich Results Test.
Confirm analytics and Search Console verification survived the switch, on the correct property.
Check hreflang if you have international versions; migrations love to break return tags.
Run PageSpeed Insights on key templates: a migration that ships a slower LCP or worse INP is smuggling a second problem inside the first.
Watch logs or a real-time 404 report for the first spike of unmapped URLs, and patch the redirect map the same day.
The quiet ways traffic dies
When migration traffic drops, the postmortem usually finds one of these, and rarely the one everyone suspected:
Dropped parameters. The old site served content on ?category=12, the new redirect strips the query string, and a thousand pages now funnel into one generic destination that soft-404s.
Changed internal linking. The new design removed the footer links, collapsed the mega menu, or cut cross-linking modules, and the pages those links supported slid quietly down the rankings. The redesign gets blamed on 'the migration' when it is really an internal link deficit.
Lost structured data. The old templates emitted Product and Review schema; the new ones do not, and rich results disappear along with their click-through rates.
Robots and noindex leftovers from staging, covered above, but worth listing twice because it happens twice as often as anything else.
Content changes smuggled in. 'Just a replatform' that also rewrites titles, thins category copy, and drops FAQ sections is three migrations wearing one project name. Change one variable at a time if you possibly can.
Slower templates. New stack, heavier JavaScript, worse Core Web Vitals, and a slow bleed that nobody attributes to speed because the launch chart looked fine for two weeks.
Pagination and facet changes that orphan deep product pages the old structure used to reach.
Simply forgotten sections: the old blog subdomain, the help center, the PDF library nobody owned. If it had traffic and no redirect, it is donating that traffic to your competitors.
Post-launch monitoring
The first 48 hours: watch server logs for 404 and 5xx spikes from verified Googlebot, and confirm crawl activity shifts onto the new URLs. Search Console's Crawl stats report lags a bit but confirms the trend.
Weeks one through four: track the Page indexing report in both properties, old URLs draining out as redirects process, new URLs filling in. Recheck your rank tracking sample weekly. Re-crawl the site and diff it against your saved pre-migration crawl: titles, canonicals, structured data, internal link counts to your money pages. That saved crawl is now the only copy of the truth, which is why phase one insisted on it.
Keep a running log of every fix you ship, dated. When the graphs wobble, you will want to know whether the wobble followed a fix or preceded it.
If the migration involves a domain change, two extras. Use the Change of Address tool in Search Console on the old property; it explicitly tells Google the site moved and speeds up the transfer. And keep the old domain registered and serving its redirects for years, not months. Expired old domains get scooped up and rebuilt by strangers, taking a decade of link equity with them. The renewal fee is the cheapest insurance in SEO.
Timeline expectations
Set these before launch, in writing, because every stakeholder discovers a strong opinion about them afterwards. The write-up needs three numbers: the expected dip, how long recovery should take, and the threshold that triggers escalation. Vague reassurance before launch becomes panic after it; a documented forecast becomes a plan everyone already agreed to.
Some ranking turbulence is normal while Google reprocesses the site, even in a flawless migration. Small sites with clean one-hop redirects often stabilize within a few weeks. Large sites take longer: Google itself talks in terms of months for big migrations, and practice bears that out, with the deepest sections processed last. A URL restructure on the same domain is usually gentler than a domain change; a replatform that changes URLs, templates, and infrastructure at once is the riskiest thing you can do short of doing it twice.
Worry when the data says to: traffic still well below baseline after four to six weeks, combined with growing 404s in the logs, redirect chains you did not plan, or indexing reports going the wrong direction. Those are findable, fixable problems, and every one of them traces back to a checklist line. Which is the real argument for the checklist: not that it guarantees a smooth migration, but that when something breaks, you know exactly where to look.