Website Migration Without Losing Organic Traffic

A website migration is the single most common way a business loses organic demand it took years to earn. The loss is rarely dramatic on launch day. It shows up over the following weeks as pages drop out of the index, redirects miss, templates lose content, and nobody can tell whether the decline is the market or the move.

The good news is that migration losses are almost entirely preventable. They come from a short list of known faults, and each has a check that catches it before launch. This guide is that list, organised into four phases — before, staging, launch day and after — with a redirect-map standard, a parity checklist and a table for diagnosing what you see in the weeks after launch. It applies whether you are changing platform, design, URL structure, domain or all four at once (which we will argue against).

Why migrations lose traffic

Search engines have a model of your site: which URLs exist, what each one is about, how they link to one another, how they perform, and which external pages point at them. A migration invalidates part of that model. The question is whether you give the engine a clean path from the old model to the new one, or leave it to reconstruct the site from scratch while your competitors keep theirs.

In practice, traffic is lost through one or more of the following:

• URLs change without complete redirects. Old URLs return 404, links and authority pointing at them are wasted, and users landing from old results bounce.
• Content changes silently. The redesign shortens category descriptions, drops FAQ sections, replaces text with images — and pages that ranked for their content stop ranking.
• Templates change what machines see. Titles are regenerated, canonicals point elsewhere, headings are restructured, structured data is dropped, internal links move out of the HTML into JavaScript.
• Crawling is blocked or wasted. A staging noindex ships to production; robots.txt disallows the new paths; the new platform generates thousands of parameter URLs.
• Performance regresses. The new stack is heavier, Core Web Vitals slip from ‘Good’ to ‘Poor’, and a template-wide signal turns negative.
• Nobody measures. Without a baseline, the decline is attributed to seasonality until it is too late to trace.

Every one of these is detectable before launch. The rest of this guide is the detection.

The four kinds of migration, and their risk

Phase 1 — Before: baseline and inventory (4–8 weeks out)

The purpose of this phase is to know exactly what you have, so that you can prove what you kept. Everything here is exported, dated and stored somewhere the whole team can find it.

1. 01

   Export Search Console

   Performance data for the last 16 months by page and by query; the Pages report; sitemaps; Core Web Vitals; links. Use the API or a connector if the site is large — the UI export caps rows.

2. 02

   Export analytics by page group

   Organic sessions, conversions and revenue for the last 13 months, grouped by template (product, category, article, landing). Page groups, not individual URLs, are the unit you will judge the migration by.

3. 03

   Crawl the whole site

   A full crawl with JavaScript rendering: every URL, status, title, canonical, h1, word count, internal links in and out, structured data types, hreflang. This is your ‘before’ snapshot of what machines see.

4. 04

   Build the URL inventory

   Merge crawl URLs, sitemap URLs, Search Console URLs with impressions, analytics landing pages and URLs with external links. Deduplicate. Rank by clicks, conversions and referring domains. This list — not just the current sitemap — is what the redirect map must cover.

5. 05

   Decide content parity

   For each template, list what content will be kept, changed or removed, and who signs off. Removing content that ranks is a decision, not a side effect of the design.

6. 06

   Write the redirect map

   See the standard below. Have it reviewed by someone who did not write it.

7. 07

   Set the measurement plan

   Define the page groups, the baseline window, the comparison method (year-on-year and pre/post) and the thresholds that will trigger investigation. Agree who reads the numbers weekly.

8. 08

   Freeze

   Two weeks before launch, stop changing URLs and content on the old site. Every change after the freeze has to be reflected in the map and the inventory.

The redirect map: a standard that prevents most losses

Redirects are how the engine carries its model of the old site onto the new one. A good map is boring: exhaustive, one-to-one and permanent. A bad map is where most migration losses originate.

• One-to-one. Each old URL redirects to the single new URL that serves the same purpose. Redirecting a section to the home page or a category is a soft loss: the engine treats it as ‘page gone’ and the authority is not carried.
• One hop. Old → new, directly. Chains (old → older → new) leak signal and time out in some fetchers. Collapse any existing redirects into the new map.
• Permanent. Use 301 or 308. Use 302/307 only for genuinely temporary moves; engines treat them differently and may keep the old URL indexed.
• Complete. Cover every URL in the inventory — including URLs that currently redirect, URLs with external links but no traffic, image and PDF URLs that rank, and parameter variants that earned clicks.
• Pattern-based where safe, explicit where not. Rewrite rules handle regular patterns; the top few hundred URLs by value get explicit entries and explicit tests.
• Tested before launch. A script requests every old URL against staging (with host overrides) and checks that the final response is 200 at the mapped destination, in one hop.
• Kept for at least a year, ideally indefinitely. External links to old URLs persist for years. Removing redirects later re-creates the loss.

Phase 2 — Staging: parity checks

Staging is where the new site is compared with the old one, template by template, from a machine’s point of view. The aim is parity or better on everything that influences crawling, indexing, understanding and performance. Run a full crawl of staging with the same settings as the baseline crawl and compare.

Phase 3 — Launch day

Launch is a sequence, not a switch. Order matters because some steps depend on others, and because the first hours after launch are when crawlers form their impression of the new site.

1. 01

   Choose a low-traffic window with people available

   Mid-week, outside peak hours, with engineering, SEO and analytics owners on hand for the rest of the day and the following morning.

2. 02

   Deploy redirects before or with the switch

   Redirects must be live the moment the old URLs stop serving. A gap of hours produces a wave of 404s that takes weeks to clear.

3. 03

   Remove staging protection and confirm

   Fetch the home page and a page from every template on the live hostname: 200, no noindex, correct canonical, correct robots.txt.

4. 04

   Submit sitemaps

   Submit the new XML sitemaps in Search Console and Bing Webmaster Tools. Keep the old sitemap files available temporarily so crawlers find the redirects faster, then retire them after a few weeks.

5. 05

   For domain changes, use Change of Address

   Verify the new domain in Search Console, then use the Change of Address tool from the old property. Update every external reference you control: profiles, directories, email signatures, ad accounts.

6. 06

   Run the live redirect test

   The same script as staging, now against production, for the full inventory. Fix anything that fails immediately.

7. 07

   Watch the logs

   For the first 24 hours, monitor bot requests for 5xx, 404 spikes and response times. A surge of crawl activity is expected; errors are not.

8. 08

   Inspect key URLs

   URL-inspect a page from each template in Search Console and request indexing for a handful of the most valuable pages. Do not try to request everything; the sitemap does that job.

Phase 4 — After: the first eight weeks

Some movement after launch is normal: the engine is recrawling, reconciling redirects and re-evaluating templates. The job in this phase is to distinguish expected movement from damage, and to act quickly on the latter. Review daily for the first week, then weekly, against the baseline page groups.

• Keep a change log from launch onward. When something moves, the first question is ‘what changed?’, and the log answers it.
• Re-crawl production at week one and week four and diff against the baseline crawl.
• At week eight, produce the comparison: organic sessions, conversions and revenue by page group versus the baseline, year-on-year and pre/post, with confounders stated. That document is the migration’s verdict.

Common mistakes

• Treating the migration as a design or engineering project with SEO ‘reviewed at the end’. By then the URL decisions are made.
• Building the redirect map from the current sitemap only, and missing the old URLs that still carry links.
• Redirecting discontinued pages to the home page instead of the nearest equivalent.
• Shipping the staging noindex or a staging canonical to production. It happens more often than anyone admits.
• Regenerating titles and descriptions from a template and losing years of tested wording.
• Removing ‘SEO text’ from category pages because the new design has no place for it.
• Launching on a Friday, or before a peak season, with nobody watching.
• Turning redirects off after six months ‘to clean up’.
• Judging the migration by rankings for a few keywords instead of demand by page group.

When to bring in help

Most of this guide can be run by an in-house team with a crawler and discipline. Bring in a specialist when the site is large enough that the inventory and redirect logic are non-trivial, when organic revenue is material enough that a bad quarter would be noticed by the board, or when the migration combines several changes at once and you need an independent view of the sequencing. The Technical SEO work we do with engineering teams is most often exactly this: planning, parity testing and post-launch verification for a move that cannot be allowed to fail.

The bottom line

• Migration losses come from known, detectable faults: missing redirects, lost content, changed templates, blocked crawling, regressed performance and absent measurement.
• Baseline everything before the freeze; the URL inventory and page-group data are what you will judge the move by.
• Redirects are one-to-one, one hop, permanent, complete and tested — and they stay in place.
• Test staging for parity from a machine’s point of view, template by template.
• Launch in sequence with people watching; then review against the baseline for eight weeks and act on the symptom table.

Frequently asked questions

How long does organic traffic take to recover after a migration?

A well-executed migration that preserves URLs and content usually stabilises within four to eight weeks. Migrations that change URLs, templates and content together can take a quarter or more, and some losses from removed content never come back because the content is gone. Recovery time is mostly a function of redirect coverage, content parity and crawl speed.

Should I redesign and replatform at the same time?

Avoid it where you can. Combining changes multiplies the risk and removes your ability to diagnose what caused a decline. If business constraints force it, preserve URLs through the change, hold content parity strictly, and accept a longer and more carefully monitored recovery period.

Do I need to keep the old domain after a domain change?

Yes, and keep the redirects live indefinitely. External links to the old domain will persist for years. Letting the old domain lapse breaks every one of them and can allow someone else to register it.

Is a 301 or a 308 redirect better for SEO?

Both are permanent redirects and both carry signals to the destination. 308 additionally preserves the request method, which matters for forms and APIs but not for search. Use whichever your platform handles cleanly; the important thing is that the redirect is permanent and single-hop.

Should I request indexing for all the new URLs?

No. Submit accurate XML sitemaps and let the crawler work; a site-wide migration is exactly what sitemaps are for. Use manual indexing requests for a handful of the most valuable pages only — they are rate-limited and are not faster at scale.

What if traffic falls and I cannot find the cause?

Check the emergency cases first — noindex, robots.txt, canonicals and bot protection — then compare the affected page group’s old and new crawl rows line by line. If it is still unclear, the change log and the log files usually hold the answer. This is also the point at which an outside review pays for itself quickly.

How this guide was put together

• The checklist reflects Lucidens migration practice and Google’s published guidance on site moves. Phase timings are typical, not guaranteed, and depend on site size, crawl rate and the scope of the change.
• Recovery ranges in the FAQ are practitioner observations across projects, stated as ranges for that reason.

Sources

1. Google Search Central — Site moves with URL changes
2. Google Search Central — Site moves without URL changes
3. Google Search Central — Redirects and Google Search
4. Google Search Console Help — Change of Address tool
5. Google Search Central — Build and submit a sitemap
6. Google Search Central — Core Web Vitals and Google Search results
7. Lucidens — The Technical SEO Audit Checklist for 2026