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 improvement rather than inadvertently degrading it.
Phase 2: The URL Mapping Process – The Single Most Consequential Document in Any Migration
If a UK business migration fails catastrophically, the root cause is almost always an incomplete or inaccurate URL mapping document. This is not an exaggeration — it is the most consistent pattern across documented migration failures in the SEO industry.
Building the complete URL mapping spreadsheet:
Every single indexable URL from the pre-migration crawl must have a corresponding row specifying exactly which URL on the new site it will redirect to. Not “most” URLs. Not “the important ones.” Every single one.
The spreadsheet should contain, at a minimum: the old URL, the new URL, the redirect type (301 for permanent moves — almost always the correct choice for migrations), the current ranking position and monthly clicks for that URL (to prioritise QA attention), and a status column tracking whether the mapping has been implemented and verified.
Handling the categories of URLs that complicate mapping:
Content is being consolidated. If multiple old pages are being merged into a single new page (a common outcome of content audits conducted alongside migrations), each old URL must redirect to the single consolidated new URL. Do not redirect multiple old pages to the homepage or to a generic category page as a shortcut — this is one of the most common and most damaging migration errors, because it signals to Google that none of the specific content from the old pages has a genuine equivalent on the new site, triggering “soft 404” treatment that suppresses the authority transfer entirely.
Content is being removed entirely. If a page genuinely has no equivalent on the new site and the content is being deliberately discontinued, resist the urge to redirect it to the homepage by default. Evaluate whether the page has meaningful backlinks or historical traffic. If it does, consider whether a genuinely relevant redirect destination exists elsewhere on the new site, even if it is not a direct one-to-one content match. If no relevant destination exists and the page has minimal external authority, allowing it to return a proper 410 (Gone) or 404 status is more honest to Google than a forced, irrelevant redirect — though for pages with meaningful backlink equity, a 301 to the most topically relevant available page is almost always preferable to losing that authority entirely.
Parameter and duplicate URLs. Old sites frequently have accumulated parameter-based URL variants, pagination artefacts, and other technical debt that should not be carried forward into the new site’s redirect map. These should be identified and excluded from the primary mapping, but you must verify whether any of them have inadvertently acquired backlinks or rankings (cross-reference against your backlink export and Search Console query data) before excluding them — what looks like technical debt sometimes carries real authority that needs preserving.
Real-world example: A UK furniture retailer migrating from a legacy ecommerce platform to Shopify identified 14,000 product URLs in their pre-migration crawl. Their initial migration plan proposed redirecting any discontinued product URL to the relevant category page — a seemingly sensible simplification. Cross-referencing against their backlink export revealed that 340 of these discontinued product URLs had meaningful external backlinks, including several from UK interior design publications linking to specific, popular product images and reviews. The migration plan was revised to create dedicated “this product has been discontinued, here are similar alternatives” pages for these 340 high-authority URLs rather than generic category redirects — preserving the specific relevance signal that the original backlinks had been built around, rather than diluting it into a generic category page redirect.
Phase 3: Pre-Launch Technical Validation
Before the new site goes live, a structured technical validation process on the staging environment catches the errors that, if discovered post-launch, are dramatically more expensive to fix in terms of lost ranking time.
The pre-launch validation checklist:
Redirect implementation testing. Test every redirect in the mapping spreadsheet against the staging environment (or, where the redirect logic can be tested without full staging deployment, against the redirect rules directly). Use a tool like Screaming Frog’s “Always Follow Redirects” crawl mode against a list upload of all old URLs to verify that every single one resolves to its intended destination with a 301 status code, not a 302 (temporary redirect, which does not pass full ranking authority with the same confidence) and not a redirect chain (old URL to intermediate URL to final URL, which dilutes authority transfer and slows page load).
Robots.txt verification. Confirm the staging environment’s robots.txt is blocking search engine crawling (staging sites accidentally left crawlable and indexed by Google are a common, embarrassing, and damaging migration error) and that the production robots.txt, ready for launch, correctly allows crawling of all intended sections while blocking any genuinely non-indexable areas (admin sections, internal search results, filtered parameter URLs).
XML sitemap preparation. Build the new site’s XML sitemap covering every URL intended for indexation, structured and ready for submission immediately upon launch. Do not rely on the new CMS’s default sitemap generation without verification — confirm it includes all intended URLs and excludes any that should remain unindexed.
Canonical tag audit. Verify every page on the staging site has a correct, self-referencing canonical tag (or, where intentional consolidation has occurred, a canonical pointing to the correct primary version). Canonical tag errors introduced during platform migrations — often a default CMS behaviour that conflicts with the intended URL structure — are a common source of post-migration indexation problems.
Structured data parity check. Compare the schema markup implementation on the staging site against the pre-migration documentation. Confirm that Organisation, LocalBusiness, Article, Product, and FAQ schema (whichever types were present pre-migration) have been correctly rebuilt on the new platform, not silently dropped during the rebuild process — a very common occurrence when migrating between platforms with different schema implementation defaults.
Content parity verification. For your highest-priority pages (identified from the traffic and backlink baseline), manually compare the old page content against the new page content to confirm no meaningful content has been lost, truncated, or altered in ways that change the page’s topical focus. Migrations frequently involve content “cleanup” that inadvertently removes the specific paragraphs, sections, or keyword-relevant content that earned the page’s original rankings.
Internal linking continuity. Verify that the new site’s internal linking structure preserves the link equity flow patterns documented in the pre-migration audit — particularly ensuring that high-authority pages continue linking to the commercially important pages they previously supported, rather than the new site’s navigation and content linking defaulting to a different pattern that inadvertently starves previously well-supported pages of internal authority.
Mobile and Core Web Vitals testing. Run PageSpeed Insights and mobile usability testing against the staging environment for a representative sample of page types before launch. Confirm the new site meets or exceeds the pre-migration Core Web Vitals baseline — a migration that degrades site speed is actively working against the SEO goals the migration was presumably intended to support.
Phase 4: The Launch Sequence
The actual go-live moment requires a precise sequence of actions, executed in order, with verification at each step before proceeding to the next.
Step 1: Final pre-launch crawl comparison. Run a final Screaming Frog crawl of the staging environment immediately before launch and compare the URL count, redirect mapping, and technical configuration against the validated checklist one final time. Changes made during the development process between initial validation and launch are a common source of last-minute errors.
Step 2: DNS and redirect activation. Execute the technical switch — DNS changes for domain migrations, redirect rule deployment for URL structure changes — during a low-traffic period for the business (typically early UK morning hours, outside core business hours for B2B sites, or outside peak shopping hours for ecommerce).
Step 3: Immediate post-launch redirect verification. Within minutes of the switch going live, re-run the full redirect verification crawl against the production environment (not staging) to confirm every redirect is functioning correctly on the live site. Differences between staging and production environment configuration are common, and this step catches them before Google’s crawlers encounter them at scale.
Step 4: XML sitemap submission. Submit the new site’s XML sitemap to Google Search Console immediately. If the property is a domain change, ensure the new property has been added and verified in Search Console in advance of launch — this should be completed during the pre-launch phase, not scrambled together on launch day.
Step 5: Change of address tool (for domain migrations). If the migration involves a domain change, use Google Search Console’s Change of Address tool to formally notify Google of the domain transition. This tool exists specifically to accelerate Google’s recognition of the migration and should always be used for domain-level changes — it is frequently overlooked in UK business migrations, and its omission measurably slows the authority transfer process.
Step 6: Manual URL inspection and indexing requests for priority pages. For your top 20 to 30 highest-traffic, highest-authority pages, use Search Console’s URL Inspection tool to request indexing of the new URL directly. This does not guarantee immediate re-crawling, but accelerates the process for your most commercially important pages relative to passive waiting for Google’s natural re-crawl schedule.
Phase 5: Post-Launch Monitoring – The 90-Day Critical Window
The first 90 days following a large-scale migration require significantly more intensive monitoring than standard ongoing SEO management. This is the window where problems, if they exist, will surface — and where rapid identification and correction determine whether a minor technical issue becomes a permanent ranking loss.
Daily monitoring for the first two weeks:
Check Google Search Console’s Coverage report daily for any spike in errors — particularly “Submitted URL not selected as canonical,” “Page with redirect,” or “Crawled, currently not indexed” statuses, all of which indicate the new site’s pages are not being indexed as intended. Check the Performance report daily for any sudden drop in total clicks or impressions that exceeds normal day-to-day variance.
Monitor server logs (as covered in our dedicated log file analysis guide) for any spike in 404 or 500-series responses being returned to Googlebot — this is often the earliest, most direct signal of a redirect mapping gap or technical configuration error before it shows up in Search Console’s slower-updating reports.
Weekly monitoring for weeks three through twelve:
Compare weekly organic traffic and ranking position data against the pre-migration baseline for your top 50 priority pages. Some temporary ranking fluctuation in the two to four weeks following a migration is normal and expected as Google re-crawls and re-evaluates the new site structure — this is not itself a cause for alarm. Sustained decline beyond four weeks, or decline concentrated in specific page categories rather than distributed evenly, indicates a specific technical problem requiring investigation rather than normal migration volatility.
The recovery escalation framework:
If traffic decline exceeds 20% and persists beyond four weeks, conduct an immediate full technical audit: re-verify all redirects, re-check canonical tags, re-verify structured data, and review the server log data for crawl pattern anomalies. The most common causes of persistent post-migration decline are: incomplete redirect mapping that was missed during pre-launch validation, canonical tag conflicts introduced by the new CMS, accidental noindex tags applied during the build process (extremely common with WordPress migrations where a “discourage search engines” setting is left enabled from staging), or unintentional content changes that altered the topical focus of previously well-ranking pages.
The Backlink Migration Dimension Most UK Businesses Skip
Beyond the technical redirect infrastructure, a complete migration strategy includes proactive outreach to update the highest-value backlinks pointing to old URLs, directing them to point at the new URLs directly rather than relying on redirects indefinitely.
While 301 redirects pass the substantial majority of link equity in most cases, direct links to the live URL are unambiguously stronger than links passing through a redirect chain — and reducing reliance on redirects also reduces the technical surface area that could fail during future site changes.
For your top 30 to 50 referring domains identified in the pre-migration backlink audit, a brief, factual outreach email — “we’ve recently updated our website structure; the page you linked to [old URL] now lives at [new URL] — would you mind updating the link when convenient?” — converts at meaningfully higher rates than typical cold link outreach, because you are not asking for a new favour, simply requesting an update to a link the site owner has already decided is valuable enough to include.
Real-World Example: A UK Financial Services Migration Done Right
A UK financial advisory firm migrated from a ten-year-old custom-built website to a modern, faster WordPress implementation, simultaneously restructuring their URL hierarchy and consolidating 40 thin, overlapping content pages into 12 comprehensive resource pages.
The pre-migration audit documented 1,200 indexed URLs, a backlink profile of 4,800 referring domains, and a 12-month organic traffic baseline of 38,000 monthly sessions. The URL mapping spreadsheet specified individual redirect destinations for all 1,200 URLs, including the consolidation logic for the 40 pages being merged into 12. Pre-launch validation caught and corrected 23 redirect errors and 4 canonical tag conflicts before launch.
Following the documented launch sequence and 90-day monitoring protocol, the site experienced a temporary 8% traffic dip in the first three weeks — within the normal range of expected migration volatility — before recovering to 103% of the pre-migration baseline by week ten. The consolidated resource pages, carrying the combined authority signal of the 40 original pages, achieved higher rankings for their target keywords than any of the original 40 pages had individually achieved, validating the consolidation strategy. Backlink outreach to the firm’s top 40 referring domains successfully updated 17 links to point directly at new URLs within eight weeks of launch.
The contrast with botched migrations in the same sector is instructive: a competing financial advisory firm that migrated platforms six months later, without equivalent pre-migration documentation or redirect mapping rigour, lost 61% of organic traffic within three weeks and had not recovered to pre-migration levels eight months later.
The Strategic Takeaway: Migration Risk Is a Process Failure, Not a Technical Inevitability
The traffic losses that follow website migrations are not an unavoidable cost of progress. They are the predictable, almost entirely preventable consequence of treating SEO continuity as a post-launch concern rather than a core requirement embedded in the migration plan from its earliest stages.
Every catastrophic migration failure documented in the SEO industry traces back to one or more of the same root causes: incomplete URL mapping, inadequate pre-launch technical validation, missing redirect implementation, or insufficient post-launch monitoring to catch and correct problems before they compound into permanent ranking losses. None of these causes is technically difficult to prevent. They require discipline, documentation, and the institutional recognition that a website migration is fundamentally an SEO project with a development component, not a development project with an SEO afterthought.
Planning a Migration? Protect Your Rankings Before You Build.
At SEO Syrup, we manage the SEO dimension of large-scale website migrations for UK businesses — from the pre-migration audit and complete URL mapping through pre-launch technical validation, launch sequence management, and the critical 90-day post-launch monitoring period.
We have seen what happens when migrations go wrong, and we have built the process discipline that prevents it. If your business is planning a platform change, a domain change, a URL restructure, or any combination of these, the most important SEO decision you will make is bringing in the right process before development begins — not after the damage has already been done.
