How to Migrate a Website Without Losing SEO (2026 Guide)

Moving a website is a lot like moving house. Do it carefully — labelling boxes, forwarding your mail, telling everyone your new address — and life carries on as normal. Do it in a rush, and things go missing, letters bounce back, and the people trying to reach you give up. On the web, those "letters" are Google's crawlers and your visitors, and losing them means losing rankings, traffic and leads.

Here's the reassuring part: migrations don't damage SEO on their own. What damages SEO is the uncontrolled migration — the one where URLs change with no redirects, pages quietly disappear, or a leftover staging setting blocks Google from crawling the new site. Every one of those is avoidable. This guide walks through the full process, from the planning nobody wants to do to the monitoring everybody forgets, so you can move your site and keep the search visibility you've built.

What Counts as a Website Migration?

"Migration" sounds like it should mean changing your domain name — and it does, but it means a lot more than that. In SEO terms, a migration is any significant change to where your content lives or how search engines and users reach it. Google itself splits these into two families in its documentation: site moves with URL changes and site moves without URL changes — a useful line to keep in mind, because the URL-change moves are the risky ones.

Common examples include moving to a new domain, switching hosting providers, going from HTTP to HTTPS, replatforming from one CMS to another (say, Wix to WordPress), restructuring your URLs, or redesigning the site. Many real projects combine several of these at once — which is exactly where trouble starts.

Why Migration Puts Your SEO at Risk

Google spends months, sometimes years, learning to trust your pages. It crawls them, indexes them, weighs the links pointing to them, and builds up a sense of which page deserves to rank for which query. Crucially, all of that trust is attached to a specific URL. When a page moves to a new address and nothing tells Google where it went, that trust doesn't transfer — it evaporates.

That's the root cause behind almost every "our traffic crashed after the redesign" story. The usual culprits are worth naming plainly, because each one has a fix later in this guide:

• Missing redirects — old URLs return 404 errors, so rankings and backlinks point at dead pages.
• Deleted content — pages that used to rank simply don't exist on the new site.
• Blocked crawling — a noindex tag or robots.txt rule carried over from staging.
• Redirect chains — old URLs bounce through two or three hops before landing, wasting crawl budget and link equity.
• Broken internal links and lost metadata — titles, descriptions and links that didn't survive the move.

None of these are inevitable. They're the result of skipping steps — so let's not skip them.

Know Your Migration Type

The precautions you need depend on what's actually changing. The table below maps the five most common migrations to the URLs they affect and the thing you most need to get right for each.

Notice the pattern: the more URLs change, the more redirect work you need. A pure hosting move that keeps every URL identical is low-risk. A domain change plus a redesign plus a new CMS, done in one weekend, is where sites disappear from Google.

Before You Touch Anything: The Planning Phase

The most expensive migration mistakes are made before a single line of code changes. Good migrations are boring precisely because the planning was thorough. Here's the groundwork worth doing every time.

1. Record a baseline you can compare against

You can't tell whether a migration went well if you don't know where you started. Before anything changes, capture a snapshot of your current performance so you have something to measure against afterwards:

• Organic traffic and top pages from Google Analytics 4 — which pages bring the most visitors and conversions.
• Keyword rankings for the terms that matter, exported from Google Search Console or a rank tracker.
• Indexed pages — a rough count using a site:yourdomain.com search and Search Console's Pages report.
• Your best backlinks — which pages have earned links from other sites, since those pages need extra protection.

If tracking is patchy today, fix that first. Our guide to Google Analytics 4 and Google Tag Manager covers getting clean measurement in place before you rely on it.

2. Back up the entire site — and verify the backup

Take a full backup before you change anything: files, database, images, themes, plugins and configuration. A backup you haven't tested isn't a backup — it's a hope. Restore it somewhere and confirm it actually works, so that if launch goes sideways you can roll back in minutes instead of scrambling.

3. Crawl your existing site

Run a crawler (Screaming Frog, Sitebulb or similar) across your live site and export everything: every URL, its title and meta description, its canonical tag, its headings, and its status code. This inventory is your "before" picture. After launch you'll crawl again and compare the two — that's how you catch the page that silently vanished or the redirect that didn't fire.

4. Map old URLs to new URLs

If any URLs are changing, build a mapping spreadsheet before launch. One column for the old URL, one for its new home. This single document becomes the blueprint for your redirects, and it's the difference between a controlled move and a guessing game.

Old URL                     New URL
/services/web-design        /services/web-development
/contact-us                 /contact
/blog/seo-tips              /resources/seo-tips
/about                      /about-us

Every important page should appear here, especially the ones you flagged as high-traffic or backlink-rich in your baseline. If a URL doesn't need to change, leave it off the list entirely — which brings us to a rule worth stating on its own.

Preserve URLs Whenever You Can

One of the most common self-inflicted wounds in a migration is changing URLs for no real reason. A redesign or CMS switch tempts you to "tidy up" every address, but each changed URL is a page Google has to rediscover, recrawl and re-evaluate — and a moment where ranking signals can leak away.

So the rule is simple: if a URL doesn't need to change, don't change it. Keeping /services/seo exactly as it is costs nothing and preserves everything. Rewriting it to /digital-marketing/search-engine-optimization-service for cosmetic reasons forces a redirect and a fresh round of trust-building for zero benefit. Save URL changes for cases where they genuinely improve structure — and redirect them properly when you do.

The Most Important Step: 301 Redirects Done Right

If you take one thing from this guide, take this. A 301 redirect is a permanent instruction that tells browsers and search engines "this page has moved here for good." It's how ranking signals, backlinks, bookmarks and referral traffic follow your content to its new address.

And the good news is straight from the source. In its "How to move a site" documentation, Google recommends server-side permanent redirects from old URLs to new ones, and states plainly that "301 and other permanent redirects don't cause a loss in PageRank." In other words, redirects aren't a consolation prize — they're the mechanism that keeps your SEO intact through a move.

To get them right, follow a few hard rules:

• Redirect every old URL to its closest new equivalent. A page about web design should land on the new web design page — not the homepage.
• Don't dump everything on the homepage. Google may treat mass redirects to the homepage as "soft 404s," meaning the signal transfer you wanted simply doesn't happen.
• Avoid redirect chains. If page A moved to B last year and B is now moving to C, point A straight at C. Chains waste crawl budget and dilute link equity.

Update Internal Links and Metadata

Redirects are a safety net, not a substitute for clean internal links. If your new navigation, footer, buttons and in-content links still point at old URLs, every click fires an unnecessary redirect — slower for users and wasteful of crawl budget. Update those links so they point directly at the new URLs. Let redirects catch the external links and bookmarks you can't control; fix your own links at the source.

At the same time, carry your metadata across deliberately. Titles, meta descriptions, heading structure, canonical tags and structured data should move with each page — not get regenerated into bland defaults. This is a natural moment to tidy up schema markup too, since a migration usually touches every template anyway.

Build and Test on a Staging Site

Never rebuild a live website in public. Do the work on a staging environment — a private copy where you can test every page, form, redirect and layout before anything reaches real visitors or Google. On staging you can validate the redirect map, check mobile rendering, measure speed, confirm forms submit, and catch broken links while they still cost you nothing.

Launch Day: The Go-Live Checklist

When it's time to flip the switch, work through a checklist rather than trusting your memory. At minimum, confirm each of these on the live site before you call it done:

• Every important page loads with a 200 status — no accidental 404s.
• Your 301 redirects fire correctly, in a single hop, for a sample of old URLs.
• The staging crawl block is gone — robots.txt allows crawling and no stray noindex tags remain.
• HTTPS is enabled site-wide and HTTP URLs redirect to it.
• Titles, descriptions and canonical tags are present and correct.
• Navigation, contact forms and conversion tracking all work.
• A fresh XML sitemap lists only live, canonical URLs — no old addresses.
• Structured data validates without errors.

As soon as you're live, submit the updated sitemap in Google Search Console and Bing Webmaster Tools. If you changed domains, this is also when you use Search Console's Change of Address tool to formally tell Google about the move — a step the site-move documentation specifically calls for.

Treat the Migration as a Speed Upgrade

A migration rebuilds your front end anyway, so it's the perfect moment to improve performance. Google measures user experience through Core Web Vitals, and the thresholds are concrete: Largest Contentful Paint (LCP) under 2.5 seconds, Interaction to Next Paint (INP) at or below 200 milliseconds, and Cumulative Layout Shift (CLS) of 0.1 or less. Optimising images, caching, server response and layout stability during the rebuild means your new site launches faster than the old one — good for users and for rankings. Our page speed and Core Web Vitals guide covers the practical fixes in depth.

After Launch: Monitor for Weeks, Not Days

The migration isn't finished when the new site goes live — that's when the most important watching begins. Search engines need time to recrawl, process redirects and reindex, and small ranking wobbles in the first days or weeks are normal. What you're looking for is anything sustained. Over the following weeks, keep an eye on:

• Search Console: indexing status, crawl errors, the Pages report, sitemap processing and any manual actions. Use the URL Inspection tool to check that key pages are indexed on their new URLs.
• Analytics (GA4): organic traffic, top landing pages, conversions and engagement — compared against the baseline you recorded earlier.
• Rankings: your priority keywords, watching for drops that don't recover within a couple of weeks.
• Crawl errors and broken links: re-crawl the live site and reconcile it against your pre-migration inventory.

Fix problems quickly — a missed redirect found and added in week one costs you far less than the same gap left open for a month. And keep your redirects in place: Google recommends maintaining migration redirects for at least a year so signals fully transfer and users following old links still arrive in the right place.