SEO Site Migrations: How to Move Your Website Without Losing Your Traffic

Most website migrations damage SEO. A study of 892 domain migrations found that the average site took 523 days to recover its organic traffic. Seventeen percent never recovered at all. Separate research from Search Engine Journal puts the average recovery time at 229 days for migrations where SEO was actively managed throughout the process.

Those numbers should make you cautious, not paralysed. Migrations go wrong when they’re treated as a design or development project with SEO bolted on at the end. They go right when the SEO strategy is embedded from the first planning meeting and someone with experience is making judgment calls at every stage.

This guide covers everything I’ve learned from managing migrations across financial services, e-commerce, and other competitive sectors where organic traffic has direct revenue impact. I’ll walk through the planning, execution, and recovery phases, but I’ll also cover something most guides skip entirely: how to decide whether you should migrate at all.

What Counts as a Site Migration?

A site migration is any change to your website that affects how search engines discover, crawl, or index your pages. The term covers a wide range of scenarios, and they don’t all carry the same level of SEO risk.

High risk: - Domain changes (example.com to newbrand.com). You’re asking Google to transfer all trust signals to a completely new address. This is the riskiest migration type. - HTTP to HTTPS (less common now, but still happens with legacy sites). Every URL changes, which means every page needs a redirect. - Subdomain consolidation (moving blog.example.com to example.com/blog). Google treats subdomains as semi-separate entities, so this is effectively a partial domain change.

Medium risk: - CMS changes (WordPress to Shopify, or Drupal to WordPress). URL structures almost always change, templates change, and the way the CMS generates metadata, canonical tags, and sitemaps changes. Even if you map every URL perfectly, the underlying HTML output is different, and that matters. - Major redesigns that change URL structure. If your redesign only changes the visual layer and keeps URLs identical, the SEO risk is low. The moment URLs change, it’s a migration.

Lower risk (but not zero): - Visual redesigns with no URL changes. Layouts, templates, and content blocks change, which can affect how Google renders and interprets your pages. Core Web Vitals can shift dramatically with a new design. Internal linking patterns often change without anyone noticing. - Content restructuring (reorganising categories, merging sections, pruning thin pages). This changes how Google understands your site’s topical architecture.

The distinction matters because the amount of SEO work required varies enormously between these types. A domain change needs months of preparation. A visual redesign with stable URLs might need a few days of pre-launch checks.

When You Shouldn’t Migrate

Every migration guide assumes you’ve already decided to migrate. I want to challenge that assumption, because sometimes the right call is to stay where you are.

Don’t migrate if: - Your primary motivation is aesthetics. A site that looks dated but ranks well is generating revenue. A site that looks beautiful but lost 40% of its organic traffic in the migration is a liability. If rankings are strong, consider a visual refresh that preserves URLs and architecture rather than a full rebuild. - The business case doesn’t justify the risk. If your site generates, say, 10,000 organic sessions per month with a 2% conversion rate and a customer lifetime value of several hundred pounds, the revenue at stake during a traffic dip is substantial. Calculate it. Then decide if the migration benefit outweighs that risk. - You’re being told “it’ll be fine.” Confidence from a developer who hasn’t managed SEO through a migration is not the same as competence. If nobody on the project has done this before and you can’t bring in someone who has, the risk profile changes significantly.

Do migrate if: - Your current platform is genuinely holding you back (can’t implement schema, can’t manage redirects, terrible Core Web Vitals that can’t be fixed within the existing system). - You’re consolidating multiple properties and the long-term authority gain outweighs the short-term disruption. - You’re rebranding and the domain change is a business requirement, not a preference. - Your site has accumulated so much technical debt that fixing it piecemeal would take longer and cost more than starting with a clean architecture.

The honest answer: most migrations that go badly were either unnecessary or poorly planned. Getting this decision right is the first and most important step.

Phase 1: Pre-Migration Planning

Benchmark Everything

Before you change anything, document your current performance in detail. You cannot measure migration impact without a clear baseline.

What to record: - Organic traffic by landing page (Google Analytics 4, last 12 months minimum) - Keyword rankings for your top 50-100 commercial and informational terms - Indexed page count (Google Search Console > Pages) - Crawl stats (GSC > Settings > Crawl stats) - Core Web Vitals field data (GSC > Experience > Core Web Vitals) - Backlink profile (export from Ahrefs, Semrush, or Majestic) - Top converting pages and their organic contribution to revenue - Current XML sitemap URL list - Any existing Google Business Profile connections or local citations pointing to specific URLs

Annotate the migration date in GA4 so future analysis can compare pre and post periods without guesswork.

Crawl Your Existing Site

Run a full crawl of your current site using Screaming Frog, Sitebulb, or a similar tool. Export everything: URLs, status codes, canonical tags, meta robots directives, heading structures, internal links, external links, structured data.

This crawl serves two purposes. First, it gives you the URL inventory for your redirect map. Second, it reveals pre-existing problems (broken links, redirect chains, orphan pages, missing canonicals) that you should fix during the migration rather than carry over.

Build the Redirect Map

This is the single most important document in any migration. A redirect map is a spreadsheet that pairs every existing URL with its equivalent on the new site.

Rules: - Every URL that has ever received organic traffic or has backlinks pointing to it needs a 301 redirect to the most relevant new URL. Not the homepage. The most relevant equivalent page. - If a page is being removed with no equivalent, redirect it to the closest parent category or topic page. Redirecting everything to the homepage is a signal to Google that you don’t know what you’re doing, and it wastes the link equity those pages carried. - Include URLs from your crawl export, your GA4 landing page report, and your backlink profile. The crawl alone won’t catch URLs that are no longer on the site but still have inbound links. - Test the redirect map before launch. Every single line. Automated redirect testing tools exist for a reason.

A bad redirect map is the most common cause of migration traffic loss. The study I mentioned earlier, where 17% of sites never recovered, almost certainly includes sites where redirects were incomplete, broken, or pointed to the wrong destinations.

Preserve Your Structured Data

If your current site has schema markup (Article, Product, FAQPage, LocalBusiness, Organisation), map which pages carry which schema types. Your new site needs to replicate or improve on this. CMS changes frequently break structured data because the new platform generates it differently, or doesn’t generate it at all.

Add a column to your redirect map: “Schema type on current page.” This ensures nothing falls through the cracks during the build phase.

Consider the AI Search Dimension

If your pages are currently being cited in AI Overviews, ChatGPT, or Perplexity, a migration adds a layer of complexity that didn’t exist a few years ago. When URLs change, the retrieval systems that feed AI models need to re-associate your content with its new location. This process isn’t instant, and there’s limited transparency about how quickly AI systems update their source references.

The practical advice: maintain your content’s citability signals through the migration. Keep your content structure, entity references, and topical coverage consistent. If you change the content significantly at the same time as changing URLs, you’re giving AI systems two reasons to lose track of you rather than one.

Phase 2: The Build and Staging

Staging Site Setup

Your new site should be built on a staging environment that is completely blocked from search engines. This means:

• robots.txt disallowing all crawlers
• noindex meta tags on every page (belt and braces)
• HTTP authentication (password protection) as an additional layer

I’ve seen migrations where the staging site was accidentally indexed by Google before launch, creating duplicate content issues and cannibalising the live site’s rankings. Check this. Then check it again.

Pre-Launch Audit on Staging

Before flipping the switch, run a full technical audit on the staging site:

• Crawl the staging site and compare URL count to the live site. Are pages missing?
• Check that every page has a unique, relevant title tag and meta description
• Verify H1 tags on every key page
• Test the redirect map against the staging URLs (do the redirects resolve correctly?)
• Confirm XML sitemap generation and accuracy
• Verify robots.txt will be correct post-launch (remove the staging blocks)
• Check canonical tags on every page type
• Test structured data with Google’s Rich Results Test
• Run a Core Web Vitals check (Lighthouse, PageSpeed Insights) to catch performance regressions
• Verify all internal links point to live URLs, not staging URLs (a common mistake)
• Check that Google Analytics and Google Tag Manager are properly configured

This audit is where you catch problems that would cost you weeks of recovery time if they went live. Treat it as the most important QA step in the project.

Phase 3: Launch

Timing

Launch during a low-traffic period for your business. Not Friday afternoon (when nobody is available to fix problems over the weekend). Not during your peak commercial season. Tuesday or Wednesday morning gives you the rest of the week to monitor and respond.

Launch Day Checklist

1. Activate 301 redirects (server-side, not JavaScript redirects)
2. Update robots.txt to allow crawling
3. Remove noindex directives
4. Submit the new XML sitemap in Google Search Console
5. If changing domains: use the Change of Address tool in GSC
6. Verify GSC property for the new domain/URL structure if applicable
7. Test a sample of 20-30 redirects manually to confirm they’re working
8. Monitor server logs for 4XX and 5XX errors
9. Check that HTTPS is working correctly across all pages
10. Verify canonical tags are pointing to the correct new URLs

Immediately After Launch

Request indexing for your most important pages via GSC’s URL Inspection tool. This doesn’t guarantee faster indexing, but it puts your key pages at the front of the queue.

Run a site:yourdomain.com search in Google. You should start seeing new URLs appearing within hours to days, depending on your site’s crawl frequency.

Phase 4: Post-Migration Monitoring and Recovery

This phase is where most guides end with “monitor your analytics.” That’s insufficient. Here’s what you actually need to do.

Week 1: The Triage Phase

• Monitor GSC’s Pages report daily. Watch for spikes in “Crawled, currently not indexed” or “Not found (404)” errors
• Check the redirect map against real crawl data. Are there URLs returning 404 that should be redirecting?
• Monitor organic traffic in GA4 against your pre-migration baseline. Some drop is normal and expected. A 30%+ drop in the first week warrants investigation.
• Watch for pages that were indexed pre-migration but aren’t appearing in search results. Use site:yourdomain.com/specific-page to check.
• Keep an eye on Core Web Vitals field data as real user data starts accumulating on the new site

Weeks 2-4: Stabilisation

• Compare keyword rankings against your pre-migration benchmark. It’s normal for rankings to fluctuate for 2-4 weeks as Google re-evaluates your site. Panic at week one is premature; concern at week four is reasonable.
• Check that Google has updated the canonical URLs in its index (GSC > URL Inspection > show the Google-selected canonical)
• Verify all structured data is being picked up (GSC > Enhancements)
• Monitor your backlink profile. If you changed domains, check that your most valuable backlinks are being followed through the redirects and are being attributed to the new domain.

Months 2-6: Recovery Assessment

The honest timeline: meaningful organic recovery from a well-executed migration typically takes 3-6 months. A domain change can take longer. If you’re in a YMYL sector where Google applies heightened scrutiny, expect the upper end of that range.

If traffic hasn’t recovered by month 3: - Audit your redirect map again. Look for broken redirects, chains (redirect > redirect > destination), and loops - Check whether Google is choosing different canonical URLs than the ones you specified - Look for content quality issues on the new site. Did the migration inadvertently change or remove content that was ranking? - Verify that internal linking is as strong on the new site as it was on the old one. Migrations frequently break internal link structures without anyone noticing - Check that your site speed hasn’t regressed. A slower site on a new platform is a common cause of ranking drops that gets misattributed to the migration itself

If traffic hasn’t recovered by month 6, something fundamental went wrong. Common culprits: incomplete redirects, significant content changes made simultaneously with the migration, loss of structured data, or a new site that’s substantially worse from a technical SEO perspective. At this point, a comprehensive audit is needed to diagnose the specific problem.

The Redesign Question

A site redesign and a site migration overlap but aren’t the same thing. If you’re redesigning your website and the URLs, content, and domain stay the same, the SEO risk is manageable. The main concerns are:

• Core Web Vitals changes. New designs often introduce heavier images, more JavaScript, and layout shifts. Test thoroughly.
• Content reflow. If the redesign changes how content appears on the page (different heading structures, content moved around, sections removed or combined), this can affect how Google interprets the page.
• Internal linking changes. New navigation, new footer links, new sidebar content: all of these affect how link equity flows through your site.
• Template-level meta changes. New CMS templates sometimes reset or override title tags, meta descriptions, and canonical tags.

The moment a redesign changes your URL structure, it becomes a migration, and you need the full process described above.

Making It Easier on Yourself

Migrations are stressful because so many things can go wrong, and most of them are invisible until traffic drops. A few things that consistently reduce risk:

• Don’t change everything at once. If you’re redesigning, migrating CMS, and rebranding simultaneously, you’ve made it impossible to diagnose what caused any problems. Separate the changes where possible.
• Invest in the redirect map. If you only do one thing properly, make it this. A complete, accurate, tested redirect map prevents the majority of migration failures.
• Keep content stable during the migration. Rewriting all your content at the same time as migrating is tempting (“we’re rebuilding anyway, let’s refresh everything”). Resist this urge. Migrate first, let rankings stabilise, then improve content incrementally.
• Get SEO involved at the start, not the end. The number of times I’ve been brought into a migration project two weeks before launch, with URLs already finalised and no redirect plan in place, is depressing. SEO needs to be in the room when URL structures are being decided, not after the developers have already built them.

If you’re planning a migration and want to understand the specific risks for your site before committing, a technical SEO audit is the right starting point. It maps what you have, identifies what’s at stake, and gives you a realistic picture of the work involved.