Site migrations represent the single largest concentrated risk to backlink equity that any established website will face. The numbers are sobering: industry analysis indicates that approximately 17% of migrations fail to recover even 1,000 days after launch, down from 42% in earlier studies, but still representing a substantial proportion of projects where years of accumulated authority are functionally written off. Among migrations that do recover, the average recovery timeline is 523 days. Only 10% of migrations actively improve SEO performance — the remaining 90% either return to baseline or fail to do so.
These statistics reflect a fundamental asymmetry. The work required to preserve backlink equity through a migration is documented, replicable, and well within the technical reach of any competent SEO team. The work required to recover from a botched migration is open-ended, expensive, and frequently unsuccessful. This guide provides a structured framework for the former, drawing on documented practice across migrations of varying scope. It is written for technical SEO practitioners, in-house teams responsible for migration projects, and agency strategists who need to translate engineering decisions into measurable equity outcomes for the backlinks that drive ranking.
Migration planning is not separable from broader link strategy. Every backlink earned through legitimate link acquisition carries an expected lifetime measured in years, during which migrations will inevitably occur. The migration plan determines whether those years of accumulated value survive intact or evaporate during transition.
| What this guide covers The four migration types and the distinct risk profile each carriesRecovery benchmarks: realistic timelines, baseline traffic shifts, and what counts as successful migrationThe 12-week migration timeline: pre-launch, launch window, and post-launch phasesThe backlink preservation workflow — inventory, mapping, verification, and outreach reclamationThe launch-day checklist that prevents the most common catastrophic failuresThree case studies: one disaster, one disciplined success, one phased migration with measured outcomes |
The four migration types and their distinct risk profiles
The term ‘site migration’ encompasses several distinct technical changes, each with materially different risk profiles for backlink preservation. Understanding which type of migration you are undertaking is the first analytical step, because the work required varies significantly.
Type 1: Platform migration (CMS change)
Moving from one content management system to another — WordPress to Webflow, Drupal to Shopify, Magento to BigCommerce — while keeping URLs identical. This is the lowest-risk migration type when executed correctly, because no redirects are required and link equity flows naturally to the new platform. The risk concentrates in technical execution: meta tags, structured data, internal linking, and rendering behaviour all need to be replicated exactly. Backlink equity itself is rarely at risk in pure platform migrations unless URL structures change as part of the move.
Type 2: URL structure migration
Changing the URL pattern of the site while keeping the domain identical. Common examples include moving blog posts from /blog/post-title to /resources/post-title, restructuring product categories, or normalising URL casing. This migration type carries moderate-to-high risk depending on how many existing URLs change. Every URL that changes requires a 1:1 redirect, and every external backlink to an old URL must continue to function through that redirect.
Type 3: Domain migration
Moving the entire site from one domain to another — example.com to example.co.uk, or oldbrand.com to newbrand.com. This is the highest-risk migration type because every external backlink now points to a domain that, from Google’s perspective, has effectively died. Recovery depends entirely on redirect quality at the destination domain, and recovery timelines extend into months even when execution is flawless.
Type 4: Protocol or canonical migration
Changes to the canonical URL form: HTTP to HTTPS, www to non-www (or reverse), trailing slash normalisation, or any combination of these. These are technically lower-risk migrations but commonly accumulate redirect debt because teams add layers of redirects rather than consolidating to single hops. The HTTPS-driven audit case in the upcoming case study section demonstrates how these silent accumulations can suppress traffic for years.
Risk comparison matrix
| Migration type | Backlink equity risk | Typical recovery time | Primary failure mode |
| Platform (URLs identical) | Low | 0–14 days | Rendering or metadata loss |
| URL structure | Moderate to high | 30–90 days | Incomplete URL mapping |
| Domain | Very high | 60–180 days | Soft 404s from homepage redirects |
| Protocol/canonical | Low (initially) | Variable | Redirect chain accumulation |
| Combined (multiple at once) | Catastrophic | 180+ days or never | Inability to diagnose cause |
| The ‘do not combine’ principle The single highest-leverage migration decision is refusing to combine migration types. When platform, URL structure, design, content, and rebrand all change simultaneously, diagnosing post-launch problems becomes effectively impossible. Migrate one variable at a time. Stabilise. Then migrate the next. The teams that win migrations treat them sequentially. The teams that lose treat them as one large project. This sequential discipline applies equally to the broader question of how link building strategy interacts with site changes — significant SEO investments should not be made in the immediate window before, during, or after a migration. |
Recovery benchmarks: what ‘successful migration’ actually means
The first step in any migration plan is calibrating expectations. The aggregate data across documented migrations provides clear benchmarks against which to measure your own project.
Industry-wide outcomes
| Outcome | Percentage of migrations | Source |
| Improve SEO performance post-migration | ~10% | Springhill Marketing 2025 analysis |
| Return to pre-migration baseline within 90 days | ~40% | Industry composite |
| Take 90–365 days to recover baseline | ~33% | Industry composite |
| Take 365+ days to recover, or only partial recovery | ~13% | Industry composite |
| Never recover within 1,000 days | ~17% | Multi-year migration study (down from 42%) |
| Suffer 30–60% traffic loss as direct migration consequence | Common | Baba SEO 2026 analysis |
Phase-by-phase traffic expectations
For a well-executed migration, the following traffic pattern is realistic and should be planned for in stakeholder communications:
| Phase | Days after launch | Expected traffic | Status |
| Initial impact | Days 1–7 | 70–85% of baseline | Crawl in progress; redirects being discovered |
| Discovery acceleration | Days 8–21 | 80–92% of baseline | Most redirects evaluated; index rebuilding |
| Stabilisation | Days 22–60 | 92–100% of baseline | Authority transfer largely complete |
| Recovery | Days 61–90 | 95–105% of baseline | Should match or modestly exceed pre-migration |
| Growth | Days 91+ | 100%+ | Migration improvements compound with prior strategy |
| When to act on traffic drops Traffic below 70% of baseline within the first 7 days is normal and does not require emergency action. Traffic below 70% of baseline at day 21 indicates a serious problem that needs immediate diagnostic investigation. Traffic below 90% of baseline at day 60 indicates the migration is significantly underperforming and a structured recovery effort should begin. The threshold that matters is the trajectory, not the absolute number. A site at 75% of baseline trending upward is recovering normally; the same site trending downward is in trouble. |
The 12-week migration timeline
Migration work expands or contracts to fit available time, but the substantive technical activity follows a consistent structure across project scopes. The 12-week timeline below assumes a medium-complexity migration with a substantive backlink portfolio. Smaller migrations can compress this; enterprise migrations with thousands of mapped URLs typically extend it to 16–20 weeks.
Pre-launch phase: Weeks 1–6
Week 1–2: Discovery and baseline establishment
- Comprehensive crawl of the existing site using Screaming Frog, Sitebulb, or equivalent.
- Export every URL returning a 200 status code, including parameter variations and pagination.
- Pull 16 months of Google Search Console URL inspection data — every URL that has earned impressions in this window must be preserved.
- Pull 24 months of organic landing page data from analytics.
- Pull complete backlink data from Ahrefs, Semrush, and Majestic — see our review of the best link building tools for migration audits. Cross-reference any URL with external links into the master inventory.
- Record baseline metrics: organic traffic by landing page, top 200 keyword positions, total indexed pages, Core Web Vitals.
Week 3–4: URL mapping
Build the master URL mapping spreadsheet — the single most important artefact of any migration. The mapping document should include the following columns at minimum:
| Column | Purpose |
| Old URL | Source URL on existing site |
| New URL | 1:1 destination on new site |
| Redirect type | 301 default; 308 for method-preserving cases |
| Backlink count | Total referring domains pointing to old URL |
| Annual organic traffic | Last 12 months of organic visits |
| Priority tier | Critical / High / Medium / Low based on backlinks and traffic |
| Implementation status | Mapped / Implemented / Verified / Failed |
| Verification timestamp | Date of post-launch verification |
| Owner | Team member responsible for this redirect |
This document should live outside the CMS — in a shared spreadsheet or version-controlled CSV — so that it survives platform changes and team turnover. Many catastrophic migrations have failed because the only copy of the mapping was lost during deployment.
Week 5–6: Technical preparation and staging
- Build the new site to staging.
- Implement HTTP basic authentication and IP whitelisting to protect staging from accidental indexing — not robots.txt disallow alone (more on this below).
- Implement the redirect map in staging configuration.
- Pre-launch crawl of staging to verify every mapped URL redirects to a working destination.
- Verify meta tags, canonical tags, hreflang, and structured data on staging match production expectations.
- Verify XML sitemap generation includes only canonical URLs.
- Verify Core Web Vitals on staging meet or exceed baseline.
Launch window: Weeks 7–8
Day −3 to Day −1: Final preparation
- Lower DNS TTL values to enable rapid propagation post-launch.
- Final pre-launch crawl with all redirects validated.
- Stakeholder communications: notify team of launch window.
- Confirm rollback plan exists and is tested.
Launch day
- Deploy new site to production. Verify deployment completed successfully before proceeding.
- Remove staging protections. Remove HTTP authentication, IP whitelisting, noindex tags, and any robots.txt disallow directives. Verify each removal explicitly — this is the single most commonly forgotten step in real migrations.
- Activate the redirect map. All 301 redirects should now be live. Verify a sample of high-traffic URLs immediately.
- Submit new XML sitemap to Google Search Console. Keep the old sitemap accessible for at least 30 days to aid Google’s discovery of redirected URLs.
- Run launch-day verification crawl. Full site crawl checking for 200s, 301s, no 404s, no chains.
- Restore DNS TTL to normal values after confirmed propagation.
Day +1 to Day +7: Intensive monitoring
- Daily crawl of high-priority URLs from the mapping spreadsheet.
- Daily Search Console coverage and error reports.
- Daily organic traffic monitoring with alerts for drops exceeding 25%.
- Document and fix any newly discovered 404s immediately.
Post-launch phase: Weeks 9–12
Weeks 9–10: Backlink reclamation outreach
This is the most underutilised phase of standard migration playbooks. Redirects preserve link equity adequately, but direct links to the new canonical URLs deliver more equity than redirected links to the old URLs. Systematic outreach to update legacy links produces measurable equity uplift.
The reclamation workflow follows the same principles as broader backlink acquisition through outreach:
- Identify the top 100 highest-authority external backlinks pointing to old URLs.
- Sort by referring domain DR and traffic value.
- Prepare a polite, brief outreach email explaining the migration and requesting the link be updated to the new canonical URL.
- Send outreach to the top 50 over a 2-week window — not all at once.
- Track responses and updates. Expected update rate: 25–40% of contacted webmasters will make the change within 30 days.
| Why direct links outperform redirected links Even though Google has stated that 301 redirects pass essentially full PageRank, direct links to canonical URLs eliminate the latency of redirect resolution, simplify the crawl path, and reduce the accumulating risk of redirect chain debt over time. For high-authority backlinks specifically, the equity differential is small per link but compounds across a portfolio. A reclamation programme targeting the top 100 backlinks typically delivers a 3–8% organic traffic lift in addition to baseline recovery, particularly when combined with ongoing digital PR campaigns that produce naturally-direct links to new canonical URLs. |
Weeks 11–12: Stabilisation review and reporting
- Comprehensive technical audit comparing pre-migration baseline against current state.
- Keyword ranking comparison: top 200 terms by pre-migration position.
- Backlink retention rate: percentage of pre-migration referring domains still passing equity to canonical URLs.
- Redirect health: chains, loops, 404 destinations identified and resolved.
- Stakeholder report documenting outcomes, lessons, and ongoing monitoring plan.
The launch-day checklist
Most catastrophic migrations fail not on complex technical issues but on simple checklist items that nobody verified because everyone assumed someone else would. The launch-day checklist below is the minimum verification required before declaring a migration live.
Pre-launch verification (within 4 hours of launch)
- □ Master URL mapping spreadsheet is final and version-controlled.
- □ All planned redirects are implemented in production configuration.
- □ Pre-launch crawl confirms 100% of mapped URLs resolve to working destinations.
- □ No mapped redirects produce 404s, 500s, or chains of 3+ hops.
- □ DNS TTL values lowered for fast propagation.
- □ Backup of current production site secured.
- □ Rollback procedure tested and documented.
Launch-day verification (within 2 hours of launch)
- □ New site reachable from clean network (not just office IP).
- □ HTTP authentication removed from production.
- □ IP whitelisting removed from production.
- □ All staging-specific noindex meta tags removed from production templates.
- □ robots.txt does not contain ‘Disallow: /’ or other broad disallow directives.
- □ Canonical tags point to production URLs, not staging URLs.
- □ Hreflang tags reference production URLs only.
- □ XML sitemap is accessible and contains canonical production URLs.
- □ Sitemap submitted to Google Search Console.
- □ Top 20 most-trafficked URLs verified manually.
Launch-day verification (within 24 hours of launch)
- □ Full-site crawl completed and reviewed.
- □ Search Console coverage report checked for new errors.
- □ Server response times within normal range.
- □ Analytics tracking confirmed firing correctly.
- □ Core Web Vitals measured and within acceptable range.
- □ Internal links updated to point to canonical destinations (not through redirects).
- □ Stakeholders notified of successful launch.
The staging protection trap
Industry surveys indicate that approximately 50% of migration projects use robots.txt ‘Disallow: /’ on staging environments to prevent search engine indexing. This common practice is dangerous for two distinct reasons, both of which contribute to a significant proportion of post-migration disasters.
Reason 1: robots.txt forgotten in production
If the staging robots.txt contains ‘Disallow: /’ and is accidentally pushed to production unchanged, Googlebot stops crawling the entire site. Existing rankings persist for several days while Google’s cache holds, then begin disappearing as pages drop out of the index. By the time the issue is discovered — typically through traffic alerts after 7–14 days — significant equity has already been lost and recovery requires both fixing the robots.txt and waiting for re-crawling, which can take weeks for large sites.
Reason 2: robots.txt is not actually secure
robots.txt is a request, not a directive. Search engines that respect it (Google, Bing) will not crawl disallowed paths, but the directive is publicly visible — anyone can read your robots.txt to discover your staging URL. Less reputable crawlers, scrapers, and competitors can simply ignore it. A staging site secured only by robots.txt is functionally public information.
The correct approach
Use HTTP basic authentication or IP whitelisting on staging. Both approaches prevent indexing because the staging URL is genuinely unreachable to unauthorised users — including Googlebot — without credentials or whitelist membership. Crawlers configured for pre-migration analysis can be granted access via static IP whitelisting or password authentication. The robots.txt file on staging should then reflect the intended production robots.txt, so that pre-launch crawl behaviour matches post-launch behaviour.
| The protocol problem with combining robots.txt and noindex A common follow-on mistake is combining ‘Disallow: /’ in robots.txt with meta noindex tags on individual pages. This combination does not work as intended: because robots.txt blocks crawling, Googlebot never reaches the page to read the meta noindex directive. The page remains indexable from external links, and the noindex protection is functionally inert. Allow crawling, then apply noindex. That is the correct sequence in every production scenario where you want pages excluded from the index. |
Case studies: migration outcomes in 2025–2026
Case Study 1: The £3.8 million domain migration disaster
A European mid-market retailer undertook a £7.6 million website rebuild in 2024, replacing a legacy platform with a modern e-commerce stack on a new domain. The technical team, focused on delivery deadlines, rejected the SEO team’s URL mapping recommendations on the basis that the new URL structure was ‘cleaner’ and ‘more semantic’ than the old one. The migration shipped without 1:1 URL mapping. The retailer lost approximately £3.8 million in organic revenue in the first month following launch.
What went wrong
- Approximately 60% of historical URLs had no redirect at all and returned 404s.
- Approximately 25% were redirected to the new homepage, triggering Google’s soft 404 detection.
- The remaining ~15% with topical redirects passed through 2–3 hop chains because the team had layered the migration on top of an earlier rebrand.
- No backlink reclamation outreach was conducted post-launch.
- Combined platform migration, URL structure change, and domain change in a single launch — making post-launch diagnosis nearly impossible.
Recovery and lessons
Recovery took 9 months. The team rebuilt the URL mapping retrospectively, working from the backlink data of the top 800 historically linked URLs. By month 9, organic revenue had returned to approximately 78% of pre-migration levels — meaning approximately £2.4 million in annualised revenue was structurally unrecoverable because the link equity from URLs that received soft 404 treatment had been functionally written off during the gap period. The case illustrates every major migration anti-pattern in a single project.
Case Study 2: The disciplined B2B SaaS rebrand
A UK B2B SaaS provider, DR 51, rebranded from one domain to a new domain in November 2025. The rebrand was driven by a corporate name change and required complete domain migration. The SEO team had three months of preparation lead time and applied the workflow above in full.
Execution highlights
- Complete URL inventory generated four weeks before launch — 2,847 source URLs mapped 1:1 to destinations.
- Master mapping spreadsheet maintained outside the CMS in version-controlled storage.
- Server-side 301 redirects implemented at the CDN edge for maximum performance.
- Pre-launch verification crawl confirmed all 2,847 redirects resolved to live destinations with no chains.
- Post-launch crawl repeated weekly for 8 weeks, then monthly.
- All internal links updated to point directly to new URLs.
- Backlink reclamation outreach contacted top 73 backlink sources in weeks 4–6 post-launch.
Outcome
Organic traffic on the new domain reached 94% of pre-migration baseline within 21 days. Baseline was exceeded at day 47. By month 4, organic traffic was 18% above pre-migration baseline. The backlink reclamation outreach delivered a 35% acceptance rate among contacted webmasters — 26 of 73 top sources updated their links to direct canonical URLs within 60 days, contributing approximately 4.2 percentage points of the post-baseline lift. The disciplined approach preserved approximately £1.2 million in annualised organic revenue that would have been at risk under a less rigorous workflow.
Case Study 3: The phased platform-only migration
A UK content publisher, DR 64, migrated from a legacy Drupal installation to a modern headless CMS in early 2026. The team deliberately limited the migration scope to platform only — URLs remained identical, content remained identical, internal linking structure remained identical. Design and information architecture changes were deferred to a separate phase 3+ months after migration.
Execution highlights
- URL structure preserved exactly — no redirects required for any indexed URL.
- Meta tags, structured data, hreflang, canonical tags replicated identically on new platform.
- Rendering verified to match legacy output across all template types.
- Core Web Vitals measured and confirmed improved (LCP reduced from 3.1s to 1.8s on the median article).
- Phased rollout: 10% of traffic to new platform for 7 days, then 50% for 7 days, then 100%.
Outcome
Zero detectable backlink equity loss. Organic traffic showed no measurable migration impact across the rollout period. Core Web Vitals improvements translated to approximately 7% organic traffic uplift within 60 days post-launch, attributed to improved mobile-page-experience signals. Total migration timeline: 14 weeks of preparation, 3 weeks of phased rollout, 6 weeks of monitoring. The case demonstrates that platform migrations that preserve URL structure carry minimal risk to backlink equity when executed deliberately. The subsequent information architecture refresh — scheduled for 6 months post-platform-migration — could then be planned and measured against a stable baseline rather than a recovering one.
| The pattern across all three cases The three cases collectively illustrate that backlink preservation through migration is overwhelmingly a function of process discipline, not technical wizardry. The disaster case (Case 1) failed on basic mapping. The success case (Case 2) succeeded on disciplined execution of standard practice. The phased case (Case 3) succeeded by deliberately limiting scope. None of these outcomes required exotic technical capability — they required teams that respected the link equity at stake. This same process discipline characterises every well-run programme across other parts of SEO investment, from anchor distribution management to link building tool stack selection. |
Common migration mistakes that destroy backlink equity
Mistake 1: Combining migration types in a single launch
Already discussed above as the ‘do not combine’ principle. Platform, URL structure, domain, design, content, and rebrand changes should each be undertaken sequentially with stabilisation between phases. The cost of combining is that you cannot diagnose post-launch problems. The cost of separating is some additional project time. The asymmetry strongly favours separation.
Mistake 2: Incomplete URL inventory
Migrations that build the inventory from the new site’s content rather than the old site’s historical URLs miss every URL that has been removed, redirected, or evolved over the site’s lifetime. The complete inventory must include URLs from Screaming Frog crawl, 16 months of Search Console data, 24 months of analytics landing pages, and backlink databases — combined and deduplicated.
Mistake 3: Mass redirects to the homepage
When teams discover that some legacy URLs lack obvious topical equivalents on the new site, the temptation is to redirect everything to the homepage to ‘preserve some value’. Google identifies this pattern as a soft 404 and treats the source URLs as removed pages. If a legacy URL has no topical equivalent, return 410 Gone (preferred) or 404 Not Found. The equity is lost either way, but soft 404s actively contaminate the rest of the site’s signals.
Mistake 4: Skipping the backlink reclamation outreach
This is the single highest-ROI activity in any migration that is too often skipped. Updating 25–40% of high-authority backlinks to point directly to new canonical URLs eliminates redirect debt at the source and delivers measurable equity uplift. The investment is a 2-week outreach campaign with a templated email; the return is sustained traffic improvement that compounds over years.
Mistake 5: Forgetting to remove staging protections
Discussed above as the staging protection trap. Verify removal of robots.txt disallow, noindex meta tags, HTTP authentication, IP whitelisting, and canonical tags pointing to staging URLs as the first launch-day step. This single mistake has caused more migration disasters than any other technical issue.
Mistake 6: Inadequate post-launch monitoring
Many teams treat launch as the end of the migration project. It is the beginning of the highest-risk monitoring period. Daily verification for the first 7 days, weekly for the first 8 weeks, and monthly thereafter is the minimum monitoring cadence for any substantive migration. Problems caught in the first 14 days have meaningfully better recovery prospects than problems caught at day 60.
Mistake 7: Treating migration as separate from broader SEO strategy
Migration planning interacts directly with every other SEO activity. Sites in active link acquisition campaigns should pause new outreach in the 4 weeks before launch and the 6 weeks after — partly to avoid muddying the migration baseline, partly to focus team capacity on the migration itself. Sites undergoing digital PR or newsjacking activity should similarly time launches outside major news cycle moments. Migration sits at the intersection of technical SEO and the broader programme — not separate from it. The same applies to guest posting campaigns in progress at the time of migration.
International migrations and multi-region considerations
Sites operating across multiple geographic markets face additional migration complexity beyond the workflow above. Hreflang management, ccTLD transitions, and language-specific redirect handling all introduce failure modes that monolingual migrations avoid. For organisations operating in multiple regions, the migration plan must explicitly account for the dependencies between language variants and the regional link profiles built in each market.
Key international migration considerations
- Hreflang consistency: Every language/region variant must reference correct production URLs, and every variant must be reciprocally linked in hreflang annotations.
- Per-market redirect mapping: Each language version of each URL needs its own 1:1 mapping. A site with 5,000 English URLs and 4 additional languages has 25,000 source URLs requiring individual mapping.
- Region-specific backlink reclamation: The reclamation outreach for German publications should be in German; for French publications in French. Region-specific outreach norms apply — see our guides on link building for European markets and link building in India and South Asia for region-specific outreach guidance.
- ccTLD migration timing: Moving between ccTLDs (e.g., .de to .eu, or consolidating .uk and .com) involves geo-targeting reset in Search Console. Expect longer recovery timelines for ccTLD changes — 6+ months is not unusual.
Tools for migration planning and execution
| Tool | Migration use case | Cost (May 2026) |
| Screaming Frog SEO Spider | Pre and post-launch full-site crawling | £199/yr |
| Sitebulb | Visual redirect chain analysis and crawl reports | £35/mo |
| Ahrefs Site Explorer + Site Audit | Backlink inventory + post-launch redirect health | From £99/mo |
| Semrush Site Audit + Position Tracking | Keyword baseline + ranking monitoring | From £119/mo |
| Majestic | Backlink data for inventory completeness | From £41/mo |
| Google Search Console | URL inspection, coverage, sitemap submission | Free |
| httpstatus.io | Bulk redirect verification | Free |
| DeepCrawl / Lumar | Enterprise migration management | Custom |
| LinkResearchTools | Risk-focused backlink audit for high-stakes migrations | From £499/mo |
For most migrations, the combination of Screaming Frog (or Sitebulb), Ahrefs (or Semrush), and Google Search Console covers the full workflow at reasonable cost. Enterprise migrations with thousands of URLs and complex international structures benefit from DeepCrawl/Lumar’s scale-oriented features. The full review of link building tools applicable to migration work covers selection criteria in depth.
Integrating migration discipline with the broader link strategy
Migration planning sits within the broader programme of link investment and authority development. Three principles apply:
- Treat migration as link infrastructure work, not deployment work. The redirect map is link building infrastructure that protects everything you have earned through ethical link acquisition. The mapping spreadsheet should be treated with the same care as the campaign tracking documentation for active outreach work.
- Plan migrations around link campaign cycles. Avoid scheduling migrations immediately after major successful campaigns — the wave of new backlinks pointing to URLs that may then be restructured creates unnecessary equity risk. Allow at least 90 days of stabilisation between a major link campaign and a migration. The same principle applies to featured snippet optimisation work and ongoing ranking campaigns.
- Use migration as an opportunity to consolidate prior redirect debt. Sites that have undergone multiple migrations typically carry accumulated redirect chains from each prior transition. The next migration is the ideal opportunity to consolidate all historical chains to single-hop redirects — turning what would otherwise be additive complexity into a one-time cleanup. The compound returns from this kind of housekeeping align directly with the data-led approach catalogued in our link building statistics for 2026.
The strategic position on migrations in 2026
Three principles emerge from the data and the case studies.
First, migration outcomes are deterministic, not stochastic. The 90% of migrations that fail to actively improve SEO performance, and the 17% that never recover even after 1,000 days, are not unlucky — they are predictable outcomes of identifiable process failures. Disciplined teams that follow the workflow above consistently produce migrations that match or modestly exceed pre-migration performance. Teams that skip the discipline consistently produce the disaster outcomes documented in industry analyses.
Second, backlink preservation is the highest-leverage discipline within migration work. URL mapping, redirect implementation, and backlink reclamation outreach are the activities that determine whether years of accumulated link equity survive transition. Every other migration activity — content review, design refresh, technical optimisation — is downstream of whether the link infrastructure works. Get the link work right and other improvements compound. Get the link work wrong and other improvements cannot compensate.
Third, the discipline that protects migrations is the same discipline that builds authority in the first place. Teams that treat link acquisition as a careful, documented programme — through digital PR, guest posting, and other ethical strategies — naturally treat migrations with the same care. Teams that treat link acquisition as a tactical scramble naturally treat migrations the same way. The migration outcome reveals the underlying SEO culture more honestly than almost any other project type. The protective work documented above is genuinely accessible to any competent SEO team. The question is whether the team is structurally willing to do it.
Frequently asked questions
How long does a site migration typically take to recover?
For well-executed migrations, recovery to baseline typically happens within 30–90 days, with full stabilisation at day 90. For platform-only migrations preserving URL structure, recovery can occur within 0–14 days. For complex domain migrations, expect 60–180 days. The industry-wide average across all migration types is approximately 523 days, but this average is heavily skewed by failed migrations — well-executed migrations should not approach this figure.
What percentage of migrations actually improve SEO?
Approximately 10% of migrations improve SEO performance post-launch. The remaining 90% either return to baseline (the majority) or fail to fully recover. Improvement is most achievable in platform-only migrations where the new platform delivers measurably better Core Web Vitals, mobile experience, or rendering performance. URL structure changes and domain migrations rarely improve SEO on their own — they typically protect equity at best.
Can I migrate during a peak traffic season?
Avoid it. Peak traffic seasons amplify migration risk because more eyes notice traffic drops, conversion losses compound, and remediation pressure intensifies. The ideal migration window is during a predictable seasonal trough for your specific industry. For e-commerce, January and February or July are typical low-risk windows. For B2B, late summer or December are typical. Always plan around your specific business cycle.
Should I keep the old domain active after migration?
Yes, indefinitely. The old domain must continue to serve 301 redirects to the new domain for as long as external backlinks exist pointing to it — which, in practice, is forever. Domain renewal costs are trivial relative to the equity at stake. There is no scenario in which letting an old domain expire benefits SEO. Maintain the domain registration, the DNS configuration, and the redirect server in perpetuity.
How do I prioritise URLs for backlink reclamation outreach?
Sort all backlinks to old URLs by referring domain authority (DR), referring domain traffic, and link placement quality. Target the top 50–100 by composite score. Within this list, prioritise links from high-traffic content pages over low-traffic homepage placements. A single DR 80 editorial backlink delivers more equity uplift through reclamation than 20 DR 30 directory backlinks combined. Focus outreach capacity on the high-leverage end of the portfolio.
What’s the expected backlink reclamation response rate?
For polite, brief, professional outreach explaining a legitimate migration, expect 25–40% of contacted webmasters to update the link within 30 days. Higher response rates correlate with the recipient’s relationship to your organisation — partner sites, customer testimonials, and editorial relationships typically respond at 50%+ rates. Cold outreach to journalists who covered you years ago typically responds at 15–25%.
Should I migrate to HTTPS as part of a larger migration?
If your site is still on HTTP in 2026, migrate to HTTPS first as a standalone protocol migration, stabilise, then conduct any further migration work. Combining an HTTPS migration with platform, URL, or domain changes creates a multi-variable diagnostic problem that is meaningfully harder than two sequential migrations. The HTTPS migration itself is typically low-risk when executed correctly with proper redirects.
How do I handle pages that have no equivalent on the new site?
If a legacy URL has no topical equivalent on the new site, return 410 Gone (preferred) or 404 Not Found. Do not redirect to the homepage — this triggers Google’s soft 404 detection and contaminates other ranking signals. If the page had substantial backlinks, consider creating a ‘best alternative’ page on the new site that genuinely serves the original intent, and redirect there. Never compromise topical relevance just to preserve a redirect; the soft 404 outcome is worse than the 410.
Can I A/B test a migration?
Not in the conventional sense — running both old and new URLs in production simultaneously creates duplicate content and canonical confusion. However, phased rollout is a powerful risk-mitigation approach: send 10% of traffic to the new site for 7 days, then 50% for 7 days, then 100%. Phased rollout allows early detection of rendering, conversion, or technical issues before full exposure. This works particularly well for platform migrations where URLs remain stable.
What’s the most underestimated migration risk?
Internal link discrepancies. Every internal link on the new site that points to a redirected URL works in browsers but creates crawl inefficiency and dilutes the canonical signal. After migration, every internal link should point directly to the canonical destination. This audit is rarely included in standard migration checklists and is one of the highest-leverage post-launch optimisations available. Schedule it for week 9–10 of the standard timeline.
Should AI crawlers and LLM citations affect migration planning?
Yes, increasingly. AI Mode, ChatGPT, Perplexity, and similar systems rely on the same canonical signals as classical search. A clean migration that preserves URL stability and consolidates redirects to single hops protects both classical SERP ranking and AI citation visibility. The reverse is also true: a botched migration that creates chains and soft 404s degrades AI citation performance alongside organic rankings. The infrastructure investment in migration discipline now pays compound returns across both classical and AI search ecosystems.
