Does WordPress still make sense in the age of AI agents?

There is an interesting paradox in the modern Web. For decades we built abstractions on top of other abstractions with a perfectly reasonable goal, letting as many people as possible create and run a site without needing to know HTML, CSS, JavaScript, PHP, databases, servers, APIs and infrastructure. WordPress is probably the most successful result of this philosophy.

Then generative artificial intelligence arrived, and suddenly a question opens up that only a few years ago would have seemed almost absurd: if I can describe to an AI agent the site I want, have it build the site directly, change it by talking in natural language and ask it to integrate any external service, do I still need a CMS like WordPress?

The short answer is that today, in some cases, yes, but much less than yesterday, and tomorrow probably even less. The interesting point, however, is not whether WordPress will die. The point is realizing that AI could make obsolete the very reason WordPress and many other CMSs became necessary.

First of all: what is WordPress, in simple terms

WordPress is a Content Management System, a system that lets you manage a site through a graphical interface. Instead of writing the code of a page directly, you log into an admin panel, create a page, insert text and images, choose a graphical theme and add features by installing plugins.

Do you need a contact form, an SEO system, an online store, translations, statistics, caching, a cookie banner, a newsletter, a booking system, backups, security, a slider or image optimization? Almost always there is a plugin.

Technically, in its traditional configuration, WordPress uses PHP on the server and a database, normally MySQL or MariaDB, from which it retrieves content and settings to dynamically generate the pages requested by users. It is WordPress's own official documentation that describes this architecture. And it is a model that has worked extraordinarily well.

Why WordPress still dominates the Web

Because it solved an enormous problem, it drastically lowered the barrier to entry for creating websites. Building a traditional site required technical skills, whereas with WordPress it became possible to buy a domain, install the platform with one click, purchase a theme, import a demo, replace text and photos, install a few plugins and publish. And the site was online.

You did not need to be a software engineer, and often you did not even need to really know HTML, CSS or JavaScript. This is not a criticism, it is precisely the success of WordPress: it democratized the Web, it let freelancers, designers, small agencies, companies and non technical professionals create something that, twenty years earlier, would have required a programmer.

The flip side is that a huge market segment developed in which "building a site" actually means assembling components built by someone else, that is a theme, a page builder, a plugin, the plugin of the plugin and a few snippets copied online. There are of course extremely competent WordPress developers and excellently engineered WordPress projects, so the problem is not WordPress itself. The problem is that its economic and operational model makes it possible to produce sites even without really understanding what happens under the hood. And for the mass market this was exactly what was needed.

The result is a gigantic technological monoculture

People often cite the figure that WordPress powers 43% of the Web. That was substantially correct in previous years, but today the more interesting figure is another one. As of 25 August 2026, W3Techs reports WordPress on 40.7% of all websites it analyzes and on 58.9% of the sites for which a CMS can be identified. It is still a simply enormous share, but something is changing.

After reaching and holding values around 43% for years, in 2026 the share began to fall more noticeably: in January 2026 it was about 43%, by May it had already dropped to around 41.9%, down to the current 40.7%. This does not mean WordPress is about to disappear, but it does mean that its dominance is no longer a natural law of the Web. And it is precisely now that a technology arrives capable of attacking the fundamental premise on which that dominance was built, artificial intelligence.

AI changes the problem at its root

Until yesterday we needed WordPress because programming a site directly had a high cost. You had to know what to write, know the syntax, know where to put the code, understand frontend, backend, database, deployment and server configuration. WordPress turned all of this into buttons. But what happens when you no longer have to write the code yourself?

Imagine being able to tell an agent:

Build a responsive site for an architecture studio. I want five sections, light animations, a gallery, a form that sends leads to the CRM and a projects page fed by this data. Optimize it for mobile, accessibility, SEO and performance.

The agent generates the project. Then you say:

Move this section up. Reduce the spacing. When a contact comes in, also send it to this webhook. Change the gallery like this. Add an English page. Make the menu turn transparent over the hero.

You are not using a CMS. Natural language has become the CMS. This is the fundamental shift: WordPress replaced code with a graphical interface, while AI is starting to replace both the code and the graphical interface with the user's intent.

The CMS was an abstraction, and now that abstraction could become unnecessary

Take an ordinary company site. It has a homepage, an about page, services, a portfolio, contacts, a few articles, a contact form, analytics and a CRM integration. To offer these features with WordPress we can end up with a chain made of web server, PHP, WordPress Core, theme, child theme, page builder, plugins, database, caching, caching plugin and CDN.

Every layer exists to solve a real problem, but every layer also introduces code, dependencies, updates, configurations, possible incompatibilities, CPU usage, queries, memory, disk space and attack surface. With an AI agent an equivalent solution could instead shrink to HTML, CSS and JavaScript with the few APIs needed served by a CDN, or to a static frontend with a small serverless function for the form. It will not always be possible, but for a huge percentage of today's websites it will. And this is where the discussion becomes much more interesting than the simple question "is WordPress slow?".

The real waste is doing dynamic work for content that is not dynamic

A visitor opens the "About us" page, and the text may not have changed in six months. Yet in a traditional WordPress installation there can be a PHP application ready to start, retrieve settings, run hooks, query the database, load theme and plugins and finally produce some HTML.

Of course WordPress can be optimized enormously through caching, CDN and object cache. But it is interesting to read what the official documentation itself says: storing pages as static files reduces the server's processing load and, for reasonably static content, caching can produce performance improvements of several orders of magnitude. In other words, after building a gigantic dynamic infrastructure, one of the best optimizations often consists of making sure that infrastructure does not run for every visit. It is an important clue, because for a great many sites the most efficient solution might simply be not having that infrastructure from the start.

CPU: producing every time something we could already have

A static site served through a CDN needs very little server side computation to serve a page: the file already exists, the request arrives, the file is delivered, done. A dynamic CMS must instead be designed to handle a much larger universe of possibilities, that is users, permissions, plugins, queries, filters, themes, shortcodes, REST APIs, comments, revisions, hooks and much more. That generality has a cost. For a large editorial portal it can be perfectly justified, for the site of a restaurant with seven pages much less so.

Storage and database: when the abstraction accumulates history

A freshly installed WordPress does not take up gigabytes of database, and it is important to be precise about this. But real sites maintained for years can accumulate a considerable amount of data through revisions, autosaves, transients, logs, statistics, form submissions, WooCommerce data, sessions, cache, metadata, SEO plugins, security plugins, analytics systems and custom tables.

WordPress explicitly allows plugins to create new structures in the database and store data that grows as the site is used, and even the revision system can be limited through configuration precisely because revisions are kept. It is therefore not absurd to find apparently simple installations with databases of hundreds of megabytes or, in particular cases, several gigabytes. The point is not to claim that WordPress necessarily takes up gigabytes, the point is another one: a site made of 30 HTML pages does not need a database to query in order to remember what those 30 pages contain.

Then the plugins arrive, and with them the operational debt

Plugins are at the same time the greatest advantage and one of the biggest problems of WordPress. They let you add a feature without developing it, but every plugin is also a new dependency. With a professional site it is normal to end up with plugins for SEO, forms, SMTP, backup, cache, security, cookies, translations, images, page builder, custom fields, redirects, analytics and online store.

At that point you no longer simply own "a site", you own a small software ecosystem made of components maintained by different organizations, with different release cycles, different business models and different quality levels. And you have to maintain it, that is update Core, theme, builder, plugins and PHP, renew licenses, test and back up. Something breaks and you roll back. One plugin is abandoned, another changes its price, one becomes incompatible, another introduces a vulnerability. The cost is not only the price of the licenses, it is the permanent complexity of the system.

And security shows the problem well

We should avoid a frequent oversimplification: WordPress Core is not necessarily "insecure" software. In fact, a very significant part of the problems comes from the external ecosystem. According to the Patchstack report for 2025, 11,334 vulnerabilities were identified in the WordPress ecosystem, 42% more than in 2024, about 91% of which concerned plugins, while 2,008 were classified as high priority.

And this is an important figure, because we are not talking only about the security of WordPress, we are talking about the security of the composition, that is WordPress plus the theme plus plugin A plus plugin B plus plugin C. Every component increases the possible surface.

Some real examples, updated to August 2026

There is no need to go back years. In the weeks just before this article was published, significant cases emerged.

WordPress Core: wp2shell

On 17 July 2026 WordPress 7.0.2 was released to fix two security issues, one Critical and one High. The severity was such that WordPress activated forced updates for the affected installations. The vulnerabilities CVE-2026-63030 and CVE-2026-60137, chained together, could allow unauthenticated Remote Code Execution in certain versions of WordPress. F5 Labs later observed real automated exploitation attempts, and both vulnerabilities ended up in the CISA catalog of vulnerabilities known to be actively exploited. And this is exactly the concept of monoculture in action, because once an exploit is built it is possible to automatically search thousands or millions of systems with similar characteristics.

CVE-2026-64638: XSS2Shell

A few weeks later CVE-2026-64638 emerged, nicknamed XSS2Shell. CERT-AGID classified it High with CVSS 8.9. The vulnerability involved the Core and affected numerous branches of WordPress, down to the 4.7 series releases, and under certain conditions it could become part of a chain capable of reaching PHP execution on the server. This does not mean that every vulnerable site could be compromised automatically, because the full chain required additional conditions and interaction, but it shows the potential reach of a vulnerability when a single software base is present on a huge portion of the Web.

Forminator: 600,000 installations

CVE-2026-15748, related to Forminator Forms, was classified Critical with CVSS 9.8. Versions up to 1.56.1 allowed, in certain form configurations, arbitrary file upload by unauthenticated users, with the possibility of reaching code execution. The plugin has over 600,000 active installations and the fix arrived with version 1.56.2.

Pods: possible administrative takeover

In August 2026 Pods too, used by over 100,000 sites, was affected by CVE-2026-19598, CVSS 9.8. The vulnerability allowed a privilege escalation up to administrative privileges and was fixed in the 3.3 series with version 3.3.9.1. Patchstack also flags it as a vulnerability known to be exploited.

TranslatePress: 400,000 sites potentially involved

More recent still is CVE-2026-19632, published on 26 August 2026 and related to TranslatePress. CVSS 9.8, versions affected up to 3.3.1, over 400,000 active installations. Under certain configurations an unauthenticated attacker could retrieve an administrator's password reset link and reach account takeover. The patch is in version 3.3.2.

WP Compress: CVSS 10

CVE-2026-73343, related to WP Compress, was classified by Patchstack with the maximum score, CVSS 10.0. Versions before 7.20.01 were vulnerable to an unauthenticated Remote Code Execution, and the plugin has over 10,000 active installations.

But be careful: "custom" does not automatically mean "secure"

Here we need to avoid the opposite mistake. A site generated by an AI can contain vulnerabilities, because an agent can write broken authentication, SQL injection, XSS, insufficient checks, secrets left in the repository, badly protected APIs and vulnerable dependencies. A badly designed custom application can be much less secure than a well maintained WordPress.

The difference is mostly about risk correlation. If a zero day is discovered in a plugin present on 5 million installations, an attacker has an enormous economic incentive to build an automated exploit: they write the attack once, scan the Internet and reuse the same exploit millions of times. This phenomenon is well known in research on software monoculture, where using the same implementation on a huge number of systems creates the risk of correlated failures, because a single vulnerability can be shared by the entire population. Software diversity can reduce this ability to propagate, even though it does not automatically guarantee greater security.

Heterogeneity could become a form of defense

And this is where AI introduces a particularly interesting consequence. If in the future ten million sites are not ten million instances of the same platform, but ten million small systems generated specifically for their own purpose, a zero day becomes potentially much less scalable. Not less dangerous for the single vulnerable system, but much less reusable.

Attacking a path like /wp-content/plugins/plugin-name/vulnerable.php is extremely convenient if you know that URL and that function exist identically on hundreds of thousands of servers, and it becomes much less convenient if every application has a different structure, endpoints and implementation, because the attacker has to spend more resources to understand the single target. In economic terms the ratio changes: an exploit that was worth millions of victims can become an exploit that reaches a much smaller set of victims. It is an enormous difference.

But it will not eliminate monocultures completely. If millions of AI generated sites all use the same JavaScript framework, the same authentication library, the same cloud service or the same vulnerable npm dependency, the problem simply moves up a level. The goal, therefore, should not be to customize everything, but to reduce unnecessary dependencies and share only what is genuinely worth sharing.

Perhaps the most important advantage of AI: building only what is needed

This is the real reversal. In the old model we bought a general purpose platform and then tried to adapt it to our problem, while in the new model we can start from the problem and generate only the software needed to solve it.

Suppose the site needs a form that collects name and email, checks the data, sends it to HubSpot, sends a notification and returns a message. With WordPress we might install a form plugin, a CRM add on, an SMTP plugin, possibly Zapier, and then configurations and updates. With direct development we can have a function of a few dozen or a few hundred lines that sends the data straight to the API needed.

And if the requirement changes tomorrow, you tell the agent:

Before sending the lead, check the email domain, assign the country based on the phone prefix and send it to this pipeline when the company has more than 50 employees.

The software is modified, and you do not have to wait for the right plugin to exist.

Integrations become much simpler

One of the historical reasons for choosing WordPress was "there is already a plugin for X". But in the age of AI agents the question could become "does X have an API?". If the answer is yes, an agent can read the documentation, implement OAuth, create the webhook, build the data mapping, handle the errors and integrate the service directly, whether it is a CRM, ERP, Stripe, a proprietary management system, booking systems, a company database, newsletters, automations, AI, search, storage or cloud services. The integration does not necessarily have to go through a commercial adapter built by a third party, and this removes one more layer.

The concept of maintenance changes too

Today, maintaining many sites consists mainly of keeping the platform alive, that is updating components, checking compatibility, renewing licenses, cleaning the database, monitoring plugins and backing up before yet another update. In an AI native architecture the work could shift toward something different, that is a Git repository, reduced dependencies, automated tests, vulnerability scanning, automated deployments, rollback, declarative infrastructure and observability.

And above all the agent could understand the project as a whole. No longer "install plugin X", but something like:

This project has a vulnerable dependency. Update it, fix the breaking changes, run the tests and show me what changed.

It is a completely different form of software management.

And on the energy front?

Here too we need balance. Generating code with AI models has a significant computational cost, so it would be wrong to present AI as an intrinsically green technology. But we have to separate the cost of building from the cost of permanent execution.

Spending computational capacity once to generate and update a very simple application can make sense if that application, across millions of later visits, requires very little processing. It is the same principle as compilation, we spend computation up front in order to do less work later. For mostly informational sites, moving the system toward static files, CDN and on demand processing can potentially reduce dramatically the CPU, RAM and infrastructure needed across the whole life of the project. Multiplied by millions of sites, it is not a marginal matter.

So is WordPress dead?

No, and it would probably be naive to claim so. WordPress has enormous advantages that do not vanish with a prompt, that is twenty years of ecosystem, millions of users, hosting everywhere, a global community, mature editorial workflows, user management, revisions, permissions, media library, APIs, plugins, WooCommerce, multilingual support and consolidated experience. Moreover WordPress itself is evolving and can incorporate more and more AI. And above all there are problems for which a CMS is genuinely the correct solution.

When WordPress will keep making perfect sense

A large magazine with fifty editors needs an editorial system. An organization with roles, approvals, drafts, revisions and thousands of pieces of content needs a structured backend. A complex online store might find an enormous advantage in the WooCommerce ecosystem. And a company that already has hundreds of thousands of pieces of content on WordPress has no rational reason to rewrite everything just because AI agents now exist.

In these cases WordPress can keep making a great deal of sense, perhaps not necessarily as a traditional monolithic platform. It could become a content repository paired with a frontend generated and optimized by AI, that is a headless or hybrid architecture, in which the CMS keeps doing what it does well, managing content and people, while the frontend is built in the most efficient way possible.

Where the change could instead be brutal

Landing pages, company sites, portfolios, restaurant sites, hotel sites, microsites, event sites, product presentations, relatively simple catalogs, personal sites and small vertical applications. It is hard to technically justify a general purpose platform made of core, database, theme and ten plugins when an agent can build exactly what is needed. Here WordPress no longer competes only with Wix, Webflow, Squarespace or Shopify, it competes with something completely new, software generated on demand.

And this time custom software could cost less than the template

Historically custom development was the premium solution, and WordPress was cheap because it reused the work done by others. A 70 euro theme was cheaper than a week of a frontend developer, and a 100 euro plugin was cheaper than developing a dedicated function. Economically it was unbeatable.

AI can invert this equation. If building a specific function takes a few minutes of agentic work, why install a plugin of 200,000 lines that solves another fifty problems we do not have? If generating the frontend takes a few iterations, why buy a general purpose theme and then fight against its options? And if changing the software means describing what we want, why keep a page builder just to avoid touching code? This is where the whole paradigm starts to crack.

From hiding the code to removing the abstraction

Over the last ten years the industry celebrated no code. But no code did not really eliminate code, it hid it, because behind every button there were still frameworks, databases, workflows, runtimes and platforms.

AI suggests something different, not just hiding complexity but generating directly the simplest solution compatible with the problem. We might call it development without abstractions, not because abstractions no longer exist, but because we are no longer forced to adopt a gigantic general purpose abstraction just to avoid programming. The agent can program for us.

The real revolution might be subtraction

For years the evolution of the Web was mostly additive, that is more frameworks, more libraries, more plugins, more APIs, more microservices, more layers, more dashboards and more middleware. AI could produce an apparently opposite effect, not necessarily more software but less software, more specific software, fewer dependencies, less useless data, less runtime, fewer databases, fewer updates, fewer components to maintain and less shared attack surface.

And perhaps this will be one of the most profound consequences of artificial intelligence in software development: not letting us build ever more complex systems, but finally letting us build simple systems without simplicity costing a fortune.

So does WordPress still make sense?

Yes, but no longer automatically. For twenty years the typical question for a new project was "which CMS do we use?". In a few years it could sound like a strange question, and the question could become "do we really need a CMS?". In a great many cases the answer could be no.

Not because WordPress has suddenly become bad software, but because the trade off that made it dominant could fall away. We accepted computational complexity, databases, plugins, updates, compatibility and dependencies because the alternative, building everything directly, was too expensive. When an AI agent can build, modify, test and integrate software through natural language, that cost collapses. And when the cost of custom development collapses, so does the economic value of a part of the abstractions created to avoid it.

WordPress might therefore not die. Something more interesting could happen to it, it could stop being the default answer and go back to being a tool you choose when the problem genuinely requires a CMS, instead of the platform installed automatically every time someone says the word "website".

And that is probably a good thing, for WordPress, for developers, for security, for infrastructure and, above all, for a Web that after twenty years of layering could finally start asking not only "what can we add?" but also "what can we remove?".