Most site migrations are launched for good reasons: a faster platform, a new design, a consolidated brand. The risk is that search engines do not care about the reasons. If they cannot map your old pages to the new ones, the organic traffic you built over the years can disappear on launch day.
TL;DR: To migrate without losing SEO traffic, record a baseline before the move, build a one-to-one redirect map, test it on staging, remove staging blocks before launch and monitor crawling and indexing weekly afterwards. Treat recovery as a process measured in months, not days: a Search Engine Journal study of 892 domain migrations found an average recovery time of 523 days.
The checklist below covers preparation, launch and the first weeks, and ends with a single list you can copy into your project plan.
Why do migrations lose organic traffic?
Because the search engine has to relearn the site. URLs change, internal links break, redirects are missing or chained, and technical settings from the staging environment leak into production. Each mistake removes pages from the index or weakens their signals.
The scale of the risk is visible in data. In an updated study published by Search Engine Journal in January 2025, covering 892 domain migrations, it took on average 523 days for the new domain to reach the organic traffic level of the old one, and 17% of migrations did not reach it even after 1,000 days. Two caveats apply: the traffic figures are estimates from third-party tools, and the study covers moves between domains, not CMS changes on the same domain. Use it as a reminder of the downside, not a forecast.
What should you crawl and document before the move?
You need a complete picture of the current site, because you can only protect what you know exists. Collect these four things before anyone changes a URL:
· a full crawl of the existing site, with status codes, canonicals and internal links;
· server logs for the last few weeks, to see which pages Googlebot actually requests;
· an export from Search Console and analytics, to rank pages by traffic and by inbound links;
· a list of orphan pages and URLs that bots crawl but your structure no longer links to.
Before TemplateMonster moved to a new UI and CMS, its team ran a complete crawl, joined it with server logs and used JetOctopus, seo management software for agencies and in-house teams alike, to compare the site structure with what Googlebot actually did. That showed about 3 million orphaned pages that Googlebot kept crawling and about 250,000 valuable pages it had never visited, and the migration went smoothly.
The lesson applies at any size, from a 50-page brochure site to a catalog of millions: the pages bots visit and the pages you care about are not always the same list, and a migration is the cheapest moment to align them.
How do you build the redirect map?
Start from the crawl and give every old URL that has traffic, links or rankings a single destination on the new site. Map each old page to its closest equivalent, not to the homepage, and use 301 redirects because the move is permanent.
Avoid chains in which one URL redirects to another that redirects again: Google’s crawl budget guide lists long redirect chains among the things that waste crawling. Point every old URL straight to its final destination. Then test the map on staging with a crawler that follows redirects, and check that each old URL ends in a 200 response on the right page.
Keep the redirects in place for as long as you can. Old URLs live on in other sites’ links, bookmarks and search results long after launch, and removing a redirect too early turns every one of those into an error. Finally, update your own internal links to point directly at the new URLs, so that visitors and bots do not rely on redirects to move around your own site.
What should you check on launch day and in the first week?
Most launch-day damage comes from settings that should have been removed. Check these first:
· noindex tags left over from staging, which tell Google to drop pages;
· a robots.txt file that still blocks the whole site;
· canonical tags that point to the staging domain or to old URLs;
· status codes that flip between 200 and a 5xx error on repeat requests, which makes the site look unstable to bots;
· the sitemap, which should list only the new, indexable URLs.
Staging settings are the most common cause of damage because they are invisible in the browser: the page looks fine while its source tells search engines to leave. A crawl of the live site right after launch, filtered for noindex, canonical and robots directives, catches them in minutes. Run it before you announce the launch internally.
Then watch the logs. Googlebot requests to the new URLs, and the share of 3xx, 4xx and 5xx responses, tell you within days whether the bot found the new structure. Compare each week with the baseline you saved before the move.
How do you know whether the migration worked?
Decide before launch what success looks like, otherwise every dip will be argued about. Use four measures, each compared with the baseline you saved:
· Indexed pages. The number of indexed URLs in Search Console should approach the number of pages you intended to keep.
· Clicks and impressions. Compare weekly totals for the pages that carried traffic, not the site average, so a few strong pages do not hide the losses.
· Bot behavior. Googlebot should request the new URLs and stop requesting the old ones. Old URLs that keep receiving hits show where redirects or links still point to the past.
· Errors. The share of 404 and 5xx responses should fall to or below the pre-migration level within a few weeks.
If a measure moves the wrong way for a month, investigate it instead of waiting. Look first for a pattern: one template, one directory or one type of URL, because most migration damage is local rather than site-wide.
Who should own which part of the migration?
Migrations fail between teams more often than inside them. Agree owners in writing. The SEO owner supplies the baseline, the URL map and the acceptance checks. Developers implement redirects and remove staging settings. Content owners confirm which pages are merged or retired. One person signs off the launch checklist, ideally someone who can say no to the date.
A step-by-step SEO migration checklist
1. Save a baseline: full crawl, server logs and Search Console export.
2. Create the URL map, one old URL to one new URL, using 301 redirects.
3. Test redirects and templates on staging and fix chains.
4. Remove noindex, robots.txt and canonical settings that belong to staging before launch.
5. Submit the new sitemap and verify status codes on key pages the day of launch.
6. Monitor logs and Search Console weekly for at least three months, and compare them with the baseline.
Conclusion
A migration succeeds in the preparation. Record what you have, map it page by page, remove the staging leftovers and watch how bots behave after launch. If something breaks, the baseline tells you where. Without it, you are guessing which of thousands of pages changed, and the argument about what went wrong replaces the work of fixing it. Treat the baseline as the cheapest insurance in the project. Even a modest site benefits from a saved crawl and a spreadsheet of top pages, and it costs an afternoon.
FAQ
How long does it take for traffic to recover after a migration?
For domain moves, Search Engine Journal’s January 2025 study of 892 migrations found an average of 523 days, and 17% of sites had not recovered after 1,000 days; traffic was estimated with third-party tools. For a CMS change on the same domain there is no comparable dataset, so track clicks and indexed pages weekly against your baseline and investigate any gap that persists for a month.
Should I use 301 or 302 redirects when moving a site?
Use 301 for a permanent move, and keep 302 for temporary changes. Whichever you pick, point each old URL straight to its final destination. Google’s crawl budget guide names long redirect chains among the causes of wasted crawling, so a clean map of single redirects is better than layers of them.
Should I keep my old URL structure?
If you can, yes. Unchanged URLs need no redirects and carry fewer risks. If the structure must change, map each old URL to the closest equivalent page, not to the homepage or a general category, and keep the one-to-one list in a spreadsheet so you can check it after launch.
What are the most common launch-day mistakes?
Five recur: a noindex tag left from staging, a robots.txt file that blocks the site, canonical tags pointing to staging, a sitemap that lists old or redirected URLs, and pages that return 200 and then 5xx on repeat requests. A crawl of the live site on launch day finds all five in an hour.
How do I monitor a migration with server logs?
Filter the logs to Googlebot and compare four numbers each week with your pre-migration baseline: requests to new URLs, the share of 3xx, 4xx and 5xx responses, pages the bot stopped requesting, and requests to old URLs. This is a practical routine, not a published standard.
