Site Migration SEO Checklist: The Phases That Actually Matter
Most migration checklists are a flat list of two hundred items with no sense of timing. That is why they fail. The steps that protect traffic are tied to a phase: things you must do before launch, on launch day, and after. Get the order right and a migration usually holds. Get it wrong and no checklist saves you.
Why phase order matters
A migration is any change big enough that search engines have to relearn the site: a new platform, a new domain, a new URL structure, or a consolidation. The risk is not evenly spread. The cheapest problems to fix live on staging. The most expensive live in production, discovered days later in the logs. Phase order is how you move problems left, to where they are cheap.
Pre-launch
This phase decides the outcome. Do the following before anything goes live.
- Crawl the current site in full and archive the URL list. Once the old site is gone, reconstructing it is painful.
- Build the redirect map (covered below) and have it reviewed.
- On staging, confirm pages are crawlable, canonicals are correct, and primary content renders in the initial HTML.
- Prepare the new XML sitemaps and a sitemap index if the site is large.
- Benchmark current traffic, rankings, and index coverage so you can measure against a real baseline.
Staging should be blocked from public crawling, but check that the block does not ship to production. A staging noindex or a blanket robots.txt disallow going live is one of the most common migration disasters, and it is entirely preventable.
Launch day
Launch day is for monitoring, not building. The work is already tested. Confirm the essentials fast.
| Check | Failure it prevents |
|---|---|
| Redirects resolve in one hop to the mapped URL | Lost link equity and crawl waste from chains |
| robots.txt allows crawl and lists the sitemap | Whole-site de-indexing |
| No stray noindex or staging canonical | Accidental removal of key pages |
| New sitemaps submitted, old kept briefly | Slow rediscovery of redirects |
| Analytics and Search Console still tracking | Flying blind during the riskiest window |
Scroll table horizontally →
Post-launch
For the following weeks, watch and clean. Index coverage will move as Google reprocesses the new URLs. Rankings often wobble, then settle. Read the logs for 404 spikes and for URLs Googlebot cannot reach. Catch redirect chains forming as the team ships follow-up work. Compare everything to the pre-launch baseline, and do not declare success on week-one numbers.
The redirect map
The redirect map is the heart of the migration. It is a spreadsheet with one row per old URL, containing the old path, the new path, the intended status code, and a note for any URL with no clean equivalent. The rule: map to the single best destination, never in bulk to the homepage.
old_url new_url status
/blog/2023/seo-tips /guides/seo-tips 301
/products/old-sku-123 /products/blue-widget 301
/category/discontinued /category/widgets 301
# No clean match? Decide: closest relevant page or 410.Every redirect should be a single hop. Chains from stacked past migrations waste crawl and risk breaking. Our guide to auditing redirect chains at scale covers how to find and collapse them.
Mistakes that sink migrations
The same handful of errors account for most migration disasters, and every one of them is preventable. The staging environment shipping to production with its noindex or its blanket robots.txt disallow still in place is the classic, and it can de-index a whole site in a day. Redirecting large numbers of old URLs to the homepage instead of the closest equivalent is another, because Google treats those bulk redirects as soft 404s and the link equity evaporates.
Changing the URL structure and the platform and the design all at once is a subtler trap. Each of those is a variable, and stacking them means that when traffic moves you cannot tell which change caused it. Where you can, hold some variables steady: keep URLs identical if only the platform is changing, or change URLs without redesigning at the same time. It is not always possible, but it is worth pushing for.
Two more that hurt quietly: forgetting to migrate or update the XML sitemaps, so Google keeps chasing the old URL set, and dropping the canonical tags during the rebuild so pages start competing with themselves. Neither shows up as a dramatic error. Both slow recovery for weeks. A pre-launch crawl of staging catches all of these while they are still cheap to fix.
If it already went wrong
If you are reading this after a migration dropped traffic, do not panic and do not roll back blindly. Crawl the old and new URL sets, find the broken and chained redirects, check for lost canonicals and accidental noindex tags, and confirm what Google has already dropped. Sequence the recovery by traffic impact so the highest-value URLs get fixed first. Recovery is usually possible, and it is faster the sooner you look.
The takeaway: a migration is won or lost before launch, in the redirect map and the staging QA. Treat launch day as a monitoring exercise and the weeks after as cleanup. If the site is large or the last migration already hurt you, a dedicated site migration SEO engagement is cheaper than the traffic a botched launch costs.