Site migration without losing traffic: the SEO guide

A site migration is where organic traffic goes to die — when done wrong. Changing domain, rebuilding the platform, changing the URL structure, or simply "modernizing the site" are operations that, without the right SEO care, throw away years of accumulated authority overnight. And worse: the drop often only shows up weeks later, when it's already hard to figure out what broke.

The good news is that a well-planned migration preserves traffic — and sometimes even improves it, because it's the chance to fix old technical problems. This is the guide we follow, from planning to post-launch monitoring.

What counts as a migration

Many people associate "migration" only with a domain change, but the concept is broader — and any of these cases requires the same SEO care:

Domain change (company.com → newbrand.com).
Platform change (from WordPress to Next.js, for example).
URL structure change (from ?id=42 to /product/name, or category reorganization).
Redesign that alters URLs, content, or information architecture.
HTTP → HTTPS or www → non-www (yes, that's a migration).
Consolidation of several sites into one.

If the URLs or the HTML Google indexed are going to change, it's a migration — and the risk is real.

The heart of it all: the redirect map

The most critical piece of any migration is the redirect map: a mapping of each old URL to its new equivalent, served with a 301 (permanent) redirect. It's the 301 that transfers authority (the "ranking signals") from the old page to the new one.

Non-negotiable rules:

1 to 1, whenever possible. Each old URL should point to the most equivalent new page in content — not to the home. Redirecting everything to the home is the classic mistake that destroys traffic: Google treats it as a "soft 404" and loses the signals.
301, not 302. A 302 is temporary and doesn't transfer authority reliably. Use 301 for permanent changes.
No redirect chains. Old URL → new, directly. Avoid A → B → C; each hop loses strength and adds latency.
Cover everything. Export the complete list of indexed URLs (from the old sitemap, Search Console, server logs, and a crawl tool) before migrating. A forgotten URL becomes a 404 and lost traffic.

What to preserve

Beyond redirects, several elements need to survive the migration:

Content. This is not the time to "trim" copy. Pages that rank, rank because of their content — cutting it during migration drops the positions. Change the design, preserve the substance.
URL structure, when you can. If the new platform allows keeping the same paths, keep them. The safest migration is the one that changes the fewest URLs.
Metadata. Titles, descriptions, canonicals, and Open Graph need to be recreated on the new platform. It's common to lose them in a CMS swap.
Structured data. The JSON-LD (Organization, Article, BreadcrumbList, etc.) needs to be reimplemented, or you lose the rich results.
Internal linking. Update internal links to point directly to the new URLs — not to the old ones that redirect. Internal links to redirecting URLs waste strength.
hreflang and canonical. On multilingual sites, the hreflang annotations and canonical tags need to be recreated and validated on the new structure — with reciprocity.

Pre-launch checklist

Before flipping the switch, in a staging environment:

Full crawl of the old site to inventory all URLs, titles, metadata, and statuses.
Redirect map ready and reviewed, covering 100% of indexed URLs.
Content and metadata migrated and checked page by page on the most important ones.
Staging blocked from indexing (noindex or authentication) — so Google doesn't index the test environment by mistake. And don't forget to remove that block at launch (it's the most common fatal mistake).
New sitemap generated, with the new, absolute URLs.
Technical validation: Core Web Vitals, rendering (content in the initial HTML), structured data in the Rich Results Test.

Launch

On switch-over day:

Publish the 301s together with the new site, at the same moment. The old URLs need to redirect from second zero.
Remove the indexing block from the new site (the staging noindex).
Update the robots.txt and confirm the sitemap points to the new URLs.
Submit the new sitemap in Search Console. For a domain change, use Search Console's Change of Address tool — it formally notifies Google.
Keep the old domain (and the redirects) live for a long time — months, ideally. Turning it off too early kills the redirects and the traffic still coming through them.

Post-launch monitoring

The migration doesn't end at deploy. In the following weeks:

Indexing coverage in Search Console: track the new URLs getting indexed and the old ones dropping out. Watch for spikes in 404s and "soft 404s".
Crawl errors and redirects: confirm no redirect chains or loops appeared.
Rankings and organic traffic: some fluctuation in the first weeks is normal (Google reprocesses the site). A drop that doesn't recover within 4–6 weeks signals a problem — usually a missing redirect or lost content.
Core Web Vitals: validate that the new platform didn't regress performance.

Redirect types: which to use in each case

Not every redirect is equal, and using the wrong type costs authority:

301 (moved permanently). The standard for any migration. It signals the change is definitive and transfers ranking signals to the new URL. Use it for all old → new URLs.
308 (permanent redirect). Equivalent to 301 for SEO, with the technical difference of preserving the HTTP method (POST stays POST). Google treats both the same.
302 (found / temporary). Signals the change is temporary and the old URL will return. It doesn't transfer authority reliably. Using 302 on a permanent migration is one of the most common mistakes — Google may keep indexing the old URL indefinitely.
Meta refresh and JavaScript redirects. Avoid them. They're slow, poorly interpreted by crawlers, and hurt the experience. A server redirect (301/308) is always superior.

The practical rule is simple: definitive migration = 301 (or 308). Anything else is an exception that needs justification.

How long until traffic stabilizes

This is the question that causes the most anxiety — and where the most wrong decisions are made out of panic. After a well-executed migration, the norm is:

First days: Google starts crawling the new URLs and processing the redirects. There may be ranking fluctuation.
2 to 4 weeks: most of the index updates. For a domain change, the Change of Address tool speeds this up.
4 to 8 weeks: traffic stabilizes at the new level. A well-executed migration recovers the previous level; a problematic one shows a drop that doesn't recover.

The classic mistake is panicking in the second week, seeing the normal fluctuation, and starting to "fix" things that weren't broken — changing redirects, altering content, creating even more instability. The discipline here is: plan well beforehand, monitor calmly afterward, and only intervene based on data (real 404s, missing redirects, lost content), not on fear.

If after 6–8 weeks traffic hasn't returned, then there's something to investigate — and it's almost always one of the causes in the next section.

The mistakes that drop the most traffic

Redirecting everything to the home instead of mapping 1 to 1.
Forgetting URLs that weren't in the sitemap but had traffic and backlinks.
Letting the staging noindex leak into production at launch.
Turning off the old domain/redirects too early.
Cutting content from the pages that ranked, in the name of a "cleaner site".
Redirect chains accumulated from previous migrations.

Most of these mistakes are invisible on launch day — the damage only shows up in the following weeks, when recovery is harder. That's why migration is so risky without a dedicated plan and monitoring.

A realistic timeline

Migrations go wrong when they're treated as a one-day event. In practice, a healthy timeline looks like this:

Weeks -4 to -3 (preparation). Full crawl of the current site, inventory of URLs with traffic and backlinks, and building the 1-to-1 redirect map. It's the longest phase and the one that most prevents disaster.
Weeks -2 to -1 (staging). New site assembled in an indexing-blocked environment, with content, metadata, structured data, and hreflang migrated and checked. Technical validation (rendering, Core Web Vitals, Rich Results Test) and testing the redirects in staging.
Day 0 (launch). Switch-over with the 301s live at the same moment, indexing block removed, new sitemap submitted, and — for a domain change — Change of Address triggered in Search Console. Ideally outside the traffic peak, with the team available to react.
Weeks +1 to +8 (monitoring). Daily tracking at first, then weekly: indexing coverage, 404s, redirects, rankings, and Core Web Vitals. Intervene only based on data.

Large migrations (e-commerce with thousands of URLs, site consolidation) deserve a pilot phase too: migrate a small section first, validate that traffic behaves as expected, and only then move the rest.

Tools that help

You don't have to do this in the dark. The minimum kit:

A crawler (Screaming Frog, Sitebulb, or similar) to inventory URLs, statuses, titles, metadata, and internal links — before and after.
Google Search Console for the list of indexed URLs, the Change of Address tool, the coverage report, and field Core Web Vitals.
Server logs to see which URLs Googlebot actually visits — a source of URLs that don't show up anywhere else.
A backlink tool to identify which old pages have external links (those are top priority in the redirect map — it's the authority you can't afford to lose).
A bulk redirect checker to confirm, after launch, that each old URL responds with a 301 to the correct new one, with no chains.

Combining these sources is what guarantees the redirect map covers 100% of the URLs that matter — not just the ones that were in the sitemap.

Conclusion

Migrating doesn't have to cost traffic. The secret is the basics done well: a complete, 1-to-1 301 redirect map, preserving content, metadata, structured data, and internal linking, a synchronized launch, and attentive monitoring in the following weeks. Done this way, the migration not only preserves authority but becomes the chance to fix the technical debt that was holding the site back.

Ready to respawn?

If you're planning a migration — or already did one and traffic dropped — you can map what to preserve and what to recover. Request a free audit — within 7 days you'll get a diagnosis prioritized by impact and effort, no strings attached.