The State of CMS Migration Readiness 2026

We scanned 1,205 live websites to measure what would break if they migrated CMS tomorrow. This is what we found — including one result we did not expect.

Every migration post-mortem tells the same story: the redirect map was incomplete, nobody audited the content, the structured data quietly failed to carry over. All of it was knowable beforehand, sitting in the old site. So we went and measured it — not on one site, but across two large samples of the live web.

What we measured

Two independent samples, both drawn from public, citable sources and scanned with a single polite request each:

• The broad web — 685 domains sampled systematically from the Tranco ranking (positions 500–25,000), filtered to remove CDNs, DNS infrastructure and ad-tech endpoints. 362 were measurable.
• Government and higher education — 520 domains drawn from the official CISA .gov registry and a public list of US university domains. 323 were measurable.

For each site we recorded eleven signals that determine whether a replatform preserves its search and AI visibility: HTTPS, title quality, meta description, mobile viewport, canonical tag, structured data, Open Graph tags, a single H1, and three security headers (HSTS, CSP, X-Content-Type-Options).

Finding 1: WordPress and Drupal score identically — and fail in opposite directions

This is the result we did not expect. Across government and university sites, WordPress and Drupal are statistically tied on overall readiness. But the averages conceal two almost perfectly inverted profiles.

WordPress sites carry 3.3× more structured data than Drupal sites. Drupal sites are 2.7× more likely to send security headers. Neither gap is small, and neither is accidental: WordPress's dominant SEO plugins emit schema markup by default, while Drupal ships hardened HTTP headers out of the box. Each platform's defaults become its users' strengths — and its users' blind spots.

Drupal sites are also less than half the weight of WordPress sites, with 43% fewer scripts. That is the plugin ecosystem showing up as payload.

Why this matters for a migration. The direction you move determines what you are about to lose:

• Drupal → WordPress: you will likely gain structured data and lose security headers. Budget for re-establishing HSTS, CSP and nosniff on the new stack — they will not come with you.
• WordPress → Drupal: you will likely gain security posture and lose schema markup. Your rich results and AI-answer visibility depend on structured data that your plugins were generating invisibly. Nothing in Drupal will recreate it automatically.

The general lesson is broader than these two platforms: what your current CMS does for you by default is exactly what you are most likely to forget to rebuild.

Finding 2: half the web is invisible to AI answer engines

Structured data is how search engines and AI answer engines understand what a page actually is. It is also the single most commonly missing signal we measured.

Roughly half of the web's most-visited sites publish no structured data at all. In government and higher education it is two-thirds. These are institutions whose entire purpose is public information — and they are the least machine-readable sites we measured.

This matters more every year. When an AI assistant answers a question about a public service or a degree programme, it favours sources it can parse unambiguously. A site without structured data is not penalised so much as overlooked.

Finding 3: security headers are the most neglected signal

HTTPS is effectively universal — that battle is won. But two-thirds of sites ship no Content-Security-Policy, the header that limits what a compromised or injected script can do. A replatform is the cheapest moment in a decade to add these, because you are already rebuilding the delivery layer.

Finding 4: about a quarter of sites would fail a readiness check

The two samples were drawn from completely different populations, scanned days apart — and produced a failure rate within half a percentage point of each other. Roughly one site in four is carrying enough unaddressed risk that a migration would very likely cost it traffic.

The basics are no longer the problem

One genuinely encouraging result: the fundamentals are close to universal. HTTPS is at 99.7%, mobile viewport at 94.8%, and titles and descriptions are present on the large majority of sites. The industry solved those.

What replaced them are subtler failures — machine readability, security posture, canonical consistency — that do not look broken to a human visitor and only surface when the platform underneath changes.

Methodology

We scanned each site's homepage exactly once, with an identifying user agent, respecting robots.txt, with a delay between requests and no deeper crawl. Samples were drawn with a fixed random seed so the selection is reproducible.

Of 1,205 domains sampled, 685 were measurable. The rest were excluded, and we think publishing why matters as much as publishing the findings:

A notable share of the "broad web" attrition turned out to be dead domains rather than slow ones: 91 no longer resolve at all, and 62 more resolve but refuse every connection. Ranked domain lists accumulate a long tail of sites that have simply ceased to exist.

Where a scan was blocked, we diagnosed why rather than recording a bare failure — distinguishing sites that are genuinely down from sites running commercial bot protection that turns away automated clients while serving human visitors normally. Blocked sites were excluded, never scored as failures. Measuring a bot wall and calling it a bad website would be a straightforward way to produce impressive, meaningless numbers.

Limitations

We measured one page per site. A homepage is a strong proxy for a site's conventions — templates and headers are usually global — but it is a proxy, not a full audit. Some sites carry structured data on article pages and not the homepage, so the true structured-data figure is likely somewhat higher than reported here.

Platform attribution is based on fingerprints observable in a single response. Sites that identify no platform are reported as "Unknown" rather than guessed at; that group is large (141 of 323 in the sector sample) and includes both bespoke builds and platforms that leave no visible trace.

Finally, these are correlations, not causal claims. Drupal sites having better security headers does not prove Drupal causes good security — it strongly suggests that defaults shape outcomes, which is the finding we would defend.

What to do with this

If you are planning a migration, the practical takeaway is narrow and useful: inventory what your current platform does automatically before you leave it. The signals most likely to disappear are the ones no human notices — schema markup emitted by a plugin, security headers set by a framework default, canonical tags generated by a module.

Those are invisible right up until the moment they are gone, and by then the traffic has already moved.