How to Migrate a Website Without Losing Your SEO Rankings

There's a specific kind of dread that hits about a week after a site relaunch. The design looks great, the team is relieved, and then organic traffic falls off a cliff. Rankings that took years to build are suddenly gone, and nobody's quite sure why.

Migrations don't lose rankings because Google punishes change. They lose rankings because something broke in the move and nobody caught it. Almost every migration disaster traces back to a handful of avoidable mistakes.

Quick Answer: A website migration keeps its SEO when every old URL either stays the same or 301 redirects to its closest new equivalent, the new site is fully crawlable and indexable, and content and internal links survive the move. Before launch, crawl and benchmark the old site, build a complete URL redirect map, and check that staging isn't blocking Googlebot. On launch day, verify redirects fire and the robots file allows crawling. After launch, watch Search Console for crawl errors, indexing drops, and spikes in 404s so you can fix problems in days, not months.

What Counts as a Site Migration?

More than people think, and that's part of the problem. A migration is any change that alters URLs, hosting, structure, or how content is rendered. Teams brace for a domain change but treat a redesign as harmless, and the redesign is where they get burned.

The common types all carry SEO risk. Changing domains, obviously. Moving from HTTP to HTTPS. Restructuring URLs during a redesign. Switching platforms, say from a custom build to a CMS. Consolidating several sites into one. Even a big template overhaul that changes how pages are built can shift how Google sees them.

The through line is that URLs or content or crawlability are about to change, and Google has to re-map everything it knew about your site. Your job is to make that re-mapping as smooth and lossless as you possibly can. The migrations that go well are boring. Nothing surprising happens, because everything was planned.

So the first move is honest scoping. Write down exactly what's changing. If URLs change, you need a redirect map. If rendering changes, you need to check indexability. If the domain changes, you need both plus a change of address signal. Naming the changes tells you which risks you're actually carrying.

Why Do Migrations Lose Rankings?

Because a link in the chain snaps, and every one of them is preventable. Understanding the failure modes is what lets you prevent them, so here are the ones that do real damage.

Broken or missing redirects top the list. When an old URL that ranked and earned links returns a 404 instead of redirecting, all of that authority evaporates. Google finds a dead page where a trusted one used to be, and the link equity built into it has nowhere to flow.

Changed URLs without a map are the same failure in slower motion. New URLs start from zero, the old ones die, and the rankings that lived on the old addresses don't transfer because nothing tells Google the new page is the same page. A 301 redirect is that "same page" signal, and without it the connection is lost.

Then there's the quiet killer. A staging site is usually blocked from search engines with a noindex tag or a disallow in robots.txt, which is correct. The disaster is pushing that block to production on launch day. The new site goes live perfectly, looks flawless, and is invisible to Google because it's still telling crawlers to stay out. Traffic doesn't drop gradually here. It falls off a shelf.

Content changes matter too. If a redesign trims copy, drops whole sections, or turns text into images, the page may simply have less for Google to rank. A prettier page that says less often ranks worse, and teams rarely connect the redesign to the thin content problem it quietly created.

How Do You Plan a Migration That Keeps Rankings?

You do the work before launch, because a migration is won or lost in preparation. The single biggest predictor of a clean migration is a complete plan built while the old site is still healthy.

Start by crawling and benchmarking the current site. Use a crawler to pull every indexable URL, and record current rankings, top landing pages, and which pages earn the most links and traffic. This inventory is what you'll protect, and you can't protect what you never measured. Screenshot or export your organic traffic and top queries before anything changes.

With the inventory in hand, decide how much actually needs to change. The safest migration changes as little as possible. If URLs can stay the same, keep them. If the structure works, don't reinvent it for the sake of a fresh look. Every URL you preserve is one you don't have to redirect, monitor, and worry about. Change is risk, so spend that risk only where it buys something real.

Then build the redirect map, which deserves its own section because it's the heart of the whole operation.

The Redirect Map Is the Whole Game

If you get one thing right, make it this. A redirect map is a spreadsheet that lists every old URL and the new URL it should point to, and it needs to be complete, not a best effort.

Every old URL that had value gets mapped to its closest equivalent on the new site. Not the homepage. The closest matching page. A product that moved gets pointed to the same product's new URL, a category to the matching category, an article to the same article. Redirecting everything to the homepage is one of the worst things you can do, because it tells Google those pages are gone and their relevance is worthless.

The redirects themselves have rules. Use 301, the permanent redirect, not 302, which signals a temporary move and passes authority less reliably. Make each redirect a single hop, so old URL goes straight to final new URL, never old to middle to final. Redirect chains waste crawl budget and leak authority at every step. And redirect at the server level so the signal is clean and fast.

Here's how the risk profile shifts by migration type, so you know where to concentrate.

Test the whole map on staging before launch. Run your redirect list through a checker and confirm each one returns a single 301 to the right destination. Finding a broken redirect on staging is a five-minute fix. Finding it three weeks after launch is a recovery project.

What Do You Check on Launch Day?

A short, non-negotiable list, run the moment the new site is live. This is the window where the worst mistakes are cheapest to catch, so treat it like a pre-flight checklist rather than a hope.

• Confirm the production robots.txt allows crawling and no stray sitewide noindex shipped from staging
• Spot-check a sample of redirects across every URL type and verify each returns a single 301
• Submit the new XML sitemap in Search Console and, for a domain change, file the change of address
• Check that canonical tags point to the new URLs, not leftover staging or old-domain addresses
• Verify key pages render their full content and internal links, not a stripped-down version
• Confirm HTTPS is enforced everywhere and there's no mixed HTTP and HTTPS

That robots and noindex check is worth doing twice. It's the mistake that turns a smooth launch into an emergency, and it hides in plain sight because the site looks perfect to human eyes. Only a crawler or a look at the page source catches it.

What Should You Monitor After Launch?

The first few weeks decide whether small problems get fixed or become permanent losses. Rankings wobble after any migration as Google re-crawls and re-assesses, and some short-term movement is normal. What you're watching for is the difference between a temporary dip and a real leak.

Lean on Search Console hard. Watch the index coverage and pages reports for a spike in errors or a drop in indexed pages, which signals redirects or crawlability broke somewhere. Check the crawl stats to confirm Googlebot is finding and fetching the new URLs. Compare impressions and average position against your pre-launch benchmark so you can tell a normal settling from a genuine decline.

Hunt for 404s actively rather than waiting for them to surface. A rising count of not-found errors on old URLs means your redirect map has gaps, and each gap is a page bleeding authority. Every 404 that should have been a redirect is a quick fix once you spot it, so make spotting them a daily habit for the first couple of weeks.

Give it time, but not blind time. Expect some settling over the first few weeks, and don't panic at day-three noise. But settling should trend back toward your benchmark. If four to six weeks pass and traffic is still well down with no recovery, something structural broke, and it's time to re-audit redirects, indexability, and content parity rather than wait longer. Patience is for normal fluctuation, not for an unaddressed problem.

FAQ

How long does it take rankings to recover after a migration? A clean migration often settles within a few weeks, sometimes with a brief dip as Google re-crawls and re-maps the site. A messy one can drag on for months or never fully recover. The recovery speed is mostly set by how complete your redirects and indexability are, not by waiting longer.

Do I need 301 redirects if the URLs stay exactly the same? No. If a URL doesn't change, it needs no redirect, which is exactly why preserving URLs is the safest path. Redirects are only for URLs that move. The fewer URLs you change, the fewer redirects you have to get right.

Should I migrate everything at once or in phases? For most sites, a single well-prepared cutover is cleaner than a drawn-out phased move, because a half-migrated site with mixed old and new URLs is hard to reason about. Very large sites sometimes phase by section, but each phase still needs its own complete redirect map and monitoring.

Will a redesign hurt my rankings even if URLs don't change? It can, if the redesign removes content, changes how pages render, or strips internal links. Google ranks what's on the page, so a lighter page can rank lighter. Preserve your copy and linking during a redesign, and treat content parity as part of the migration, not an afterthought.

What is the change of address tool and when do I use it? It's a Search Console feature that tells Google you've moved to a new domain. Use it only for domain changes, after your 301 redirects are live, to speed up how quickly Google recognizes the move. It supplements your redirects, it doesn't replace them.

Is it normal for traffic to drop right after launch? A short, shallow dip while Google re-crawls is common and usually recovers. A steep, sustained drop is not normal and signals something broke, most often redirects or an accidental noindex. The trend over the first few weeks tells you which one you're looking at.

Where to Go Next

Before your next migration, build the redirect map and benchmark the old site first, because everything else depends on those two artifacts. A complete map plus a clear before-picture is what separates a boring, successful move from a months-long recovery.

If a migration already went sideways, start with the redirect audit and the noindex check, since those two account for most disasters. And if the drop looks like an algorithm issue rather than a broken move, the core update recovery guide covers that different problem. Astro SEO Blog covers redirects, crawlability, and technical fixes across the technical SEO category.