Ten years of WordPress: Why we still haven't found anything better

A question that comes up in every meeting

Over the past few months, one question has kept coming up in conversations with our clients, whether they’re SMEs, public institutions, or large organisations: “With everything AI can do today, do we still need a CMS?”

It’s a fair question. Everywhere you look, the message seems to be the same: an agency has migrated its websites away from WordPress in just ten days using Claude Code, a prominent plugin creator has left the ecosystem for a static site generator, and a new generation of AI-native tools is supposedly making traditional CMSs obsolete. The narrative is compelling. And part of it is true.

But it tends to blur two very different questions: “Do all websites need a CMS?” (no, and that hasn’t been true for quite some time), and “Should every existing CMS-powered website be migrated to an AI-assisted JavaScript stack?”. That’s a very different debate. And in our view, the default answer is no.

This article reflects our position after ten years of building, launching, and maintaining WordPress websites for organisations with vastly different needs and constraints. It is also inspired by a recent article by Chris Van Patten on the same topic, which we highly recommend reading alongside this one.

What’s actually true about the “CMS is dead” argument

Let’s start by acknowledging what the current narrative gets right.

Not every website needs a CMS. That’s not a controversial statement, and it hasn’t been for the last twenty years. A product landing page, a portfolio, or a largely static corporate website can often be served more efficiently by a static site generator. In the right context, performance improves, maintenance decreases, and the attack surface becomes significantly smaller without WordPress (ex: Calculateur Elantis).

AI is also genuinely accelerating the initial scaffolding phase of a project. (By scaffolding, we mean the foundation of a website: pages, components, routes, configurations, and overall structure). This isn’t marketing hype. Generating the first version of a showcase website in a matter of hours with an AI coding assistant is now entirely realistic, and it represents a genuine productivity gain.

Traditional CMS editing experiences have also started to show their age. There is a legitimate tension between the flexibility offered by tools such as Gutenberg and the simplicity expected by non-technical content editors. This isn’t a new criticism. The WordPress community has been discussing it for years.

All three observations are valid. What we don’t believe is that they automatically lead to the conclusion that every production website should be migrated to an AI-generated JavaScript stack. Here’s why.

Ten years of experimentation: what we tried, and what broke

We didn’t stick with WordPress out of habit. Over the years, we’ve thoroughly evaluated, and often deployed in real-world projects, a number of alternatives. None of them checked every box our clients require.

Contentful and proprietary SaaS CMSs. These platforms offer an excellent developer experience, polished APIs, and a fast path to publishing content. But things change once you start scaling (multiple languages, multiple environments, multiple editors, multiple content types, whether that’s event pages, product sheets, or forms). At that point, pricing quickly becomes difficult to justify. For a public-sector organisation or an SME looking to control costs over a ten-year horizon, it’s often a structural dealbreaker. And when it comes to data portability, the reality is usually less reassuring than the marketing theory suggests.

Ghost is a great tool for what it was designed to do: publishing content and running newsletters. The moment you step outside that scope, towards institutional websites, complex content structures, custom workflows, or third-party integrations, its limitations become apparent. That’s not a flaw. It’s simply not trying to be a general-purpose CMS.

Strapi has long positioned itself as the open-source alternative many teams were waiting for. In practice, we’ve repeatedly encountered three challenges: A plugin ecosystem that remains relatively limited compared to WordPress. Localization support that spent years feeling like a secondary concern. And major version upgrades that can be surprisingly painful. There’s also a broader trend that deserves attention: what we would call “open source with a catch” (we’ll come back to that in a moment).

Next.js on its own isn’t a CMS. It’s a presentation framework. To recreate the editing experience WordPress provides out of the box, you need to rebuild much of what twenty years of community-driven development have already produced: media management, publishing workflows, roles and permissions, revision history, preview environments, internationalisation. None of that complexity appears in the demo. It becomes very visible once the project enters maintenance mode and real users start working with it.

The rise of “open source with a catch”. This may be the least discussed, and most important, part of the conversation. Many modern platforms present themselves as open source. Yet the features our clients consider essential are often hidden behind premium plans: advanced permissions, serious multilingual support, multiple environments, single Sign-On, audit trails, enterprise support.

For a public organisation subject to procurement requirements, or for a large company dealing with compliance obligations, these are not premium features. They’re the foundation. Paying a per-user SaaS subscription to unlock permission management after being sold on the promise of “open source” feels, at best, misleading.

WordPress, despite all its imperfections, remains remarkably faithful to the original spirit of open source. The code is there. The community is there. The documentation is there. And the core functionality isn’t hidden behind a paywall. That’s becoming increasingly rare.

Our evaluation framework

Rather than debating technologies in the abstract, let’s look at the criteria that matter most to the organisations we work with.

These are the key criteria most of our clients care about in practice, along with how the solutions we’ve tested perform based on our experience.

This framework isn’t a defence of WordPress. It scores several ⚠️, particularly around the learning curve for non-technical editors. That’s a fair criticism, and one we address on a project-by-project basis, often by relying on ACF to simplify the editing experience rather than exposing Gutenberg in its raw form.

But across the full set of criteria weighted against what clients actually need, no alternative has performed better.

AI doesn’t replace the CMS, it makes it more powerful

This is probably the most counterintuitive part of our stance: we believe the rise of AI strengthens WordPress more than it threatens it.

First point, and one that is rarely mentioned: training data. Large Language Models (LLMs, generative AI systems such as ChatGPT, Claude or Gemini) perform significantly better with WordPress than with any emerging framework. Two decades of documentation, open-source code, Stack Overflow threads, tutorials and public repositories make it one of the richest ecosystems they can draw from.

When an AI agent needs to resolve a plugin conflict, write a template, debug a hook, or explain unexpected behaviour to an editor, it has depth to rely on. With newer CMSs or frameworks released just a year or two ago, the same request tends to produce shallow or unreliable answers.

For clients thinking in terms of ten-year durability, this becomes a maintenance argument that rarely makes it into migration pitches.

Second point: MCP is entering the core of WordPress. The Model Context Protocol, combined with the Abilities API and the already mature REST API, makes WordPress a particularly strong foundation for AI-assisted editing. Users can already, and increasingly will, ask an assistant to update opening hours, publish an article, or rewrite a page, while the traditional admin interface remains available for those who prefer a manual workflow. WordPress is not a replacement target for AI; it is a natural substrate for it.

Third point, which directly concerns our work: AI-assisted translation in production. We’ve built an internal plugin using the DeepL API to translate multilingual client content.

Why building a custom plugin instead of using the official DeepL WordPress plugin? Because most of our projects rely on ACF structures, with pages sometimes containing hundreds of fields, and the official plugin handles these structures poorly. Our solution properly traverses ACF structures, respects field relationships, and integrates seamlessly with Polylang workflows.

It is still a beta version, but already running on real projects.

This is exactly the kind of adaptation the WordPress ecosystem makes possible: when an existing tool doesn’t cover a specific need, the extensibility is strong enough to let us build the missing piece. In closed CMS platforms or proprietary SaaS tools, that layer simply doesn’t exist, and cannot exist.

AI doesn’t make WordPress obsolete. On the contrary, it makes it one of the best-equipped platforms to absorb this shift.

The right tool for the right job: what we actually do

Our position is not “WordPress for everything”. It never has been. And that’s precisely why the “move everything to a single modern stack” narrative feels questionable to us: in practice, we already mix technologies every day, because that’s what best serves our clients.

Concretely:

• WordPress headless for projects where the front-end UX justifies a dedicated framework, while keeping a rich and familiar editing experience on the client side.
• Shopify for e-commerce, not WooCommerce. We’re comfortable with the fact that Shopify simply does commerce better, and we know how to combine a WordPress headless content site with a Shopify checkout experience in a seamless way for end users.
• Static site generators for very simple websites with no ongoing editorial needs.
• Classic WordPress for projects where the native WordPress admin is, quite simply, the most effective tool for the client.

The decision is never driven by stack ideology. It is based on a clear assessment of needs, client capabilities, expected project lifespan, and maintenance budget. That is exactly the kind of reasoning the “CMS is dead” narrative tries to bypass, and precisely why it deserves to be challenged.

Who benefits from the migration?

In any major technological shift, one question is worth asking: who actually benefits from changing tools?

When a client moves from a mature WordPress stack to a bespoke AI-generated site built on a JavaScript framework, they don’t remove dependency, they simply relocate it.

Yesterday, they could rely on thousands of WordPress developers across Europe to evolve their website. Tomorrow, they depend on the single agency that built it, because it’s the only one that understands the custom architecture that was generated. The Builder.ai case, a company that promised AI-built custom applications and collapsed in 2025, leaving clients locked out of their own tools, is an extreme example of a risk that, at smaller scale, exists in many over-customised systems that are poorly documented.

Maintenance costs don’t disappear either. They just change shape. Yesterday: plugin updates and PHP upgrades. Tomorrow: npm dependencies breaking builds, front-end frameworks shifting paradigms every 18 months, Node runtimes to maintain, and AI agents whose behaviour drifts with each model update. Complexity doesn’t go away, it moves into layers of the stack that are often less visible and less understood by the end client.

And then there’s the European dimension, which matters for a significant share of our clients. Data sovereignty, EU-based hosting, GDPR compliance, independence from major US platforms, all of these are easier to guarantee with a self-hosted WordPress stack than with a proprietary SaaS or an architecture heavily dependent on external AI APIs. This isn’t a detail. It’s a structural requirement for public sector organisations and many large enterprises.

The honest question, to conclude

The question is not “is the CMS dead?”. It never really was.

The real question, the one we ask at the start of every project, is the following: what is the right tool for the next ten years of this specific website, given its users, its budget, its regulatory constraints, and the team that will actually run it day to day?

For the types of projects we work on (SMEs, public sector organisations, large multilingual enterprises), no alternative has yet performed better against our evaluation framework. If that ever changes, we’ll migrate without hesitation. Until then, we continue to build on WordPress, integrating AI where it genuinely adds value (assisted translation today, MCP-driven editing tomorrow), rather than replacing everything with stacks whose trade-offs are not better, just different, and often less well understood.

If you’re currently in an evaluation phase and find this framework useful, let’s talk.