The playbook we run every website migration through

Every website migration that goes wrong follows the same script. Someone decides the old site looks dated, an agency quotes a shiny rebuild, and six months later organic traffic has halved and nobody can explain why. The fix is a repeatable playbook applied before a single line of new code is written, not a prettier design.

Here is the one we use.

Why do most migrations destroy organic visibility?

Because the new site launches without the old site's signals baked in. URLs change without redirects. Internal link equity scatters. Pages that ranked for niche queries disappear entirely because nobody audited them before the build started.

Half of UK SMEs now use AI tools to accelerate content and development work, which is good, but speed without structure makes migrations worse, not better. You can ship a broken site faster than ever before.

The other culprit is the handoff model. A design agency builds the site, a developer deploys it, and an SEO consultant is brought in three weeks after launch to explain the damage. By then the crawl budget has been wasted, Google has re-indexed the new URL structure, and the client is staring at a six-month recovery timeline.

We run all four stages in parallel, not sequentially. That is the only way to avoid the handoff gap.

Stage one: extract everything before you touch anything

Before we write a brief, open Figma, or spin up a Next.js project, we extract the full picture of the existing site.

That means:

• A complete crawl of every indexed URL, with status codes, canonical tags, and inbound internal links mapped
• A 12-month GSC export covering impressions, clicks, and average position at URL level
• A full redirect inventory, because most sites already have a graveyard of old redirects nobody documented
• A content audit scored by traffic contribution, not by whether someone likes the copy
• A schema and structured data snapshot

When we rebuilt purple.ai for Purple, the WiFi analytics company with 80,000-plus venues, the existing site had accumulated years of content across 13 locales. The new build ended up with 6,500-plus URLs across those locales on Next.js. Without the extraction stage, a migration of that scale would have been guesswork. With it, every URL had a destination, every redirect had a source, and every locale had its hreflang wired before the domain switched.

The extraction stage is unglamorous: a spreadsheet and a crawl tool and a lot of decisions about what to keep, consolidate, or kill. But skipping it is how you lose rankings you spent years earning.

Stage two: rebuild with visibility baked in, not bolted on

Most agencies treat SEO as a post-launch checklist. We treat it as a build constraint, the same way performance budgets and accessibility standards are build constraints.

In practice that means:

• URL structure agreed before development starts, not after
• Redirect map implemented in the codebase, not in a plugin, not in a spreadsheet someone will action later
• Metadata templating built into the component system so every programmatic page inherits correct title and description patterns
• Structured data implemented at the component level, not injected via a third-party tag
• Core Web Vitals targets set as acceptance criteria on the staging environment
• Hreflang (where relevant) validated in staging before go-live

For our own site, this discipline meant that when we migrated to the current stack, we carried forward every URL that had earned any meaningful signal and built the redirect map into the deployment pipeline. The site launched with zero broken internal links and a clean crawl on day one.

The rebuild stage is also where we make the structural decisions that will affect content for years. Flat versus deep URL hierarchies. Whether to use subdirectories or subdomains for different content types (almost always subdirectories). How to handle pagination. These are not exciting questions but they have long tails.

Stage three: switch on the content engine before launch, not after

This is the stage most businesses skip entirely, and it is the one that separates sites that recover traffic quickly from sites that flatline for six months.

The content engine has two parts.

First, programmatic content where it earns its place. For Bidwell, our live tender-response product, we built 2,100-plus programmatic pages indexed against 32,858 UK contract-award records. Each page is genuinely useful, not thin filler. The indexation came because the content answered real queries, not because we gamed a template. That is the test: would a person find this page useful, or does it only exist to capture a keyword?

Second, editorial content planned against the gap analysis from stage one. If the extraction audit showed that certain query clusters drove traffic on the old site, the new site needs content ready to serve those clusters on day one. Launching a rebuilt site with a blank blog is a choice to restart from zero.

Research from Orbit Media's 2025 blogging survey shows a clear correlation between publishing frequency and reported strong results, which is not surprising, but the more useful finding is that depth and original research outperform volume. One well-structured post with a real point of view beats twelve thin ones.

We use Contentwell to run the editorial pipeline: briefing, drafting, and publishing on a cadence that does not depend on someone remembering to write something this week.

Stage four: validate, monitor, and close the loop

Go-live starts a 90-day monitoring window where problems surface and need fixing fast. The migration is not finished at launch.

The validation checklist we run on launch day:

• Crawl the live site within two hours of DNS propagation and compare against the pre-launch crawl
• Verify redirect chains are resolving correctly and not creating loops
• Check GSC for crawl errors and submit the new sitemap
• Confirm structured data is rendering in the Rich Results Test
• Validate hreflang across all locales if the site is multilingual
• Check Core Web Vitals on the live environment, not just staging

The 90-day window is where you catch the long tail of issues: pages that were missed in the redirect map, internal links that still point to old URLs, structured data that renders differently in production than in staging.

For the Vets at Home replatform to Next.js and Supabase, we built 248 automated tests covering the booking platform's typed functions. That test suite is the ongoing safety net that means a content update six months later cannot silently break a booking flow. It does more than gate the initial launch.

Automated testing on a marketing site is still unusual. It should not be.

The honest summary

A website migration checklist is a discipline applied across four stages, not a document you download and tick off: extract before you build, bake visibility into the build, start the content engine before launch, and monitor hard for 90 days after.

The businesses that lose rankings in a migration are almost always the ones that treated the technical work and the visibility work as separate projects with separate owners. They are the same project.

As I have said to more than one client who came to us after a migration went wrong: the ranking you lost in a week took two years to earn. The playbook exists so you do not have to learn that the hard way.

If you are planning a migration and want to run it through this process, book a consultation and we will tell you honestly what the risk profile looks like before you commit to anything.