How to Migrate a Site Without Losing Rankings

Site migrations are where good rankings go to die. A redesign, a platform switch, a domain change, an HTTP-to-HTTPS move — each is a chance to accidentally throw away years of accumulated SEO equity in a single afternoon. The traffic drop usually shows up two weeks later, once everyone has moved on and nobody connects the dots.

It doesn’t have to be that way. Migrations are risky, but the risk is almost entirely manageable. Here’s the playbook we follow.

Preserve URLs whenever you can

The single best redirect is the one you never have to write. Before anything else, ask a blunt question: does this URL actually need to change? Often the answer is no, and the whole project gets safer.

If you’re changing platform or design but the content is staying, fight to keep the existing URL structure. Every URL you preserve is one less redirect to map, one less chance of a chain, one less thing to break. Only change URLs where there’s a real reason — a genuinely better structure, a language path, a consolidation.

When URLs must change, map every old URL to its closest new equivalent. Not the homepage — the closest matching page. A lazy blanket redirect to / is one of the fastest ways to lose rankings, because Google treats it as a soft 404 and drops the old page’s authority entirely.

Build the redirect map before launch

Export a full list of your current indexed URLs — from your sitemap, your analytics, and a crawl of the live site. That’s your source of truth. For each one, decide its fate:

• Stays the same → nothing to do.
• Moves → 301 redirect to the new URL.
• Gone for good → let it 404 (or 410) deliberately, don’t fake it.

Use 301 (permanent) redirects, not 302s — a 302 tells Google the move is temporary and it hangs on to the old URL. Avoid redirect chains (A → B → C); point every old URL straight to its final destination. And double-check you’re not redirecting into pages that are themselves blocked or noindexed.

A migration is only as good as its redirect map. Everything else is detail.

Run pre-launch checks on staging

Never discover problems in production. On the staging site, verify the things that silently kill migrations:

• Indexability — make sure the staging noindex and robots.txt disallow rules are removed at launch. Shipping a site that tells Google “don’t index me” is the classic catastrophic mistake.
• Canonicals and hreflang — confirm they point to the new URLs, not the staging domain or the old site.
• Metadata and structured data — titles, descriptions and schema should carry over, not reset to defaults.
• Internal links — update them to point at the new URLs directly, so you’re not relying on redirects internally. This is where solid technical foundations built in from day one pay off.

Crawl the staging site with a tool like Screaming Frog and compare it against the old one, page for page.

Monitor obsessively after go-live

The work isn’t done at launch — that’s when it starts. In the first hours, crawl the live site and check that redirects resolve in a single hop and return 200s at the destination. Submit the new sitemap in Google Search Console and keep an eye on the Coverage and Crawl Stats reports for spikes in errors.

Watch for weeks, not days. Some ranking fluctuation is normal as Google re-crawls and re-processes everything; a total collapse is not. If traffic craters, your redirect map almost certainly has a hole in it — find the orphaned old URLs and patch them.

Migrations reward the meticulous. If you’re planning a replatform, a redesign or a domain move and want it done without the traffic dip, that’s exactly the kind of website development work we do — request a free audit and we’ll pressure-test the plan before anything ships.