The slow turn away from WordPress

WordPress is one of the great successes of open source. It began as a tool for blogs and grew into the software behind a large part of the web, free to use, free to change, with an ecosystem of themes, plugins and hosts that lets almost anyone publish.

As an agency we built and looked after WordPress sites for years, and many good sites still run on it. This is not an obituary. But three things have changed at once, and a company that runs its website on WordPress should know all three: the share has turned, the risk sits in the plugins, and the project’s leadership has spent two years in a dispute that is now headed for a jury.

The share has turned

W3Techs, which tracks the technology behind websites, shows WordPress climbing for most of a decade: from 23.3 percent of all websites at the start of 2015 to 43.2 percent at the start of 2022. Then it flattened. It stood at 43.6 percent in January 2025 and 43.0 percent in January 2026. On 12 October 2026 the figure was 40.1 percent.

That is still more than all other content management systems together, and 58.6 percent of the sites whose system W3Techs can identify. But the direction is new. Over the same period Shopify grew from 4.7 to 5.4 percent of all websites and Wix from 3.3 to 4.2 percent, while Joomla and Drupal kept shrinking. Counts like these depend on method, so the direction matters more than the decimal.

The risk sits in the plugins

The core of WordPress is in good shape. Patchstack, a security company that tracks the ecosystem, counted just six vulnerabilities in WordPress core in 2025, all of low priority.

The ecosystem around it is another matter. Patchstack counted 11'334 new vulnerabilities across WordPress in 2025, 42 percent more than in 2024. 91 percent were in plugins and 9 percent in themes. For 46 percent of them, the developer had no fix ready when the flaw was made public. And for the flaws attackers went after hardest, the median time from disclosure to mass exploitation was five hours.

Patchstack sells protection against exactly this, so its framing deserves the usual care. The pattern, though, is structural. A company site often runs many plugins from many authors, each with its own update rhythm, its own quality and its own business model. Every one of them is code on the public server. Keeping them current is a weekly job, and the weeks it is skipped are the weeks that matter.

Two years of turmoil

In September 2024, at the WordCamp US conference, Matt Mullenweg, the chief executive of Automattic and the leading figure of the WordPress project, urged the community to stop paying WP Engine, one of the largest WordPress hosts. In a post that followed he called the company a “cancer” to WordPress. Mullenweg had demanded a royalty for the use of the WordPress trademark: 8 percent of WP Engine’s monthly gross revenue.

On 25 September WordPress.org banned WP Engine from its resources, which broke plugin and theme updates for some of the sites it hosted. In October WP Engine sued Automattic and Mullenweg, and WordPress.org took control of Advanced Custom Fields, a popular plugin WP Engine maintained. In December a federal judge granted a preliminary injunction that restored WP Engine’s access and the plugin.

What followed hurt the project more than the host. In January 2025 Automattic cut its pledged contribution to WordPress to about 45 hours a week, from about 2'560, to put resources into the legal fight. In April it laid off 16 percent of its staff, and WordPress said 6.8 would be the last major release of 2025. At the end of May Automattic reversed course and returned to core. In June the Linux Foundation launched FAIR, a federated repository for plugins and themes, designed so that no single source controls updates.

The case is far from over. On 24 September 2026 the judge revived WP Engine’s antitrust claims, which she had dismissed a year earlier, and found that Automattic and Mullenweg are neither owners nor registrants of the WordPress marks they asserted. Most of Automattic’s counterclaims survive too. A ten day jury trial is set for October 2027.

What it means for a company on WordPress

None of this makes a WordPress site unsafe overnight. A well kept installation with few plugins, a good host and a named person responsible for updates can serve a company for years. For a blog, a small brochure site or a team that knows the platform well, staying is often the sensible choice.

What the last two years have shown is the dependency. A site’s updates, its plugins and the trust in its supply chain run through one repository, and for a while the decisions about that repository were made inside a commercial dispute. Add an ecosystem in which almost half of new flaws are public before they are fixed, and the question is no longer whether WordPress works. It is how much of the website a company wants to rest on parts it does not control.

Built sites with a CMS on top

That is why more companies move to built sites: a website compiled from code into fast pages, with a content management system on top for the people who edit it. The public site then has no plugins and no admin login to attack. Every change goes through a build that is tested before it goes live. The content lives in files the company owns, not in a database shaped by a vendor.

The trade off is real. A built site needs developers for new features, where WordPress has a plugin for almost everything. And the editing has to be built well, or the marketing team will miss the old admin panel within a week.

This is the problem Studio was made for. Its core is a CMS on top of sites built in Next.js, Vite or TanStack, with no plugins and no PHP on the public site. Every publish is checked, built once, tested, made live, verified, and rolled back on its own if anything fails, and every publish commits the content to the company’s own repository. Editors click a word to change it and see the live page. Studio is in early access.

Machines can take over the builds, the tests and the rollbacks. What a page says, and whether it is good enough to go out, stays with the people who answer for it.

Where to start

Count your plugins and write down who maintains each one, when it was last updated and what it does. Remove what nobody needs. Make sure every plugin, the paid ones included, receives its updates, and that a named person checks them every week. Export your content once and see whether you could move it if you had to.

Then decide on purpose. Keep WordPress where it serves you, with fewer parts and a clear owner. Where the website is central to the business, a built site with a CMS on top is worth a conversation.