Site migration without losing your organic traffic

Teams reserve the word for a domain change, then lose a third of their traffic to a redesign nobody called a migration. In practice, four kinds of change carry the same risk and deserve the same plan: changing domain or subdomain, changing the URL pattern, changing platform, and reorganising the content — merging categories, retiring sections, restructuring a catalogue. A redesign that keeps every URL intact is genuinely low risk; a redesign that renames a hundred category URLs is a migration whatever the ticket says.

The risk comes from the same mechanism in all four cases. Every URL you have accumulated carries history: links pointing at it, impressions and clicks recorded against it, an assessment of its quality. That history is attached to the address, not to the content. Move the content without moving the address correctly and you start again from zero on a page that took two years to earn its position.

The corollary is reassuring: a migration that preserves addresses, or maps them one-to-one, preserves history. Nothing about a replatform is inherently damaging to SEO. What damages it is losing the mapping — and losing the mapping is almost always a planning failure rather than a technical one.

The single most valuable hour in a migration is spent before the work starts, archiving the current state. Run a full crawl of the live site and keep the export: URLs, status codes, titles, meta descriptions, canonicals, hreflang, word counts, internal link counts. Export sixteen months of Search Console data by page and by query. Export the backlink profile from whatever index you trust. Save all three somewhere that will still exist in a year.

Then freeze a performance baseline by template rather than site-wide. Product pages, category pages, editorial pages and the homepage behave differently after a migration, and a single site-wide average will hide the one segment that broke. Write down, before launch, what the last four stable weeks looked like for each template: impressions, clicks, average position, indexed count.

This archive is not paranoia, it is the only way to answer the question that will be asked in week six: "was this page ranking before?". Without it, every recovery discussion becomes a matter of opinion, and the team spends its energy relitigating what happened rather than fixing it.

Building the map from the CMS export alone is the most common mistake, because the CMS only knows the pages it currently publishes. It does not know the old campaign landing page that still holds forty links, the retired product URL that gets two hundred impressions a month, or the PDF a trade publication linked to in 2021. Build the map from the union of three sources: the crawl, every URL with impressions in Search Console, and every URL with external links.

The rule is one-to-one to the closest equivalent. Where a page has a direct replacement, redirect to it. Where a page has been merged into another, redirect to the merged destination. Where a page genuinely has no successor — a discontinued product with no equivalent — a 410 is honest and processed faster than a 404. What you must not do is redirect the unmatched remainder to the homepage: search engines treat a mass redirect to a generic page as a soft 404 and the accumulated signal is discarded rather than transferred.

Two implementation details cause most of the damage. Chains: a URL redirected to a URL that is itself redirected wastes crawl budget and dilutes signals, so flatten every chain to point directly at the final destination before launch. And the trailing details — protocol, www, trailing slash, case sensitivity, query parameters — each of which can silently double your URL space if the new platform handles them differently from the old one.

Staging environments cause two recurring accidents, and both are avoidable. The first is a staging site that gets indexed because it was left open; use HTTP authentication rather than robots.txt, because a disallowed staging site can still end up listed. The second is the reverse and far more expensive: the staging `Disallow: /` shipped to production on launch day, which quietly de-indexes the entire site while everything looks fine in the browser.

On the staging build itself, crawl it as if it were live and compare against the archived crawl of the old site. What you are looking for: titles and meta descriptions that survived the template rewrite, canonical tags pointing where they should, hreflang clusters still reciprocal, structured data still present and valid, internal links pointing at final URLs rather than at redirects, and the main content present in the server-rendered HTML rather than injected after hydration.

Then test the redirect map mechanically. Take the crawl export of the old site, request every URL against the staging environment, and assert that each returns a single 301 to a 200-responding destination. A spreadsheet of a thousand rows is tedious; discovering in production that a fifth of them 404 is worse. This is also the moment to check that the sitemap on the new site contains only canonical, indexable, 200 URLs.

Launch mid-week, in the morning, never before a holiday. The reason is boring and decisive: the first four hours are when you find the thing the staging environment did not reproduce, and you want the whole team available. Within that window, check the live robots.txt, request twenty redirects by hand, submit the new sitemap, and confirm in the URL Inspection tool that a representative page from each template renders with its content, its canonical and its structured data.

Then expect a dip. Even a well-executed migration usually loses visibility for two to six weeks while the engine recrawls, reprocesses the redirects and reassesses the new URLs. The useful discipline is to monitor by template against the frozen baseline, and to distinguish three shapes: a shallow dip that recovers steadily is normal; a segment that flatlines while the rest recovers is a mapping or indexing bug; a site-wide collapse that does not move is usually one line in robots.txt or a rogue noindex.

Beyond week eight, patience stops being a strategy. If a template is still down, go back to the archive: was this page ranking before, does its replacement exist, does it return 200, is it in the sitemap, is it internally linked, does it carry the same content depth? In practice the great majority of unrecovered migrations come down to one of five causes — missing redirects, redirect chains, noindex left in a template, internal links still pointing at old URLs, or content quietly lost in the replatform. Our technical audit checklist covers the diagnostics, and the SEO health scorecard helps sequence the repairs.