Should you really keep your URLs during a site migration?

Why does Google emphasize retaining URLs?

During a site migration, Google must recrawl the entire site, identify new addresses, transfer accumulated signals (authority, history, backlinks), and update its index. Every URL change requires the engine to establish matches between old and new content using 301 redirects.

By keeping the same URL structure, this layer of complexity is eliminated. The engine doesn't need to understand a new page naming logic, nor redistribute signals. Only the technical elements change: domain, server, possibly CMS. The crawl remains predictable, with familiar patterns.

This approach drastically reduces the processing time on Google's side. The bots recognize the structure, spot simple redirects (domain change only), and transfer data faster. Ranking fluctuations, which are inevitable during migration, remain confined to a shorter period.

What actually happens when everything is changed at once?

Simultaneously modifying both the technical platform AND the URL structure creates a situation where Google must solve two distinct problems. On one side, it has to understand the new server architecture, response times, and crawl management. On the other, it needs to map the old site to the new with completely different URL patterns.

Historical signals (page age, link depth, internal PageRank distribution) must be recalculated. External backlinks point to addresses that no longer exist. Even with perfect redirects, each external link now goes through an additional jump, which can slightly dilute the authority transmitted.

The crawl budget depletes faster. The bots must discover new URLs, check redirects, and index content seen as new (even if identical). The instability period extends, sometimes from several weeks to several months depending on the size of the site.

In what cases does this recommendation not apply?

This guideline assumes that the current structure is viable. If your URLs are catastrophic (chaotic dynamic parameters, session IDs, excessive depth), retaining this structure amounts to perpetuating a major SEO handicap.

Google does not say that one should NEVER restructure. It warns that restructuring during a migration amplifies the risks. The cautious approach is to migrate first with a constant structure, stabilize positions, THEN progressively restructure once the site is consolidated on its new platform.

• Keeping URLs speeds up the transfer of signals and shortens the duration of organic traffic fluctuations
• Changing both the platform and structure simultaneously increases complexity on Google's end and prolongs instability
• A restructuring remains possible and sometimes necessary, but ideally after stabilizing the technical migration
• The crawl budget depletes faster when Google must discover new URLs AND understand a new architecture
• External backlinks go through an extra jump if URLs change, potentially diluting the authority transmitted

Is this recommendation consistent with field observations?

Absolutely. Migrations with URL retention consistently show more stable traffic curves. Sites that simultaneously restructure often experience 3 to 6 months of rollercoaster effects, with pages disappearing and then reappearing in the index, and rankings swinging violently.

What we observe: Simple redirects (domain A to domain B, same path) are processed within a few days to a few weeks. Complex redirects (new hierarchy, new patterns) sometimes take several months before Google recalculates all signals. The engine seems to handle these cases more cautiously, as if it checks more thoroughly before fully transferring authority.

What nuances should be considered regarding this statement?

Google does not specify the optimal delay between migration and restructuring. Three months? Six months? It depends on the size of the site, its crawl frequency, and its overall authority. A site crawled daily stabilizes faster than one crawled weekly. [To be verified] on each project with close monitoring.

Another point: this recommendation presumes that your current structure is not toxic. If your URLs contain parameters that generate massive duplicate content, or if your depth exceeds 7-8 clicks from the homepage, maintaining this structure may cause more harm than good. In that case, the choice is: immediate clean migration (with restructuring) or rapid migration followed by redesign (with a double period of instability).

Third nuance: the size of the site changes everything. Migrating 50 pages with a new structure remains manageable. Migrating 50,000 pages changes the game. The risk of error (missing redirects, loops, mismatches) skyrockets. Keeping the URLs eliminates a major source of human error during mapping.

In what scenarios should this advice be ignored?

When the current architecture is so flawed that it undermines crawling and indexing. Example: an e-commerce store with filters generating thousands of duplicate URLs, no proper canonicalization, product pages buried 8 clicks deep. Here, migrating with identical structure means migrating a problem.

Another case: a complete redesign with a radical change in editorial model. Switching from a classic blog to a hub-and-spoke structure, or from a product catalog to an inverted category logic. Keeping old URLs would create semantic dissonance between the address and the actual content of the page.

What should be done concretely before a migration?

Start by auditing your current structure. List all indexed URLs (Search Console, Screaming Frog crawl), identify major issues: duplicate content, excessive depth, chaotic parameters, existing chain redirects. If the flaws are minor (a few malformed URLs, a few redirects to clean up), keep the structure and correct these details AFTER migration.

If the flaws are structural (thousands of toxic URLs, unreadable hierarchy), you have two options. First option: migrate cleanly with a new structure AND a significant budget to manage the lengthy instability period (enhanced monitoring, weekly adjustments, patience over 6+ months). Second option: migrate quickly with an identical structure, stabilize in 4-6 weeks, THEN restructure in phase 2 with a detailed redirect plan.

Prepare your mapping file even if you are keeping the URLs. Ensure every old address redirects properly to its new version (domain change only). Test in a staging environment. Use a tool like Redirect Path or Screaming Frog to validate that all redirects are 301, with no chains or loops.

What mistakes should be absolutely avoided?

Never underestimate the complexity of mapping if you decide to restructure. Regex that work on 80% of URLs can create catastrophes on the remaining 20% (special characters, accents, edge-case parameters). Manually validate URLs with high traffic and authority. A broken redirect on your most backlinked page can cost 30% of your SEO traffic.

Avoid temporary redirects (302) during a migration. Google interprets them as provisional and does not transfer signals. Only 301 (permanent) redirects allow for the complete transfer. Check the actual HTTP headers, not just what your CMS displays in the interface.

Don’t initiate migration on a Friday night. You need real-time monitoring during the first 48 hours: error codes, crawl time, organic traffic, positions on strategic queries. Plan for a Tuesday or Wednesday, during a medium traffic period (not during a seasonal peak), with your technical team available.

How can you check that everything is going well post-migration?

Monitor Search Console daily: 4xx/5xx errors, non-indexed pages, coverage, Core Web Vitals. In the first weeks, Google will massively recrawl. Errors appear quickly. Immediately fix any errors on strategic URLs.

Keep an eye on your positions for 20-30 priority queries. Fluctuations of ±5 positions are normal. Abrupt drops (from page 1 to page 3+) indicate a problem: missing redirect, lost content, technical issue blocking. Investigate urgently.

Check that the external backlinks resolve correctly. Crawl your main destination pages from an external tool (Ahrefs, Majestic). Links must point to the new URLs via clean 301 redirects, without chains. If you detect chains (old URL → intermediate redirect → new URL), simplify immediately.

• Audit the current structure and list indexed URLs before making any migration decisions
• Prepare a complete mapping file even for URL retention (domain validation)
• Test all redirects in a staging environment before going live
• Use only permanent 301 redirects, never temporary 302
• Monitor Search Console daily during the first 2 weeks post-migration
• Manually verify redirects on the 50 pages with the most organic traffic