The Rise and Fall of WordPress as a CMS

For most of the last decade, the answer to "what should we build the site on?" was a shrug and the word WordPress. It ran the blog, the marketing site, the docs, sometimes the store. That default is breaking. The platform still powers a huge share of the web, but its share of new builds is shrinking fast, and the teams doing the new work are picking Next.js, headless content platforms, and AI-assisted frontends instead.

This piece walks the full arc: how WordPress climbed to roughly 43% of the web, what soured serious teams on it, what the AI shift actually changed, and what to pick in 2026 if you are starting fresh.

How WordPress Ate the Web

WordPress launched on May 27, 2003, as a fork of the b2/cafelog blogging engine by Matt Mullenweg and Mike Little. It was a blog tool. The rise from there was not inevitable — it was earned by three things: a plugin architecture that let non-developers extend the CMS, a permissive GPL license, and a hosting ecosystem that made one-click installs the norm on shared hosting.

By the mid-2020s, WordPress was not just popular, it was the substrate. W3Techs put its peak at roughly 43.6% of all websites in mid-2025. Among sites that use any known CMS, the share was higher still. Even at the top end of the traffic curve, the platform held on: the HTTP Archive's 2025 Web Almanac reports WordPress at about 58% of CMS usage among the top 10,000 highest-traffic websites, with Drupal punching above its weight at 6–7%.

Those are the numbers everyone quotes. The interesting story is what the numbers stopped doing.

The First Sustained Contraction in Twenty Years

WordPress had shed share in short windows before. What is different now is that the decline has continued month after month. Market share fell from 43.2% in December 2025 to 41.9% by late May 2026 — a 1.3-point drop in six months, roughly double the pace of decline across all of 2025. That is the first sustained contraction in the platform's twenty-plus year history.

Two things drove it. The first is technical fatigue that had been building for years. The second is a governance blow-up that made a lot of teams sit down and reconsider whether they wanted to keep depending on the project at all.

The Governance Fight That Reset the Conversation

In September 2024, at WordCamp US, Matt Mullenweg publicly called WP Engine "a cancer to WordPress," called for a boycott, and demanded WP Engine pay 8% of its gross revenue for trademark licensing. Days later the fight moved from stage to court and infrastructure. WordPress.org blocked WP Engine from accessing its servers on September 25, 2024, and on October 2, 2024, WP Engine sued Automattic and Mullenweg for extortion and abuse of power.

Whichever side you land on, the practical effect on buyers was the same. A platform whose pitch had always been "open, community-governed, boring in a good way" suddenly looked like it had a single point of failure at the top. Procurement teams started asking questions that had not been on any RFP in a decade.

The Operational Pain Teams Actually Hate

Governance drama got the headlines. Day-to-day, the reasons engineers keep pushing away from WordPress are more mundane and more expensive.

• Plugin sprawl and conflicts. A production site typically runs 15–30 plugins from as many vendors, each on its own release cadence. Every WooCommerce, Yoast, or page-builder update is a potential regression, and conflicts often surface only in production.
• Security exposure that lives in the plugins. Patchstack's State of WordPress Security in 2025 report counted 7,966 new vulnerabilities disclosed in the WordPress ecosystem in 2024, a 34% increase over 2023, with 96% of them in plugins. The core is not the problem. The blast radius of the ecosystem is.
• Performance built on caching plugins. WordPress renders each page from PHP and MySQL on request, then hides that with cache layers. Every added plugin adds to the render path. Lighthouse scores on stock installs with a page builder and a dozen plugins routinely land in the 40s on mobile.
• Editor lock-in to a theme. A theme couples content to presentation. Reusing the same content on a mobile app, a partner site, or a chatbot means copy-paste or a headless retrofit.

None of this is fatal in isolation. The compounding cost is what pushes teams off. A finance site or SaaS marketing surface running twenty plugins is not a website; it is a small distributed system with no on-call rotation.

What AI Actually Changed

AI did two things at once, pointing in opposite directions. WordPress itself shipped version 7.0 "Armstrong" on May 20, 2026, with native AI capabilities including an AI Client in Core and a modernized dashboard. That helps existing sites. It does not help the platform win new ones.

The bigger shift is on the build side. Cursor, Claude Code, and similar tools generate React and Next.js far more reliably than they generate a good custom WordPress theme, because the training data is cleaner and the type system carries more information. A team that can ship a Next.js marketing site in a week with an AI pair now weighs the WordPress option very differently than a team that had to hand-write PHP templates. The economics of a static, typed, componentized stack collapsed in favor of Next.js, Astro, and friends. Our own take on that tradeoff sits in AI-assisted vs. traditional development, and it is also why AI-assisted website builds have become a real product category rather than a novelty.

Meanwhile the content layer moved. Headless platforms — Sanity, Contentful, Strapi, Payload — grew into the default backend for sites where editors still need a CMS, but engineering wants to own the frontend. Sanity puts the headless CMS market at roughly $3.94 billion in 2026, growing to $22.28 billion by 2034 at a CAGR above 21%. The shape of the decision changed: the CMS is now a data source, not a website.

Where the Numbers Land in 2026

The picture is not "WordPress is dead." It is "WordPress is a legacy default, not a forward default." Existing installs keep running. New serious builds skew hard toward Next.js and a headless backend, and the AI tooling accelerates that skew every quarter.

Choosing a CMS for a New Build in 2026

The answer depends on who is editing, what the site has to do, and how the site connects to the rest of the product. A rough decision matrix that maps to what most teams actually pick:

A few notes on the choices.

• Next.js plus a headless CMS is the default for anything that has to perform, rank, and grow. Pair it with Sanity, Contentful, or Payload depending on editor sophistication and hosting preference. Payload deserves a look for Next.js-native teams; Sanity for structured content and real-time collaboration.
• Astro plus MDX is the right shape for a docs site, an engineering blog, or a marketing site with a small content team that writes in Markdown. It ships almost no JavaScript by default.
• WordPress is still the correct answer for a lean editorial site with a non-technical team, or when you need a specific plugin (LearnDash for LMS, MemberPress for membership) whose Next.js equivalent would cost more to build than the site is worth. Lock it down, keep the plugin count low, and budget for maintenance.
• Shopify or a headless commerce stack beats WooCommerce for most new stores. Fewer moving parts, better checkout, less to patch.
• Custom app with an admin is right when the "content" is really product state, and where a CMS is the wrong abstraction. That is the world where a proper API layer and a real database schema pay for themselves quickly.

The frontend framework question is a related one. If you have not landed on a stack yet, the pattern that keeps holding up is Next.js on TypeScript, and the reasoning is covered in the business case for TypeScript. The point is not fashion. It is that a typed, componentized frontend is what modern AI tools generate best and what senior engineers can maintain longest.

What to Do If You Are on WordPress Today

Do not rip and replace on principle. Migration is disruptive, and a stable, well-hosted WordPress site is not an emergency. A more useful sequence:

1. Audit the plugins. Anything not actively used comes out. Anything with a poor security history gets replaced or wrapped.
2. Move the marketing surface first. The blog and top landing pages are the highest-leverage pieces to migrate to Next.js plus a headless CMS; the admin panel and long-tail archive can stay on WordPress during a strangler-fig transition.
3. Decide whether editors need a visual builder or can work in structured fields. That single question narrows the CMS shortlist more than any feature matrix.
4. Budget honestly. A serious build is closer to a custom application than a template install. Our breakdown of what a website should cost in 2026 is a reasonable starting point.

The Honest Read

WordPress is not collapsing. It is deflating from a share no software project should reasonably hold. What replaces it is not a single winner but a shape: a typed frontend framework, a headless content backend, and AI tooling that makes the combination cheap enough to justify for sites that used to reach for a plugin. The platform that ate the web is becoming one option among several, chosen when it fits and skipped when it does not. For most new builds in 2026, it does not.