Migrating a Website Without Losing SEO Rankings

A website migration — a redesign, a platform change, a domain move, or a simple restructuring of the URL layout — is one of the few events that can undo years of accumulated SEO in a matter of days. It is also, in most cases, entirely avoidable. The businesses that lose rankings during a migration almost always lose them to the same handful of preventable mistakes: broken redirects, lost content, and a launch that happened before anyone checked whether search engines could still find their way around.

Why Migrations Go Wrong

Search engines rank URLs, not businesses. Every page that currently ranks has accumulated its own history of links, engagement signals, and relevance associations tied specifically to its URL. A migration that changes those URLs without carefully mapping old to new is, from a search engine’s perspective, deleting a set of known pages and publishing a set of unknown ones — and unknown pages start from zero, regardless of how good the underlying content is.

The teams that get this wrong are rarely being careless on purpose. Migrations are usually driven by a design team, a development team, or a platform decision, and SEO considerations get treated as a final checklist item rather than a constraint that shapes the plan from the start. By the time someone asks “did we redirect the old URLs?” after launch, the damage is often already showing up in search traffic.

The Pre-Migration Audit

Before a single page changes, the existing site needs a full inventory: every indexed URL, its current ranking keywords, its organic traffic, and its backlink profile. This is not optional groundwork — it is the baseline against which post-migration performance gets measured, and it is the source data for the URL mapping that comes next.

Crawl Everything

A full site crawl, using a dedicated crawler rather than relying on a sitemap alone, catches pages that might not be in the sitemap but are still indexed and receiving traffic — old blog posts, orphaned landing pages, paginated archives. Anything missed at this stage is a page that risks disappearing silently during the migration.

Identify High-Value Pages

Not every page carries equal weight. Pulling organic traffic and ranking data (from Search Console and analytics) identifies the pages doing the heavy lifting — the ones that, if broken, would cause the most visible damage. These pages deserve manual verification after launch, not just automated redirect checks, because they’re the ones where a subtle mistake causes the most damage.

Building the URL Redirect Map

A 301 redirect map — one entry for every old URL, pointing to its most relevant new equivalent — is the single most important technical artifact in a migration. This needs to be one-to-one wherever possible; redirecting every old URL to the new homepage (“catch-all” redirects) preserves almost none of the original ranking value and is treated by search engines as barely better than a broken link.

Every redirect should be a 301 (permanent), not a 302 (temporary) — search engines treat these differently, and a 302 does not reliably pass ranking signal the way a 301 does. Redirect chains (URL A to URL B to URL C) should also be flattened to single hops wherever possible, since each additional hop adds a small amount of signal loss and a real amount of page-load delay.

Content and On-Page Elements That Must Survive

A redesign often comes with a rewrite, and rewriting content during a migration is where a lot of unnecessary risk gets added on top of the structural risk already present. If content is being substantially changed, that should ideally happen before or well after the migration — not simultaneously — so that any ranking movement can be attributed to one variable rather than several at once.

Title tags, meta descriptions, and heading structure should be carried over deliberately, even when a page’s visual design changes completely. These elements are frequently ranking factors in their own right, on top of the content they describe, and losing them in a redesign — even when the visible content stays similar — regularly causes ranking drops that surprise teams who assumed the “content” was preserved. This same discipline extends to internal linking: a page that received links from twenty other pages on the old site needs to keep receiving comparable internal links on the new site, not lose them because a new navigation structure or related-posts widget was built without referencing the old link graph.

Technical Checks Before Launch

A staging environment should be fully crawled and checked before it goes live, specifically for: a robots.txt file that isn’t accidentally blocking the entire site (an extremely common staging-to-production mistake), an XML sitemap reflecting the new URL structure, canonical tags pointing to the correct new URLs rather than leftover staging URLs, and structured data intact and validating correctly. Any one of these, missed, can suppress indexing or visibility even when every redirect is perfect.

This kind of pre-launch technical verification overlaps closely with a standard technical SEO audit, and running one specifically against the staging environment — not just the live site after launch — catches problems while they’re still free to fix.

Launch Day and the Weeks After

On launch day, the redirect map should go live at the same time as the new site, not days later. A gap where old URLs simply 404 while the team “gets to the redirects soon” is one of the more damaging and entirely preventable mistakes in migration work. Submitting the new sitemap to Search Console immediately after launch, and using the URL inspection tool to request indexing for the highest-value pages, speeds up the re-crawl process rather than waiting for search engines to discover the changes on their own schedule.

Traffic and ranking monitoring should intensify for the following four to six weeks, since this is the window where most migration-related ranking volatility plays out. A temporary dip immediately after launch is common even in well-executed migrations, as search engines re-crawl and re-evaluate the new URLs; a dip that continues past several weeks without recovering usually signals a genuine problem — a missed redirect, an accidental noindex tag, or lost internal links — that needs direct investigation rather than patience.

When a Migration Coincides With Other Changes

Businesses migrating a site as part of a broader project — moving to a new website development partner, changing hosting as part of a server administration upgrade, or consolidating multiple domains — face compounded risk, since more variables are changing at once. Sequencing these changes deliberately, rather than bundling everything into one launch date, makes it far easier to isolate the cause of any post-launch issue. Google’s own site-move documentation and Moz’s guide to redirection are both worth reviewing alongside a migration checklist, since the technical detail involved goes deeper than any single article can fully cover.

Common Migration Scenarios and Their Specific Risks

Platform Migrations

Moving from one CMS to another (a custom-built site to WordPress, or between e-commerce platforms) usually changes URL structure whether the team intends it to or not, since different platforms have different default conventions for how category, product, and blog URLs are generated. Locking down the exact new URL structure before development starts, and mapping every old URL against it, avoids a scramble to reconstruct that mapping after the new platform is already built around a different pattern.

HTTP to HTTPS Migrations

A protocol change is technically a migration even when nothing else about the site changes, since every URL’s protocol prefix is different. This is usually lower-risk than a full redesign, but still requires a site-wide 301 redirect from every HTTP URL to its HTTPS equivalent, updated internal links and canonical tags to point to HTTPS directly (rather than relying on the redirect), and a Search Console property verified for the HTTPS version.

Consolidating Multiple Sites Into One

Businesses that acquire other companies, or that decide to fold several smaller sites into one main domain, face one of the more complex migration types: content from multiple source domains needs individual redirect mapping into the consolidated structure, and duplicate or overlapping content across the merging sites needs a deliberate decision about which version survives, rather than letting both versions compete against each other on the new domain.

Redesigns With No URL Changes

Not every redesign changes URLs, and when it doesn’t, the redirect risk disappears — but the content and on-page element risk does not. A visual overhaul that quietly drops H1 tags, changes heading hierarchy, or removes internal links that used to appear in a sidebar or footer can hurt rankings just as much as a full URL restructuring, simply through a different mechanism. Treating a “redesign only” migration as risk-free is a common and avoidable mistake.

Frequently Asked Questions

How long does it take rankings to recover after a migration?

A well-executed migration with complete 1:1 redirects typically sees rankings stabilise within two to eight weeks, though highly competitive keywords can take longer. A poorly executed migration can take months to recover, if it fully recovers at all.

Should I migrate everything at once or in phases?

Phased migrations (moving sections of a site gradually) reduce risk by limiting how much can go wrong at once, and make it easier to isolate problems, but are not always practical for a full redesign or platform change. When a full launch is necessary, extra pre-launch verification substitutes for the risk reduction that phasing would otherwise provide.

Do I need to redirect every single old URL?

Ideally yes, though pages with zero traffic, zero backlinks, and no ranking value can reasonably be allowed to 404 rather than redirected, since maintaining redirects for genuinely valueless pages adds ongoing complexity without meaningful benefit.

What happens if I change domains during a migration?

A domain change adds a layer of risk on top of URL structure changes, and requires the site-move tool in Search Console for both the old and new domain in addition to the redirect map, since search engines treat a domain change as a distinct signal from a URL path change.

Can I use 302 redirects temporarily during testing?

Yes, 302s are appropriate while a migration is still being tested or is reversible, but they should be switched to 301s before or at the moment of permanent launch, since search engines may not pass full ranking signal through a 302.

Will my Google Business Profile or local rankings be affected by a website migration?

Local rankings are less directly tied to on-site URL structure than organic rankings, but a broken or slow website discovered through a Google Business Profile link can still hurt local conversion rates and indirectly affect local visibility over time.

What is the most common mistake in DIY migrations?

Skipping the pre-migration crawl and relying only on the current sitemap, which misses orphaned but still-valuable pages, combined with launching without a complete redirect map already live.

The Bottom Line

A migration does not have to cost a business its search rankings, but it does require treating SEO as a launch requirement rather than a post-launch cleanup task. A complete pre-migration audit, a one-to-one redirect map, preserved on-page elements and internal linking, and close monitoring in the weeks after launch are not exotic techniques — they are the well-documented basics that separate migrations that barely register in the traffic data from the ones that make headlines internally for the wrong reasons. Planning this alongside the broader project timeline, rather than bolting it on at the end, is the difference between a migration and a setback.