Site migration without losing rankings
Most migration losses come from the same four omissions, and all four are cheaper to prevent than to recover.
- Map every URL before anything moves. Redirect one to one.
- Move first, confirm stability, rewrite afterwards.
- Baseline before, or you cannot tell recovery from decline.
- A staging robots.txt shipped to production is the classic.
How do you migrate a site without losing rankings?
A site migration keeps its rankings when four things happen in order: every URL is mapped and redirected one to one, the content moves unchanged, the numbers are baselined in the week before the move, and the launch-day technical checks are run against the live site.
The sections below take each one in turn, and the last sets the expectation to hold while it happens.
How do you map URLs before a site migration?
A site migration begins with a complete URL inventory. Crawl the current site and export every URL that exists, including ones nobody remembers. Then decide, per URL, whether it moves, merges or goes. Redirect old to new one to one wherever a match exists.
Sending everything to the homepage is the single most common cause of a migration collapse.
Should you rewrite content during a site migration?
Keep the content itself out of the migration: move the existing pages unchanged and rewrite them later. Rewriting during a migration mixes two variables. When rankings fall you cannot tell whether it was the move or the words. Move first, confirm stability, rewrite afterwards.
It is slower and it keeps the diagnosis clean.
What should you measure before and after a migration?
A migration needs a before-and-after record, and the before half has to be recorded while the old site is still live. Record rankings, indexed page counts, traffic by page and profile position the week before. Without a baseline you cannot tell recovery from decline, and you will argue about it for a month.
Then watch weekly for six weeks. Some fluctuation is normal, and the shape of the recovery curve tells you whether anything is broken.
What should you check on launch day?
Launch day is a short list of unglamorous checks run against the live site: robots.txt, analytics, structured data, Search Console and internal links. Each has a state it has to be in before traffic arrives, and the table below gives them one per row.
| Check | State it has to be in on launch day |
|---|---|
| Robots.txt | Not carrying a staging block |
| Analytics | Still firing |
| Structured data | Still present |
| Search Console | Updated |
| Internal links | Pointing at new URLs rather than through redirect chains |
A staging robots.txt shipped to production is the classic, and it can cost weeks before anyone notices.
What is a realistic expectation after a migration?
A dip is the normal outcome of a migration, and the honest question is how deep it goes and how long it lasts. Even a well-run migration usually dips before it recovers. Anyone promising no movement at all has either not done many or is not telling you about the ones that went badly.
“Sending everything to the homepage is the single most common cause of a migration collapse.”
Rankings are never guaranteed. Anything we could not trace to a primary source is absent from this page, not estimated. The audit runs the same six layers described on the pricing page, and Share of Answer is scored quarterly.
Youssef works on visibility for established local businesses. The surfaces are Google Maps, organic search and AI answers, the cadence is quarterly, and the protocol is public. A figure that resists checking never reaches the report.
More about Youssef