How to Migrate a Website Without Losing Traffic: SEO Evidence

Executive brief

Key takeaways

The decision to change CMS, overhaul information architecture, or change a domain always carries a clear commercial risk: the sudden loss of accumulated organic traffic. Instead of avoiding this necessary technical move out of fear, teams must treat the migration not as a magical transition, but as an auditable transfer of relevance.

In simple terms, an SEO website migration means instructing search engines that a page has permanently moved to a new address. If done correctly, the "reputation" (ranking signals and history) is passed on; if done incorrectly, search engines view the new URLs as beginner pages, tossing out years of work.

The evidence base and methodology we use here come directly from Google Search Central’s official documentation on site moves, alongside validated observations extracted from server logs and Google Search Console API data.

How to Prepare and Execute the Migration

1. Pre-migration: The URL Inventory

The most common mistake is relying solely on simulated crawler tools (like Screaming Frog) to map the current site structure. Crawlers do not see orphan pages that still receive traffic or hold valuable external backlinks.

To generate actual evidence of what needs redirecting, combine three sources:

• Indexed pages in Google Search Console (filter by clicks and impressions over the last 12 months).
• Most visited pages in Google Analytics or your preferred analytics system.
• The complete map from your technical crawler.

2. The Redirect Mapping (From → To)

Create a strict table where every old URL has a corresponding match in the new structure. Use strict logical criteria:

Old Page Scenario	Decision and Destination (New URL)
Page exists and remains relevant	301 redirect to the equivalent new URL.
Product/service discontinued	301 redirect to the closest parent category.
Page has no value and no equivalent	Return a 404 or 410 HTTP code (intentional, signaling removal).

[!WARNING] Never redirect all old pages in bulk (catch-all) to the Homepage. Google classifies this practice as a "soft 404" and will not transfer the authority of the individual URLs to the new Home.

3. Testing and Launch

Before pointing the DNS or releasing the public production build, test the redirects in a staging environment.

• The returned HTTP code must be strictly 301 (Moved Permanently), not 302 or JavaScript-based redirects, which have an inconsistent history of passing authority quickly.
• The canonical directive (<link rel="canonical">) of the new site should point to itself (self-referencing).

At the moment of launch:

1. Remove robots.txt blocks and noindex tags from the new environment.
2. Activate the 301 rules on the server (Edge, Nginx, Apache).
3. Submit the new XML Sitemap immediately in Search Console.

Limitations and False Positives Post-Launch

In the first 48 to 72 hours after a severe structural migration, real-time reports often show massive drops. This happens because the old traffic stops instantly, and the search engine's index is still processing the transition. This very short-term drop is a false positive of a disaster.

The technical limitation of the process lies in the crawl budget. Search engines won't instantly reprocess millions of URLs at once, which means traffic and visibility metrics typically take between two and six weeks to stabilize.

Verifiable Action Plan

To confirm that the migration is succeeding, validate these four steps:

1. Inspect HTTP headers: Use command-line tools (curl -I) or extensions to confirm that the old URL returns a 301 code, without multiple chains (redirect loops).
2. Monitor the Indexing report: Track the "Pages" tab in Search Console. The volume of indexed URLs on the old site should drop progressively as it rises in the new property or structure.
3. Validate unintentional 404 errors: Review Search Console reports weekly in the first month to spot URLs that should have been mapped but fell into a 404 error.
4. Compare vital metrics: Analyze the parity of impressions and clicks for the core keywords that sustain revenue.

If your team needs to consistently audit directives and monitor post-migration technical health without relying only on manual inspections, the Remountly technical monitoring platform can help automate regression detection before they become SERP losses.

Direct answers

Frequently asked questions

Is it possible to migrate a site with zero risk of traffic loss?

No. Temporary fluctuations (days to weeks) are part of Google's re-indexing process, even when all guidelines are strictly followed. The goal is to prevent permanent losses.

How long does it take for traffic to recover post-migration?

Depending on the site size and search engine crawl capacity, full recovery typically takes between two and six weeks.