18 June 2026

There is a specific kind of dread that experienced SEO professionals feel when a stakeholder says the words “we’re rebuilding the website.” Not because website rebuilds are inherently bad — a modern, faster, better-designed site is a genuine improvement. The dread comes from years of evidence that website migrations are the single most common cause of catastrophic, sudden organic traffic loss in the entire discipline of SEO. A UK business that has spent three years building domain authority, earning backlinks, and climbing rankings can lose 40, 60, or 80% of its organic traffic within a fortnight of a poorly executed migration — not because Google’s algorithm changed, not because a competitor improved, but because the technical transition between the old site and the new one broke the signals that Google had been using to rank it. This is almost always avoidable. The traffic loss that follows a botched migration is not bad luck. It is the predictable consequence of a process that treated SEO as an afterthought to be addressed after launch, rather than a core requirement built into the migration plan from day one. This guide is the complete migration framework: the pre-migration audit, the technical mapping process, the launch sequence, and the post-launch monitoring discipline that protects UK businesses from the traffic catastrophes that migrations routinely cause — and the recovery process for those who are reading this after the damage has already occurred. What “Migration” Actually Means – and Why Each Type Carries Different Risk The term “website migration” covers several distinct scenarios, each carrying a different risk profile and requiring different technical safeguards. Understanding which type of migration you are undertaking determines which risks deserve the most attention. Platform migration (e.g., moving from a custom-built site to WordPress, or from WordPress to Webflow) carries the highest technical risk because the underlying URL structure, page templates, and rendering method typically change substantially. This is the migration type most likely to break large numbers of URLs simultaneously if not carefully managed. Domain migration (e.g., changing from oldcompanyname.co.uk to newcompanyname.co.uk, or moving from a .com to a .co.uk) carries the highest authority transfer risk. Every backlink pointing to the old domain needs to be redirected, and Google’s domain-level trust signals — built over years — need to transfer to the new domain through a carefully executed 301 redirect strategy. URL structure migration (e.g., flattening a deep folder structure, removing date stamps from blog URLs, or changing from /products/category/item to /item) carries high redirect mapping risk because even small structural changes can affect thousands of URLs across a large site, each requiring individual redirect mapping. HTTP to HTTPS migration carries a lower but still meaningful risk, primarily around mixed content errors, canonical tag conflicts, and incomplete redirect coverage if not every HTTP URL is properly redirected to its HTTPS equivalent. Site redesign without URL changes carries the lowest technical risk but still requires careful attention to content preservation, internal linking continuity, and technical implementation quality (page speed, mobile rendering, schema markup) to avoid inadvertent ranking signal loss even when URLs remain stable. Most large-scale UK business migrations combine several of these types simultaneously — a platform migration that also restructures URLs and moves to a new domain, for instance — which compounds the risk and the corresponding need for rigorous process discipline. Phase 1: The Pre-Migration Audit – Documenting Everything Before You Touch Anything The single most important principle in migration SEO is this: you cannot protect what you have not measured. Before any development work begins on the new site, a comprehensive audit of the existing site’s current performance, structure, and technical configuration must be completed and documented. The complete pre-migration audit checklist: Full site crawl and URL inventory. Run a complete Screaming Frog crawl of the existing site and export every indexable URL, along with its title tag, meta description, H1, word count, and current internal link count. This becomes the master inventory against which every URL on the new site will be mapped. Current ranking and traffic baseline. Export 12 months of Google Search Console data — every query, every page, click and impression data, and average position — filtered for UK traffic. Export 12 months of GA4 organic traffic data by landing page, including conversion data where available. This baseline is what you will compare post-migration performance against, and it is also what will reveal exactly which pages and queries are most critical to protect during the transition. Backlink profile export. Export the complete backlink profile from Ahrefs (or Semrush), including every referring domain and the specific target URL each backlink points to. This data is essential for two reasons: it identifies which pages on the current site carry the most external authority (and therefore require the most careful redirect handling), and it provides the basis for post-migration outreach to update high-value backlinks to point directly at the new URLs rather than relying on redirects indefinitely. Indexation status documentation. Use Google Search Console’s Index Coverage report to document exactly how many pages are currently indexed, and export the list. This becomes the benchmark for confirming that the new site achieves equivalent indexation after migration — a critical signal that the migration has not caused content to silently drop out of Google’s index. Current technical configuration documentation. Document the existing robots.txt configuration, the existing XML sitemap structure and submission status, current canonical tag implementation, current hreflang configuration if applicable, and current structured data implementation across page types. Every one of these technical elements needs to be replicated, and ideally improved, on the new site — but replicated first, improved second, never simultaneously with the migration itself if it can be avoided. Core Web Vitals baseline. Record current Core Web Vitals scores (LCP, INP, CLS) from Google Search Console’s Core Web Vitals report and PageSpeed Insights for a representative sample of page types. A migration is frequently justified partly by performance improvement ambitions — but you need the baseline to confirm the new site actually delivers that