SEO Migration Without Losing Rankings

A site migration is the moment when it's easiest to lose what you built over years — your Google rankings. Changing the domain, CMS, URL structure or moving to HTTPS without a plan can wipe out organic traffic in a week. The good news: a well-executed migration is almost invisible to the search engine, and 301 redirects don't lose PageRank. This guide explains how to migrate without losing visibility — based on Google's official guidance.

A domain, CMS or URL-structure change without a plan can wipe out organic traffic in a week. I explain how to migrate without losing visibility: a complete 301 redirect map, a stage-by-stage checklist and the most common mistakes to avoid.

Google's two migration categories

Google splits site moves into two groups, each with its own guide:

• Without URL changes — paths stay identical; only hosting/infrastructure changes (server, IP, DNS). You don't use the Change of Address tool — Google detects it.
• With URL changes — the domain, protocol (HTTP→HTTPS) or URL structure changes. Requires 301 redirects, sitemap updates and, for a domain change, the Change of Address tool.

Key point: it's whether URLs change that decides, not whether the domain changes. Restructuring URLs on the same domain is still a "with URL changes" move.

Types of migration — what exactly changes

"Migration" covers several very different operations, each with its own risk profile. Before you start, name exactly what you're changing:

The safest rule: change one thing at a time. Combining a domain change with a URL restructure and a redesign in one launch means that when traffic drops, you don't know what killed it. If you must do everything, split it into separate, measurable phases — advice John Mueller repeats too.

Redirects: 301 vs 302 vs 308 — and the equity myth

• 301 (permanent) — the preferred signal for moves; Google consolidates signals to the new address and treats it as canonical.
• 308 — Google treats it identically to 301 for SEO (the difference is only at the HTTP level: 308 preserves the request method).
• 302/307 (temporary) — Google usually keeps the old URL canonical. Not suitable for migrations.

The key fact that kills the myths: 3xx redirects don't lose PageRank (Gary Illyes confirmed this back in 2016). Mind the two mechanisms: PageRank flows through all 3xx, but it's permanent redirects (301/308) that tell Google which URL to index. So use 301/308 for migrations.

The golden rule: a 1:1 redirect map

• Map every indexed URL (Search Console export + crawl + analytics + server logs + sitemaps).
• Redirect 1:1 to the most topically similar equivalent — not en masse to the homepage (Google treats that as a "soft 404" and those URLs drop from the index).
• Avoid chains (A→B→C) — redirect straight to the target in one hop.
• Keep redirects in place a long time — Google recommends at least a year, ideally permanently.

How to build the redirect map in practice

A 1:1 map sounds simple until you have 40,000 URLs. Here's a proven process:

1. 1.Collect the full list of source URLs from multiple sources at once — because no single one is complete: Search Console export (Pages + Performance), a crawl (Screaming Frog, Sitebulb), sitemaps, server logs (showing what Googlebot actually visits) and URLs with backlinks (Ahrefs/Majestic).
2. 2.De-duplicate and classify — which URLs have traffic, rankings or links (priority) and which are junk (parameters, sessions) to cut with 404/410, not redirect.
3. 3.Match 1:1 to the closest topical equivalent on the new structure. When the URL pattern changes (e.g. /blog/{id} → /blog/{slug}), you can often automate this with a rule or a spreadsheet map.
4. 4.Handle URLs with no equivalent. If content disappears for good, redirect to the closest parent category — not the homepage. When there's no sensible target, a deliberate 410 (Gone) beats a misleading redirect.
5. 5.Test the map on staging — verify every old URL lands on a 200 OK in a single hop, with no chains or loops.

Mind parameters and variants: settle canonical versions (sort parameters, pagination, letter case, trailing slash) and redirect to them consistently, so you don't create new duplicates after the migration.

Multilingual migration — hreflang and regional variants

If you run language versions, migration is the highest-risk moment for `hreflang`. The rules:

• Update hreflang annotations to the new URLs in the same launch — stale pointers to old addresses break language mapping.
• hreflang must be reciprocal and canonical — each version points to all the others and itself, and the pointers lead to destination URLs (post-301), not to redirects.
• Don't combine a domain change with moving languages from subdirectories to subdomains in one step — those are two different architecture changes that are hard to diagnose together.

A migration checklist for keeping rankings

The Change of Address tool (domain change only) — an important 2026 change

The Change of Address tool in Search Console applies only to a domain change (not HTTPS or path changes). As of June 2026, Google clarified you must submit it for all variants of the old domain — `www` and non-`www` plus subdomains — even ones you don't use, because the tool doesn't move subdomains automatically. Requirement: all variants verified in GSC, with 301 redirects already live.

Launch day — a step-by-step runbook

Deploying a migration is surgery on a living system. Order and control are everything:

1. 1.A low-traffic window. Pick the quietest time, but avoid Friday evening — you want people on deck if something goes wrong.
2. 2.Remove staging blocks. `Disallow: /`, `noindex`, password/IP — take these down first and verify immediately.
3. 3.Enable 301/308 redirects and check a sample of critical URLs (most traffic/links) — one hop, 200 OK at the end.
4. 4.Swap internal links to the new addresses in templates, menus, the sitemap and structured data — don't rely on redirects alone.
5. 5.Submit the new sitemap to Google Search Console and Bing Webmaster Tools; for a domain change, run the Change of Address tool (all variants).
6. 6.Check the technical basics: response codes, canonical, hreflang, content rendering without a JS wall, the HTTPS certificate.
7. 7.Turn on monitoring and keep logs from minute zero — they'll be invaluable for diagnosis.

Post-migration monitoring — a timeline

A migration doesn't end at launch — it ends when signals stabilize. What to check and when:

• Day 0–1: response codes (no mass 404/5xx), correct 301s, indexability (no accidental `noindex`), working analytics, sitemap accepted in GSC.
• Days 2–7: the "Pages" report in GSC (a rise in "Discovered/Crawled – not indexed"?), Crawl Stats (is Googlebot fetching the new URLs), first rankings and traffic vs baseline, errors in the Enhancements report (schema).
• Weeks 2–4: re-indexing of new addresses, ranking stabilization, a drop in old URLs in the index, monitoring 404s from external links.
• Week 4+: a full comparison to baseline (traffic, rankings, conversions). CrUX is a 28-day rolling average, so Core Web Vitals "catch up" to reality with a lag.

Keep old redirects for at least a year. Only when logs and GSC show the old URLs are no longer visited or indexed should you consider retiring them.

A rollback plan — when and how to back out

Every serious migration needs a plan B. Before you deploy, prepare: a full backup of the old version (files + database + server config), the ability to quickly restore DNS/server, and the saved old URL map. Set rollback criteria upfront — e.g. mass 5xx, a 404 spike on key pages, site-wide broken canonicalization. If the problem is local (a few bad redirects), fix it live; reserve a full rollback for systemic failures, because it is itself another migration and another shock to the index.

The most common mistakes that kill traffic

• Missing redirects (old URLs return 404) or bulk-redirecting everything to the homepage (soft 404).
• A staging block left in production — `Disallow: /` in `robots.txt` or `noindex` — a classic disaster that makes the whole site vanish.
• A canonical pointing to the staging host.
• Changing content and URL structure at once — drops are hard to diagnose.
• A Core Web Vitals regression or lost structured data.

What to expect

Even with a perfect migration, temporary fluctuations are normal — Google must re-index and recompute signals. Google says that for a domain change, effects usually settle within a few weeks, while large sites may need a few months. A permanent drop with no rebound signals an error (bad redirects, a block, lost content) — start diagnosis with the "Pages" report and Crawl Stats in GSC. Mueller also advises splitting changes over time (domain separately, URL restructure separately, redesign separately) so you can tell what hurt.

Migration and AI visibility (GEO) — the overlooked part

A migration isn't only a risk for Google — it's a risk for your presence in ChatGPT, Perplexity and Copilot too. AI models source from indexes (largely Bing for ChatGPT/Copilot, its own crawl for Perplexity), so after a move you need to take care of both:

• Re-index in Bing, not just Google. Submit the new sitemap in Bing Webmaster Tools too — otherwise ChatGPT and Copilot will keep citing old, redirected URLs for weeks.
• Don't block AI bots. In the new `robots.txt`, make sure you allow GPTBot, OAI-SearchBot, PerplexityBot and Bingbot — easy to break when copying config from staging.
• Preserve entity and schema. After migration, keep structured data and `sameAs` consistent — they "glue" the new address to your entity so AI still knows it's the same brand.

In practice: after a major migration it's worth running an AI visibility audit, because models refresh their sources more slowly than Google.

---

I run SEO migrations without losing visibility — from the redirect map to post-launch monitoring — as part of technical SEO. Get in touch before you start; the cheapest mistakes to fix are the ones you never made.

Worth reading next:

• Core Web Vitals — how to improve LCP, INP and CLS
• Crawl Budget — how Google indexes a large site