Surviving a CMS migration without losing your SEO

A CMS migration is the single most dangerous thing you can do to your organic search traffic. We’ve been called in to help recover post-migration drops on some sizeable publisher sites — including BBC Discover Wildlife and other titles managed by Our Media — and almost every dip we’ve diagnosed traces back to a small handful of avoidable causes. If you’re planning a migration, here’s the checklist worth pinning above your desk.

1. Crawl the old site before you touch the new one

Before any code is written, run a complete crawl of the live site and store it. URLs, status codes, metadata, internal links, structured data, the lot. This becomes your reference: if something is missing or different on the new site three months later, you have evidence of what it used to be. It’s also the single source of truth for the redirect map.

2. URL structure is a one-way bet

If the new CMS forces a different URL pattern — and most of them try to — every old URL needs a 301 to the new equivalent. Not a chain, not a 302, not a soft 404 to the homepage. A direct, single-hop, 301 to the most relevant new URL. Get this wrong on a site with thousands of pages and the recovery is months of work.

Where possible, fight to keep the old URL structure. Modern CMSes are flexible enough that you can almost always replicate it.

3. Metadata, headings, and schema are content

Title tags, meta descriptions, canonical tags, hreflang tags, h1s, breadcrumbs, JSON-LD structured data — these are SEO assets. They need to be migrated as carefully as the article body. The most common cause of a migration drop we see isn’t missing pages — it’s pages that exist but lost their structured signals.

4. Internal links matter more than backlinks

Migrations often quietly demote internal linking — a sidebar that used to surface related posts disappears, an editorial “you might also like” module isn’t rebuilt, footer navigation gets thinned out. Each one of those was passing PageRank to deeper pages. Audit internal link counts before and after — pages that used to receive twenty internal links and now receive two will drop in rankings.

5. Performance is a search signal

The new build needs to be at least as fast as the old one — ideally faster. Core Web Vitals are part of the ranking signal mix and are also strong proxies for actual user behaviour. Ship with realistic performance budgets and run synthetic checks in CI.

6. Stage, crawl, fix, repeat

Don’t go live and then audit. Stand the new site up on a staging URL, crawl it as Googlebot would, and compare it against your pre-migration crawl. Diff every URL, every redirect, every title tag. The week before launch is when the bugs are cheap to fix.

7. Monitor for ninety days post-launch

Set up dashboards for indexed pages, organic landing-page performance, and crawl errors before you launch. Watch them daily for the first month, weekly for two months after that. The window in which you can intervene cleanly closes fast.

None of this is glamorous

It’s a discipline, not a trick. Sites that migrate well almost always migrate boringly — months of preparation, conservative URL handling, careful redirect maps, and someone whose only job is to watch the numbers afterwards. If you’re scoping a migration and want a sober pre-flight audit, get in touch.