Site Migration SEO: The Full Checklist
A site migration loses traffic when redirects, canonicals or content go missing. This checklist covers the mapping, the launch and the four weeks after.
A site migration keeps its traffic when every indexed URL redirects to its closest live equivalent, canonical tags and hreflang carry over correctly, and nothing important changes at the same time as the domain, platform or URL structure. Miss any one of those and recovery takes months instead of weeks.
Migrations sit inside the wider technical SEO checklist as the highest-risk single event on it, because a mistake here can undo months of otherwise solid work in one deploy.
On this page
What counts as a migration for SEO purposes?
Any change that moves, renames or restructures URLs search engines already have indexed: a domain change, a move from HTTP to HTTPS, a platform replatform, a URL structure change, or a redesign that happens to touch templates at the same time. Google's own guidance treats "with URL changes" and "without URL changes" as genuinely different risk levels [1][2], and it is worth knowing which one you are doing before you start planning.
A redesign that keeps every URL identical carries far less risk than one that renames paths, even if the redesign itself looks like the bigger project. The URL is the thing search engines have built history against; change it and you are asking that history to transfer, not just refreshing what sits behind it.
| Change | URLs affected | Typical risk |
|---|---|---|
| Visual redesign, same URLs | None | Low |
| HTTP to HTTPS | Protocol only | Low, if done correctly |
| CMS or platform replatform, same URLs | None, if preserved on purpose | Medium |
| URL structure change | Every affected URL | High |
| Domain change | Every URL on the site | Highest |
How do I build a redirect map that actually holds?
Start from what Google has indexed, not from what the new site contains. Pull every URL from your XML sitemap, your Search Console coverage report and, if you have it, your server logs, then map each one to the single closest equivalent on the new site.
Export every currently indexed URL
Combine the sitemap, the Search Console Page indexing report, and analytics landing pages from the last twelve months into one list.
Map each one to its new destination
One redirect per old URL, to the page that actually replaces it in content and intent, not to the homepage as a catch-all.
Flag anything with no real equivalent
A page being retired on purpose still needs a decision: redirect to the closest parent category, or let it 404 deliberately.
Test the map against a staging copy
Crawl the old site's URL list against the new environment and confirm every mapped redirect actually resolves to a 200, not a chain or a soft 404.
Keep the map after launch
You will need it again the day someone finds a URL that was missed.
A redirect to the homepage is the default that causes the most damage. It tells Google nothing about what replaced the page, so the signal the old URL had built simply evaporates instead of transferring. Map to the actual replacement, even when that means more work up front.
Redirect chains are the second most common cause of a slow recovery. A URL that redirects to another redirect, which redirects again to the final destination, still resolves for a visitor, but it costs crawl budget on every hop and dilutes how much of the original signal reaches the page that matters. Rewrite every chain to a single hop before launch; on a large site this alone can be the difference between a smooth recrawl and one that stalls halfway through the list because the crawler ran out of budget before it reached the true destinations.
It is worth deciding, in writing, who owns the map once it exists. On most migrations we see, the map is built once by whoever is closest to the deadline, then nobody owns it afterward, so the first new URL added six months later has no redirect convention to follow and the site quietly starts collecting broken links again. Assign an owner and a place the map lives that outlives the migration project itself.
What has to survive the move besides the URL itself?
The whole page, not just its address. Canonical tags need to point at the new URL's own address, not a stale copy of the old one carried over in a template. Hreflang pairs, if the site has more than one language, need every entry updated to the new URL structure at the same time the redirect goes live, or you end up debugging two problems that look like one; our guide to fixing hreflang errors covers that diagnosis directly.
Structured data, internal links, and image paths all need the same treatment. An internal link pointing at an old URL still works through the redirect, but a chain of internal links all pointing at redirects instead of final destinations adds up to a slower, messier crawl than one where every link already points where it should.
Should the new site launch client-rendered or server-rendered?
Whatever it was before, unless you have a specific reason to change it, and if you do change it, treat that as its own separate risk on top of the migration itself. A move from a server-rendered platform to a client-rendered one at the same time as a domain change makes it much harder to tell which change caused which drop in traffic. Our guide to JavaScript SEO covers what a crawler needs to see in the first response regardless of platform.
The same logic applies to Core Web Vitals. A migration is a natural moment to also improve page speed, but bundling a speed rewrite with a URL change means a regression in either one gets blamed on the wrong cause. Where possible, ship the URL migration first, confirm it holds, then run the speed project as a second, separately measured change; our Core Web Vitals guide has the fix order for that project on its own.
How do I sequence the actual launch?
Stage it wherever the platform allows. Migrating one section, such as the blog, before the rest of the site gives you a smaller blast radius to catch mapping mistakes in, and a working pattern to repeat with more confidence on the sections that carry more traffic.
Freeze content changes during the cutover window
A content edit landing at the same moment as a redirect makes it harder to isolate what changed.
Launch redirects and the new site together
A gap between the old site going down and redirects going live turns into 404s a crawler will record.
Resubmit the new sitemap immediately
Do not wait for Google to discover the new structure on its own schedule.
Watch server logs for 404s from old URLs
Anything still returning a 404 a week in is a gap in the map, not a page nobody cared about.
What do I check in the first four weeks?
Coverage first, rankings second. The Page indexing report in Search Console will show old URLs dropping out and new ones coming in; watch for old URLs marked as a redirect rather than a 404 or an error, which confirms the map is being read correctly.
Rankings and traffic typically lag indexing by one to two weeks past that, and some fluctuation in that window is ordinary even on a migration that goes well. What should not happen is a shortfall that is still growing at the four-week mark; that pattern means something in the map or the new templates is still wrong, not that the site simply needs more time.
If you want a second set of eyes checking the map and the post-launch numbers, that diagnostic work is exactly what sits inside our technical SEO service, run against your actual crawl and log data rather than a generic checklist.
What should we do differently on a domain change specifically?
Treat it as the highest-risk case and plan extra time around it. A domain change asks Google to transfer trust built over years to a brand-new address, and even a perfectly executed move usually shows a temporary dip while that transfer processes. Google's own guidance on moving with URL changes exists largely because of this case [1], and the core advice does not change: map every URL, redirect with a real 301, and keep the old domain reachable and redirecting for as long as you can, ideally a year or more, rather than letting the registration lapse the moment the new domain is live.
Communicate the change outside of SEO too. Update the domain everywhere it appears under your own control: email signatures, social profiles, directory listings, and any partner site that links to you. Those external links still point at the old domain, and while the redirect will carry the visitor and most of the signal through, a direct link to the new domain is cleaner and faster, and it is work you can start well before the migration itself launches.
Questions people also ask
How much traffic should we expect to lose during a migration?
Some short-term fluctuation is normal even on a well-planned move, because Google has to recrawl and reprocess the whole site. A migration built on a full URL map with correct redirects should recover within a few weeks; one without a map can lose traffic for months.
Do we need 301 redirects for every single old URL?
Every URL that carries traffic, links or rankings, yes. A handful of long-dead pages with no history are not worth mapping individually, but anything a search engine currently indexes or a real page links to should redirect to its closest live equivalent.
Should we launch the new site all at once or in stages?
Staged, wherever the platform allows it. Migrating one section first lets you catch mapping mistakes on a smaller blast radius before the whole site depends on the same redirect logic being right.
How long before we know the migration worked?
Give it four full weeks before judging the outcome. Search Console's indexing and traffic data both lag the actual crawl, and a dip in week one that is still a dip in week four is a different problem than a dip that is already recovering.
What is the single biggest cause of migration traffic loss?
A redirect map built from the new site's structure instead of the old one. The map has to start from every URL Google currently has indexed, not from what a sitemap of the new site happens to include.
Sources
- Site moves with URL changes — Google Search Central (checked 22 September 2026)
- Site moves without URL changes — Google Search Central (checked 22 September 2026)
- 301 redirects — Google Search Central (checked 22 September 2026)
Planning a migration and want the redirect map checked first?
Book a free 30-minute consultation with Ibrahem and Jeremy. We look at your site while we talk, and you leave with a prioritised plan.
Who wrote this
Jeremy ZavaCo-founder
Leads growth and client partnerships.
Works on: CRO, SEO
Reviewed before publishing by Ibrahem Helal, Co-founder.
- Technical SEO: the complete checklist for 2026Technical SEO makes sure search engines and AI crawlers can reach, render and index your pages. This checklist covers every layer, in the order to fix it.
- JavaScript SEO: Get Google to See Your PagesJavaScript SEO means rendering content so crawlers see it without running your scripts: pick server rendering, check the raw HTML, and avoid client-only routes.
- Hreflang Errors: How to Find and Fix ThemHreflang errors mostly come from missing return tags or wrong language codes. Here is how to find every broken pair and fix them without breaking more.
- Indexing Problems: Why Pages Stay OutPages stay unindexed for a handful of reasons: low quality, a blocked crawl path, a wrong canonical, or Google simply choosing not to bother yet.