Can a website migration really happen without any loss in rankings?

What justifies this statement from Google?

John Mueller seeks to reassure SEOs facing a terrifying scenario: website migration. He presents a theoretical framework where, if everything is done correctly, the damages are contained. The underlying message? Google knows how to manage migrations — as long as we make it easier for them.

However, behind this reassuring formula lie heavy assumptions. 'Appropriate redirects': which ones, exactly? 301 permanents, sure, but at what granularity? 'No significant changes to content': significant according to whom, Google or the client redesigning their site?

What types of migrations are involved?

Mueller talks about domain changes (example.com → newbrand.com) and restructuring of the hierarchy (/blog/article → /resources/article). These are the two classic cases where the identity of URLs changes significantly.

But he deliberately omits hybrid migrations — those that combine graphic redesign, editorial rewriting, and a new CMS. In these cases, the impact is never minimal, regardless of the redirects. The crawl budget explodes, behavioral signals change, and Google has to recalculate the relevance of hundreds of pages.

What does 'minimal impact' really mean?

Google provides no figures. 'Minimal' could mean -5% organic traffic for a stable site, or -30% for an e-commerce site during peak season. The term is intentionally vague.

In reality, even a perfect migration generates a floating period. Google recrawls, reevaluates, updates its index. This window lasts between 2 to 8 weeks depending on the site's crawl frequency. During this time, fluctuations are normal — and rarely 'minimal' from the client's perspective.

• Permanent 301 redirects: mandatory, but insufficient if misconfigured (chains, loops, accidental 302s)
• Stable content: do not redesign the content at the same time as the technical aspects — that’s the classic trap
• Consistent structure: if the hierarchy changes, maintain an equivalent logic of depth and internal linking
• GSC Monitoring: watch for 404 errors, deindexed pages, crawl drops — that’s where failures are detected
• Timing: never during peak season, never just before a major algorithm update — common sense, but too often ignored

Does this statement reflect the reality on the ground?

Partially. Google does know how to manage migrations — that's true. But the term 'minimal impact' is misleading. On sites with 500+ pages, I have rarely seen a migration without at least 10-15% volatility for 4 to 6 weeks. And that’s even with a flawless plan.

The real problem is that Mueller does not differentiate between simple migrations (domain change, identical hierarchy) and complex migrations (redesign + restructuring + new CMS). In the latter case, the impact is never minimal. [To be verified]: Google does not publish any aggregated data on average volatility post-migration.

What are the blind spots in this statement?

Mueller does not address the issue of crawl budget. During a migration, Google must recrawl massively. If the site generates many new URLs (pagination, facets, duplicates), the budget dilutes. Result: some strategic pages are not recrawled quickly enough, causing temporary ranking drops.

Another silence: the Core Web Vitals. Changing CMS or servers often alters performance. If the new site is slower, Google incorporates that signal. The impact is no longer 'minimal'; it becomes structural. The same goes for internal linking: if the new hierarchy breaks the internal PageRank, some pages lose juice.

When does this rule not apply?

When there is a massive editorial rewrite. Even with perfect redirects, if the content changes radically (tone, length, keywords), Google considers that new pages. It must reevaluate relevance, and that takes time. Rankings fluctuate, sometimes significantly.

Another case: multilingual or multi-regional sites. Changing the hreflang structure or subdomains (fr.example.com → example.com/fr/) is a separate project. Google must re-associate language variants. If just one hreflang tag is wrong, it's a drop for an entire language.

What should you do before launching a migration?

Map the existing structure: crawl the current site (Screaming Frog, Sitebulb), extract all indexed URLs, note strategic pages (those generating organic traffic). This is the foundation of the redirect plan. Without this map, it's impossible to ensure that each URL will be redirected correctly.

Next, define the new hierarchy while maintaining equivalent depth logic. If a page was at /cat/subcat/product and moves to /product, it loses semantic context. Google must recalculate its relevance. It's better to retain a similar structure, even if slightly simplified.

What mistakes should you avoid during migration?

The worst: launching the migration on a Friday night. If a bug occurs, the site remains down all weekend. Always migrate at the start of the week, with the entire team available. Another classic pitfall: redirect chains (A → B → C). Google follows them, but it consumes crawl budget and dilutes PageRank.

Never forget to update the XML sitemap with the new URLs and submit it immediately in GSC. Google recrawls faster if it has a clear plan. The same goes for the robots.txt file: check that there are no blocking rules inherited from the dev version.

How can you verify that the migration is successful?

In GSC, monitor 404 errors: if they spike, it's an indication that some redirects have failed. Also check the indexation rate: if pages are disappearing from the index for no reason, it means Google is not following the 301s or it's erroneously detecting content as noindex.

Compare the average positions on strategic queries (GSC, Performance module). A volatility of ±3 positions is normal for 4 weeks. Beyond that, dig deeper: content issues, linking, or technical performance. Also monitor the daily crawl: if it drops suddenly, Google is encountering server errors or duplicate content.

• Crawl the site before/after and compare both exports (URLs, HTTP codes, title/meta tags)
• Manually test a sample of 50 old URLs to ensure that the 301s are working
• Set up GSC alerts for 404 errors and deindexed pages
• Check that the new site does not have erroneous noindex or canonical tags inherited from staging
• Monitor the Core Web Vitals: LCP, CLS, INP — a slower site = guaranteed negative impact
• Implement a position monitoring tool (SEMrush, Ahrefs) to detect drops before the client notices them