Site Migration Without Losing Your Rankings

Published 2026-09-12 · 8 min read · by the isaeo team

The two mistakes

Migrations go wrong in dozens of ways, but two account for most of the serious traffic losses.

First: no inventory. If you don't have a complete list of the old URLs before the old site goes away, you cannot verify that anything still resolves. People discover missing pages months later, from a customer complaint.

Second: lazy redirect mapping. Pointing every retired URL at the homepage is fast and destroys the value of each one. Engines treat a redirect to an irrelevant destination as a soft 404, so the page's accumulated signals evaporate rather than transfer.

Everything below is in service of avoiding those two.

Before: inventory and mapping

1. Crawl the old site completely and export every URL with its title, H1, status and canonical. Do this while the old site is still live. Keep the file; it's your only source of truth afterwards.
2. Add URLs the crawl won't find — from analytics (anything with traffic in the last year), Search Console, your sitemap, and any campaign landing pages linked from elsewhere.
3. Record the baseline. Scores, indexable page count, top pages by traffic. Without a before, you can't tell whether the after is bad.
4. Map old → new, one row per URL. Every old URL gets an explicit destination. Where nothing equivalent exists, decide deliberately: closest parent category, or a genuine 410 if the content is truly gone.
5. Flag your top 50 pages and check their mappings by hand. These carry most of the value; they deserve individual attention.

Launch day

1. Redirects live at cutover, not the following week. Use 301 for permanent moves.
2. One hop, not chains. Old → new directly. See redirect chains.
3. Check robots.txt on the new site immediately. A staging Disallow: / shipping to production is the single most common migration catastrophe.
4. Check for stray noindex tags carried over from staging templates.
5. Submit the new sitemap and keep the old one available briefly so engines re-crawl the retired URLs and see the redirects.
6. Verify canonicals point at the new domain, not the old one or staging.

After: the first two weeks

This is the one situation where daily crawling earns its keep. You're watching for problems that only surface under real traffic and real crawler behaviour.

• Day 1: crawl the new site. Compare the page count to your baseline. A large shortfall means pages aren't reachable.
• Day 1: spot-check 20 old URLs from your inventory, including the top 10 by traffic. Each should 301 in one hop to a relevant page.
• Days 2–14: crawl daily and watch the diff — new 404s, new noindex, dropping page counts. See change tracking.
• Week 2: re-check search console coverage and fix anything reported as excluded that shouldn't be.

Expect a dip. A modest, recovering fluctuation over two to four weeks is normal even for a well-executed migration. What isn't normal is a decline that keeps deepening — that's a signal something is still broken.

The staging-site trap

Two failure modes worth their own section, because both are silent and both are common.

Staging gets indexed. A crawlable staging domain competes with production for the same content. Protect it with HTTP auth — robots.txt alone doesn't prevent indexing if something links to it.

Staging artefacts ship to production. Canonical tags pointing at the staging hostname, absolute links to staging assets, or the blanket robots disallow. Grep the built output for your staging hostname before you deploy — it takes seconds and catches the whole class of problem.