Website Migration Without Losing Your Rankings

Migrations go wrong quietly. The new site launches, everyone is pleased with how it looks, and nothing obviously breaks. Six weeks later somebody notices organic traffic is down a third and nobody can say precisely when it started.

The cause is nearly always the same, and it is nearly always mundane: URLs that changed and were never mapped to their replacements. Not the design, not the platform, not the copy. The redirect map.

What counts as a migration

More than people expect. Any of these carries the same risk, because all of them can change URLs or how they are served:

• Moving to a new domain
• Changing platform or CMS, even on the same domain
• A redesign that changes URL structure
• Consolidating several sites into one
• Moving from HTTP to HTTPS, or between www and non-www
• Restructuring your URL scheme — adding or removing a /blog/ prefix, say

The last one gets underestimated constantly. "We are only tidying the URLs" is a full migration with a friendly name.

Before you build anything

1. Inventory every URL you currently have

Not the ones in your CMS. All of them. Pull from four sources and merge, because each one knows about pages the others do not:

1. 1A full crawl of the live site
2. 2Your XML sitemaps
3. 3Search Console — every URL that has received an impression in the last twelve months
4. 4Server access logs, which are the only source that reveals orphan pages nothing links to any more

The log file step is the one people skip and the one that saves them. Old landing pages and campaign URLs with real backlinks almost never appear in a crawl, because nothing on the site points at them any more.

2. Record what each URL is currently worth

Against every URL, note organic sessions, impressions, ranking keywords and referring domains. This becomes your baseline. Without it you cannot tell after launch whether a drop is real or seasonal, and you cannot prioritise which broken redirect to fix first.

3. Build the redirect map

One row per old URL, one destination each. This is the single most important artefact of the whole project.

Blanket-redirecting orphans to the homepage feels safe and is not. It gets treated as a soft 404, so you lose the signal anyway, and a visitor who clicked a specific link lands somewhere useless. A 410 is cleaner and more honest.

While you build

• Block staging from indexing. HTTP authentication is the reliable way. A noindex tag depends on a tag nobody forgets to remove.
• Keep staging off your live domain if you can, and never make it publicly reachable without authentication.
• Test redirects on staging by pointing your redirect rules at it and checking a sample by hand.
• Carry the metadata across. Titles, meta descriptions, canonicals, structured data and image alt text are all part of what is currently ranking.

On the first point: a staging site that gets indexed causes two problems at once. It competes with your live pages, and it is a security exposure in its own right — staging environments habitually run debug routes and seed data that production does not.

Launch day

1. 1Remove the staging block. Check robots.txt and check for noindex in both the page source and the X-Robots-Tag header. The header one is invisible in the source and is missed constantly.
2. 2Verify redirects with the real list. Not a sample — run the whole map and check each one returns 301 to the intended destination.
3. 3Check for chains. A → B → C should have been collapsed to A → C. Migrations layered on top of previous migrations are where chains breed.
4. 4Submit the new sitemap in Search Console, containing only canonical, indexable, final URLs.
5. 5Keep the old sitemap live for a while. It helps crawlers rediscover old URLs and follow the redirects sooner.
6. 6File a change of address in Search Console if the domain changed.
7. 7Confirm analytics still fires, and annotate the launch date so future you can find it.

The month after

This is where a migration is actually won or lost, and it is where attention usually evaporates because the launch is done.

• Watch 404s daily for the first two weeks. Server logs beat any tool here — they show real requests for URLs you did not map.
• Track indexation. Pages indexed should climb toward your old total. A flat line means something is blocking it.
• Compare against your baseline page by page, not just in aggregate. A site-wide average hides a category that lost everything.
• Expect some volatility. Rankings wobble for two to four weeks after a well-executed migration. That is normal. A sustained drop past six weeks is not.

Every 404 in your logs after launch is a URL somebody still thinks exists. Some of them have links pointing at them.

The mistakes that cost the most

One security item while you are in there

A migration is the ideal moment to fix the configuration layer, because you are already touching the edge and there is a change window.

Set your security headers, cookie flags and HTTPS redirects on the new platform from day one rather than retrofitting them later — the security headers checklist covers the full set. It is also worth confirming that nothing from the old build is still reachable: forgotten admin paths and development routes survive migrations remarkably well.