Site migration without losing your traffic
You are moving a site and you want to know what will break and how to tell whether it did.
Short answer
Most migration losses come from three things: URLs that changed without a redirect, redirects that chain or end in errors, and a staging configuration that shipped with the site. Map every old URL to exactly one new URL before you launch, keep the mapping one hop deep, and expect a dip of a few weeks even when everything is done correctly.
Before anything, take a baseline
Export your Search Console data for the widest range available, page by page and query by query. After launch this is the only way to answer "is this worse". A migration without a baseline turns every subsequent conversation into an argument about memory.
Build the URL map first
Every old URL gets exactly one destination, and that destination returns 200. Not a category page, not the homepage, not a search results page: the closest genuine equivalent. Where there is no equivalent, a 404 is a more honest answer than a redirect to something irrelevant, which engines treat as a soft 404 anyway.
One hop, always
Point the old URL straight at the final destination. It is tempting to layer the new rules on top of the old ones because it works when you test it in a browser, and that is how sites end up three hops deep on every legacy URL on launch day.
The staging checklist
Robots.txt, noindex headers, canonical hosts, and any basic-auth. Every one of these is set to block on staging and every one of them is capable of shipping. Check them on the live host after launch, not in the repository, because the file that matters is the one being served.
Launch and then watch the right numbers
Impressions move before clicks, so impressions are the early warning. Watch crawl activity in your logs, watch server errors, and watch the pages that carried the most traffic before rather than the site total, which averages away exactly the failure you are looking for.
The recovery curve
A dip is normal even on a clean migration, because engines have to recrawl, re-evaluate and reassign. Weeks, not days. What is not normal is a dip that keeps deepening after the first fortnight, or one concentrated on your best pages while the rest holds steady.
The thing that makes it recoverable
A complete before-and-after URL map, kept somewhere you can query. When something is missing three weeks later, and something always is, the difference between a ten-minute fix and an afternoon of archaeology is whether that map exists.
Questions
- How long should I keep the redirects?
- At least a year, and ideally permanently for URLs with external links. Redirects are cheap to keep and the cost of removing one that still carries traffic is losing that traffic silently.
- Should I migrate everything at once or in phases?
- At once, if you can. Phased migrations mean two sets of URLs live simultaneously, duplicate content risks, and a much harder time telling which change caused which movement. Phase only when the site is too large to switch safely.
- How much traffic loss is normal?
- A dip during recrawl is expected and should recover over several weeks. Sustained loss after a month usually traces to a specific fixable cause: a missing redirect group, a canonical pointing at the old host, or a robots rule that shipped.
Measured, not asserted
The value of a baseline is not theoretical: ihatepdf.cv, taken from zero to 100,542 users, lost 31 consecutive days of Bing traffic (17 May to 16 June) with no change on its side. Without the export from before, that would have been indistinguishable from something the site did to itself.
Free tool for this: Search Console Analyzer. No account, nothing uploaded.
Where this goes deeper
Every number on this page comes from one complete dataset: one product taken from zero to 100K+ users on search alone, with nothing spent on advertising. The full argument is Chapter 22 of the book. Five chapters are free to read.