Migrations lose traffic for boring reasons. Not one of the five most common causes is unpredictable, and every one of them is preventable on a schedule known weeks in advance. Work this checklist in order and the risk drops sharply.
Four weeks before launch
Freeze a benchmark. Export current rankings, organic sessions by landing page, and Search Console performance for the last twelve months. Date it and save it somewhere nobody will overwrite. Without this you cannot prove afterwards whether the migration hurt you or the season did.
Crawl the existing site completely. Every URL, not the top 500. Screaming Frog, Sitebulb or equivalent, with the crawl saved.
Build a full URL inventory. Merge three sources, because none of them is complete on its own:
- Your crawl
- Search Console’s indexed pages
- Server logs or analytics landing pages for the last 12 months
The third source is the one people skip, and it is where you find the old URLs that still earn traffic but are no longer linked from anywhere.
Map every legacy URL to a destination. One hop, no chains. Every row of the inventory gets a destination or an explicit decision to let it 410. “We will catch the rest with a wildcard” is how the long tail dies.
Two weeks before launch
Audit staging against the same checklist you will use on launch day. Titles, meta descriptions, headings, canonical tags, structured data, internal links, image alt text — verify these exist on the new templates, not just that the pages render.
Check structured data survived. Schema almost never carries over intact in a replatform. Validate the new templates against the Rich Results Test before launch, not after — our schema markup guide covers what to check per template.
Verify the internal link graph. New navigation frequently orphans pages that were previously well linked. Crawl staging and compare click depth against the old site; anything that got deeper needs attention. This is the moment when orphan pages are created.
Prepare the new XML sitemap. Include only canonical, indexable, 200-status URLs on the new structure. See the XML sitemaps guide for the details.
Agree the rollback trigger. Write down, in advance, the metric and threshold at which you revert. Deciding this at 2am on launch night produces bad decisions.
Launch day
Work in this order:
- Check
robots.txtfirst. Staging’s blocking directive shipping to production is the single most common catastrophic migration error. - Check for stray
noindextags across templates. - Spot-check redirects — 50 URLs across every template type, verifying single-hop 301s landing on 200s.
- Submit the new sitemap in Search Console.
- If the domain changed, submit the Change of Address tool.
- Confirm analytics and Search Console are firing on the new property.
- Watch server error rates for the first few hours. Crawl spikes on migration day take down under-provisioned servers.
The first 30 days
Week one: monitor index coverage daily. Some fluctuation is normal; a sustained fall in indexed pages is not. Watch 404 reports for legacy URLs you missed and add redirects as they surface.
Weeks two to four: compare rankings and traffic against the frozen benchmark, by page rather than in aggregate. Aggregate numbers hide the case where half your pages doubled and half collapsed.
Expect a dip. A 10–20% drop for two to four weeks is normal as Google recrawls and reassesses. What is not normal is a drop that is still there at week six — at that point something is broken rather than settling.
If it has already gone wrong
Post-launch recovery is several times more expensive than prevention, but it is very rarely hopeless. Start by dating the loss precisely and separating migration damage from everything else, using the traffic drop diagnostic framework.
If you would rather not run this yourself — or the launch date is too close for comfort — our site migration service covers the whole sequence, and the traffic drop audit is the entry point for migrations that already landed badly.
