Algorithm updates get the blame. Migrations do the damage.

Because they are usually managed as design or engineering projects with SEO consulted late or not at all. The recurring causes are mundane and preventable: incomplete URL inventories (nobody knew page X ranked), redirect maps built page-by-page and abandoned at 80%, changed internal linking that strands authority, content quietly trimmed during redesign, blocked staging environments accidentally shipped live, and no pre-migration baseline to measure the damage against. Algorithm updates get the blame; migrations do the damage.

Five phases. Inventory: full crawl, ranking, traffic and backlink baselines captured before anything changes. Mapping: redirects designed at template logic level (not URL-by-URL) so nothing is missed, with edge cases explicitly listed. Validation: staging crawled and tested against the inventory, redirects verified in bulk, schema and rendering checked. Launch: monitoring windows with defined thresholds and agreed rollback criteria. Recovery: daily comparison against baseline for the fortnight after, so drift gets caught in days, not quarters.

Frequently, and the sooner the better: recoveries in the first weeks usually restore most of the loss, while sites that waited months face compounded damage (lost rankings decay further, competitors consolidate). The rescue sequence is forensic: recover the pre-migration URL set from archives and Search Console history, identify unredirected and misredirected paths, restore trimmed content, repair internal linking, and resubmit systematically. We publish honest expectations: not every migration recovers fully.

In rough order: domain changes (everything moves at once), replatforms with URL structure changes (Shopify, Salesforce and similar impose their own patterns), consolidations of multiple sites into one, internationalisation restructures (hreflang gets rebuilt while URLs move), and design-only refreshes that quietly change templates, content and linking. The last is the sneaky one: nobody calls it a migration, so nobody plans for it, and rankings drop anyway.

At URL-structure decisions, which usually happen during platform selection or wireframing, months before launch. SEO involvement at "we launch Friday" limits us to damage documentation. Realistically: engaged four to eight weeks before launch we can protect properly; engaged during platform choice we can prevent the structural mistakes entirely and often improve architecture in the same motion.

By inventorying it as an asset: which pages carry rankings and links, what their content actually is, and what the new design proposes to cut. Redesigns routinely trim "wordy" pages that were ranking precisely because of that content, and stakeholders discover the cost afterwards. The protection is a content-parity check before launch: every ranking page keeps its substance or gets a deliberate, documented decision.

Protection engagements from £2,500 for standard business sites, £6,000+ for large or complex migrations (multi-domain, international, e-commerce at scale). Emergency rescues scoped after triage, typically £2,000-£8,000 depending on damage and site size. The arithmetic is consistent: protection costs a fraction of rescue, and rescue costs a fraction of the lost revenue.