What Is a Site Migration? Moving Without Losing Traffic

Aug 05, 2026 · SEO Glossary

The call usually comes two or three weeks after launch: "We redesigned the site and organic traffic is down 40%." A look at the crawl tells the story in an hour — the URL structure changed, half the old URLs 404, the redirect map covers only the top navigation pages, and the money pages that earned links for eight years now dead-end. None of it was malicious. It just wasn't anyone's job to prevent it.

So what is a site migration? Any change substantial enough to alter how search engines reach and evaluate your site: a new domain, HTTP to HTTPS, a platform switch (say, WordPress to Webflow), a URL-structure overhaul, a redesign that rebuilds templates, or a merger of several sites into one. The common thread: URLs and signals that Google spent years learning are about to change, and your job is to hand it an unambiguous map from old to new.

Why Migrations Lose Traffic

Google's index is built around URLs. Rankings, link equity, and historical performance attach to specific addresses. When an address changes, that accumulated trust doesn't follow automatically — it follows the 301 redirect you provide, and only if you provide it. The classic failure modes, in descending frequency:

• Incomplete redirect maps. The team maps the 50 pages in the navigation and forgets the 3,000 blog posts, PDFs, and old campaign URLs — including the ones with the best backlinks.
• Everything redirected to the homepage. Google treats irrelevant blanket redirects as soft 404s, and the equity evaporates just the same.
• Redirect chains stacking. The new migration's redirects pile onto the last migration's, producing multi-hop chains that crawl slowly and break easily.
• On-page regressions shipping alongside. The new templates quietly drop title tags, canonical tags, structured data, or half the internal links — the migration gets blamed, but the templates did it.
• Staging leftovers. A noindex tag or Disallow: / that was correct on staging goes live in production. It happens to companies of every size.

What Is a Site Migration Plan? The Sequence That Works

Before anything moves: crawl the current site completely and export every URL — this snapshot is your insurance policy. Augment it with URLs from Search Console (top pages by clicks), analytics, and your backlink data, because the crawl won't find orphaned pages that still earn links or traffic. Then build the redirect map: every old URL to its most relevant new counterpart, one-to-one wherever an equivalent exists. Pages being retired deliberately should 410 or redirect to the closest useful parent — decided, not defaulted.

On staging: crawl the new site before launch. Verify templates carry titles, metas, canonicals, structured data, and internal links. Load the redirect map into the new stack and test it against the full old-URL list — every entry should answer with a single 301 to a 200 page. This one test, run before launch, prevents the majority of migration disasters I've seen.

Launch day: deploy, then immediately verify robots.txt and spot-check that production pages don't carry staging noindex tags. Submit the new XML sitemap; for domain changes, file the Change of Address in Search Console (keep the old property verified — you'll want its data). Keep the old sitemap temporarily available so Google recrawls the old URLs and processes their redirects faster.

The Weeks After: Monitoring Season

Launch day ends; the migration doesn't. In Search Console, watch the new property's indexing climb while the old property's fades; watch Crawl Stats for a spike (normal — Google reprocesses everything) and for 404 clusters (not normal — map gaps). Recrawl the old URL list weekly for the first month; new 404s and chains appear as teams "clean up" redirect rules they don't recognize. A scheduled recrawl of the site through this window catches regressions while they're hours old instead of weeks.

Keep a daily eye on three numbers for the first few weeks: total indexed pages on the new property, total clicks against the same weeks last period, and the count of "Not found (404)" URLs in the indexing report. Those three, trending the right way, are what "the migration is working" looks like in data.

Setting Expectations With Stakeholders

Even clean migrations wobble. Rankings typically fluctuate for two to six weeks on a same-domain migration as Google reprocesses the site; full domain changes commonly take two to six months to fully settle, and Google's own guidance for large sites says as much. What distinguishes a normal wobble from a real problem: the wobble is broad, shallow (single-digit to low-teens percentage), and recovering by week four. A 40% cliff that isn't recovering means something specific is broken — go find the 404 cluster, the noindexed section, the unmapped directory. The data always points somewhere.

One rule saves more migrations than any other: change one thing at a time. A domain change plus a platform change plus a redesign plus a content rewrite in a single launch means that when traffic drops, you have four suspects and no witnesses. Sequence the changes months apart, and each one gets a clean before/after — and a clean rollback story. Migrations don't have to lose traffic. They lose it when the old site's full URL inventory was never captured, never mapped, and never re-verified — three tasks that cost a fraction of what recovering the lost rankings does.