WordPress is losing market share. We should be able to say that without starting a civil war in the comments.
According to W3Techs’ current historical report, WordPress was detected on 43.4% of the websites it measured in September 2025. On September 27, 2026, that figure stood at 40.2%. A fall of more than three percentage points in a year is not a rounding error, and pretending otherwise will not help the ecosystem.
It is also not proof that WordPress is dying.
Forty percent of the measured web remains an extraordinary installed base. More importantly, the number tells us where WordPress appears in a website’s detectable output. It does not tell us how WordPress is being used behind a static front end, a mobile application, a commerce feed, an internal workflow or an AI agent.
That distinction is about to matter far more than it did when the main job of a CMS was to render a page and wait for a human to click it.
At WPBay, we spend a great deal of time looking at what WordPress developers are building. The shift is already visible. The most interesting products are no longer merely adding another settings screen or decorating the front end. They are controlling workflows, moving content, managing commercial data, exposing actions and connecting WordPress to systems outside the browser.
So the honest answer to the title is uncomfortable for both sides of the usual debate. WordPress is not dying, but one version of WordPress probably is: the assumption that its future will be secured by winning every new brochure website. Its next important role may be less visible and more valuable.
WordPress is starting to look like an open backend for the agentic web.
The decline is real, but the interpretation is not settled
There are good reasons to take the W3Techs trend seriously. The decline has continued across 2026. Commerce platforms have gained ground, while hosted and AI-assisted builders have made the simple end of the market brutally competitive. Creating a polished small-business site no longer requires choosing a host, installing a CMS, comparing themes and assembling six plugins. A business owner can describe a site to an AI builder and have something acceptable online before a traditional WordPress installation has finished arguing about its cookie banner.
That pressure is strongest at the simple end of the market. Landing pages, portfolios, restaurant sites and small catalogues were once automatic WordPress projects. Many are now easier to launch on a closed platform, particularly when the owner values convenience more than portability.
WordPress has contributed to the problem. The admin experience is inconsistent. A new site can contain the block editor, a page builder, a theme options panel, a hosting dashboard and several competing design systems. Plugin notices compete for attention. Updates remain stressful for owners who have previously watched a site break. Performance can be excellent, but it is not excellent by default after an undisciplined stack of extensions has been installed.
None of that should be excused by saying WordPress still runs a lot of websites.
The market-share number still needs context, though. W3Techs measures what it calls the “relevant web,” currently a sample of more than 20 million sites. It detects technology from website output, excludes duplicate and low-content sites, and does not count subdomains as separate websites. Its methodology is useful and transparent, but it remains a measurement model rather than a census of every application using WordPress.
That matters because a backend can become less detectable without becoming less important. A Next.js front end may consume content from WordPress through the REST API. A mobile app may use WordPress for authentication and publishing. A store may expose product and order operations to an agent without sending that agent through the theme at all.
Market share is still a health signal. It simply may no longer describe the whole patient.
The web is moving from pages to capabilities
The first web was built around documents. The commercial web added applications, accounts and transactions, but people still reached most functionality through pages. They opened a browser, navigated a menu, filled a form and pressed a button.
Agents change that sequence.
If a customer asks an assistant to find a compatible camera lens under a certain price, compare delivery dates and place an order after confirmation, the assistant does not benefit from imitating twenty mouse clicks. It needs structured access to product data and a controlled action for checkout. If an editor asks an agent to find every article that references an outdated API and prepare revisions, the agent needs a way to query content and propose changes. Scraping the admin screen is the worst possible interface for either task.
The emerging agentic web is an attempt to give software agents something better than a screenshot and a guess.
MCP provides a standard way for AI applications to connect with data, tools and workflows. WebMCP, still a proposed browser standard, lets a page declare structured tools so a browser agent can understand actions such as searching, submitting or purchasing without reverse-engineering the interface. Different protocols cover different environments, and none of this is finished. The direction is nevertheless clear: websites are beginning to describe what they can do, not only what they look like.
This is where WordPress becomes interesting again.
WordPress already knows about content, authors, roles, revisions, media, taxonomies, scheduled events and permissions. Plugins add bookings, products, memberships, courses, invoices, forms, support tickets and thousands of narrower business objects. The ecosystem has spent two decades teaching WordPress how businesses operate.
Until recently, much of that knowledge was trapped behind plugin-specific PHP functions, admin forms and custom REST routes. An external client could interact with it, but only after a developer studied that particular plugin and built a dedicated integration.
The agentic web needs those operations to become discoverable, typed and permission-aware. That is precisely the problem WordPress has begun to address.
WordPress has been a backend for years
Calling WordPress a backend is not a reinvention cooked up for AI.
The WordPress REST API has long allowed other applications to query and modify posts, pages, taxonomies, media, users and settings as JSON. It powers the block editor itself and has been used for headless sites, mobile applications and alternative administration tools. WordPress can already serve as a structured content store while another system owns the visible interface.
Its deeper advantage is not the REST API alone. It is the combination of a mature data model, an extension system and an authorization model installed on an enormous number of independently operated sites.
A proprietary SaaS platform can offer a cleaner API because it controls every layer. It can also change the price, restrict an integration, discontinue an endpoint or decide that a use case no longer fits its strategy. WordPress is untidy, but the site owner can inspect it, modify it, move it and keep it running. The GPL freedoms at the heart of WordPress become more valuable, not less, when automated systems start acting on a business’s behalf.
An agentic future dominated by a few closed application backends would give AI vendors enormous leverage. They would decide which products, publishers and services can be reached. WordPress offers another possibility: millions of businesses exposing their own data and capabilities from infrastructure they control.
That does not happen automatically. An open backend still needs a common language.
The Abilities API may matter more than the AI features
Most discussions about AI in WordPress focus on visible features: generate a title, rewrite a paragraph, create an image or answer a support question. Those features are easy to demonstrate and easy to sell. They are also the least important part of the architectural change.
The Abilities API gives WordPress and its plugins a shared way to register discrete operations. An ability has a name, an input schema, an output schema, a permission callback and an execution callback. It can describe a read-only action such as retrieving site information or an operation that changes something, provided the code author exposes it safely.
That sounds like developer plumbing because it is. Good plumbing is what turns a collection of clever features into a platform.
Before the Abilities API, a plugin might implement the same action several times: a PHP method for its admin page, a REST callback for an integration, a WP-CLI command for automation and perhaps a custom tool for an AI assistant. Each path could validate data differently. Each could apply permissions differently. Every new interface increased the chance of inconsistent behavior.
An ability gives that operation a canonical contract. The admin interface, REST client, command palette, automation service or AI agent can call the same underlying business action. The interface becomes replaceable while the rules remain in one place.
WordPress 7.1 made these abilities easier to filter, expose and validate. It also added a consistent public metadata flag for abilities intended for external clients. Core’s own developer note makes an essential point: exposure is not authorization. A public ability must still enforce the acting user’s permissions inside its callback. That is exactly the kind of boring distinction on which safe agent integrations depend.
Imagine an appointment plugin. Today it may give a visitor a calendar and an administrator a table of bookings. In an ability-first design, the plugin could also expose appointments/find-slots, appointments/create-booking and appointments/cancel-booking. Each operation would define the data it accepts, the result it returns and who may run it. The website would still have a human interface, but an authorized agent would no longer need to pretend to be a human to use it.
That is a more significant shift than adding a chatbot to the dashboard.
MCP gives agents a door, not the keys to the building
The official WordPress MCP Adapter translates selected abilities into MCP tools and WordPress data into MCP resources. An MCP-compatible assistant can discover what the site exposes, inspect the relevant schema and invoke the operation.
The adapter model is a smart choice because MCP will not be the last agent protocol. WordPress does not need every plugin author to hard-code support for every assistant. Plugins can define useful abilities once. Adapters can then represent those abilities through MCP, REST, WebMCP or standards that have not yet been invented.
This also puts an important boundary in the right place. The protocol does not decide whether an editor may publish a post or whether a customer may refund an order. WordPress and the plugin do. MCP is the door through which a request arrives; capabilities, authentication and the ability’s permission callback decide whether it can enter.
The distinction is easily lost in demos. An agent successfully changing a product price looks impressive. The production questions are less glamorous. Which WordPress user is the agent acting as? Was the requested change within that user’s role? Can the action be retried without applying it twice? Is there an audit record? Does a destructive operation require human confirmation? Can untrusted content manipulate the agent into calling a privileged tool?
If the ecosystem treats MCP as a magic route around WordPress permissions, the result will be a supply-chain disaster. If it treats MCP as another client of carefully designed WordPress capabilities, it can be genuinely useful.
WooCommerce shows why the backend role has commercial weight
Content management makes the architectural case. Commerce makes the business case.
WooCommerce has been moving from generic API access toward canonical business operations. Its current agent work is built around the WordPress Abilities API and MCP. The initial roadmap covered product and order management, while WooCommerce 10.9 introduced domain abilities for operations such as querying, creating and updating products, querying orders, changing an order’s status and adding an order note.
This is different from dumping a REST endpoint catalogue into an agent’s context. A canonical ability describes the business operation the caller intends to perform. The implementation can preserve WooCommerce rules, permissions and side effects without forcing every external client to understand the internal storage model.
The commercial destination is larger than store administration. WooCommerce’s own agentic commerce roadmap describes a world where products are discoverable to shopping agents and transactions can be completed securely on the user’s behalf.
If that becomes normal, the storefront is no longer the only entrance to a store. A customer may begin with a conversation inside an assistant. The assistant identifies a suitable product, checks live data from the merchant, asks the customer to approve the purchase and completes it through a controlled commerce action.
WordPress does not need to own the assistant to remain central to the transaction. It needs to remain the authoritative source for the merchant’s products, policies, customers and orders.
That is the backend thesis in one sentence.
The front end is not disappearing
Predictions about agents often make the same mistake as earlier predictions about mobile apps: they assume a new interface must eliminate the old one.
People will still visit websites. They will want to inspect a company, read a long argument, compare photographs, understand a warranty, check whether a seller looks legitimate and complete tasks themselves. Search engines, accessibility tools, regulators and customers all need stable public pages. A brand cannot outsource its entire presence to the tone and layout of somebody else’s assistant.
The website also provides the canonical material from which agent-facing information is derived. If product descriptions are vague, policies conflict and structured data is stale, an API will only expose the confusion more efficiently.
The likely future is not headless WordPress everywhere. It is multi-interface WordPress. The same installation may render a theme for people, provide JSON to an application, expose abilities to authenticated tools and publish selected operations to agents. A booking plugin may have a calendar, a REST route and an agent tool. None makes the others obsolete.
This is good news for theme developers, though not an excuse to stand still. Themes will carry less of the application’s logic and more of its human experience: trust, clarity, accessibility, performance and identity. A theme that is merely a bundle of demo imports has less protection than a theme that presents complex content beautifully and remains compatible with the structured systems underneath it.
What this means from WPBay’s side of the marketplace
Marketplaces tend to reward what is easy to show. A beautiful dashboard screenshot sells more quickly than a correct permission model. A chatbot animation is easier to market than an idempotent background operation. That bias made some sense when a buyer judged a plugin mainly by the screen it added to WordPress.
It makes less sense when software agents become users of the product too.
From WPBay’s perspective, the next valuable WordPress plugins will not simply attach an AI text box to an existing feature. They will turn useful domain logic into dependable capabilities. A shipping plugin should be able to calculate a rate through a stable operation. A deployment plugin should be able to describe and execute a safe content transfer. A booking plugin should expose availability without bypassing its own rules. An advertising plugin should return campaign data through a documented schema rather than requiring screen scraping.
This changes what quality looks like.
The plugin still needs a usable interface for people. It also needs predictable inputs and outputs, explicit permissions, useful errors, safe retry behavior and documentation that explains side effects. Destructive actions should be distinguishable from read operations. High-risk actions should support confirmation. Credentials should not be sprayed across logs. Agent activity should be attributable to a user or integration.
Those qualities are not “AI features.” They are signs of mature software. Agents are simply making their absence harder to ignore.
Marketplaces will also have to become stricter about trust. A plugin that exposes an ability to export users, change orders or publish content expands the consequences of a vulnerability. Buyers need to know who maintains the product, how updates are reviewed, which external services receive data and what happens if the product changes ownership. Code review and ownership transparency become commercial features.
There is an opportunity here for independent developers. Closed SaaS vendors will build integrations for the largest platforms first. WordPress developers can bring thousands of specialist workflows into the agentic web: regional invoicing, niche catalogues, local bookings, memberships, learning systems and industry-specific operations that will never be priorities for a global AI company.
That long tail has always been WordPress’s strength. Abilities can give it a standard interface.
The AI Client matters for a different reason
Agent access is only half of the picture. WordPress plugins will also use models internally.
WordPress 7.0 added a provider-agnostic AI Client. A plugin can describe the capability it needs and let WordPress route the request to a suitable model from a provider configured by the site owner. The Connectors screen provides a common place to configure supported providers.
This reduces a problem that has made the first generation of WordPress AI plugins unpleasant to maintain. Every plugin built its own OpenAI settings page, stored another API key, implemented another HTTP wrapper and failed in a slightly different way when a model name changed. Users ended up configuring the same provider repeatedly while developers became accidental maintainers of provider SDKs.
A shared client does not make the generated output better by itself. It does separate the plugin’s value from the AI vendor. A product can focus on a workflow—classifying support tickets, preparing product metadata or checking content consistency—while the site owner chooses the model provider.
That is aligned with the backend role. WordPress becomes the place where content, permissions, tools and model connections meet, without requiring every feature to belong to one platform company.
WordPress can still miss this opportunity
None of these APIs guarantees that WordPress will own a meaningful part of the agentic web.
The platform moves slowly, sometimes for good reasons and sometimes because fragmented responsibility makes coherence difficult. Documentation can lag behind implementation. Authentication for external clients remains intimidating for ordinary site owners. Plugin developers may expose hundreds of low-quality tools with vague descriptions and overlapping purposes. Hosting security products may block legitimate agent traffic while allowing an impersonated user agent through.
The ecosystem may also repeat its page-builder mistake: ten incompatible abstractions solving the same problem, each insisting that its interface should become the standard. An ability registered by one plugin is only useful to an external client if its naming, schema and behavior are understandable. Shared APIs need conventions, not merely functions.
Security is the largest risk. Traditional WordPress vulnerabilities are often triggered by a malicious visitor or a logged-in user. An agent adds a confused intermediary that reads untrusted material and can call tools. A support ticket, product description or imported document may contain instructions designed to manipulate the agent. WordPress capability checks remain necessary, but they do not solve prompt injection or excessive delegated authority.
Developers should expose the smallest useful operation, grant the narrowest practical permission and keep humans in the loop for irreversible actions. Read abilities should not quietly write. A dry run should be available where the consequence is expensive. Every mutation should leave enough evidence to reconstruct who requested it and what changed.
There is also a business risk. If agents consume WordPress content and complete transactions without sending visitors to the site, publishers may lose advertising impressions and direct customer relationships. Being the backend is only attractive if the owner can retain attribution, control and a reasonable share of the value. The technical standards are advancing faster than the commercial settlement.
WPBay cannot answer that question for the entire web. We can insist that WordPress products respect the owner’s data and make automated access visible rather than hiding it behind a vague “AI-powered” label.
What WordPress developers should build now
The immediate job is not to add MCP to every plugin.
Start by finding the real business operations already buried in the product. Separate them from the admin-page callback that currently triggers them. Give each operation a clear input, a clear result and one place where permissions are enforced. Make it possible to call the same logic from PHP, REST or a background job without duplicating the rules.
Once that boundary is solid, registering selected operations as WordPress abilities becomes a natural next step. Read-only discovery is a safer place to begin than autonomous mutation. A stock plugin might expose inventory lookup before inventory changes. A form plugin might expose submission status before submission deletion. The value comes from a dependable contract, not from the number of tools an agent can see.
Test failures as carefully as successful calls. Agents need errors they can interpret without inventing a recovery path. Distinguish invalid input from missing permission, a temporary upstream failure and a business rule that rejected the action. Use idempotency controls for operations that may be retried. Log enough context to investigate an incident without storing secrets or unnecessary personal data.
Finally, maintain the human interface. An owner should be able to see which integrations are connected, which abilities they can use and what they have done. The best agentic plugin will not force a customer to open a terminal to understand its activity.
This work is less exciting than adding a prompt field. It is also far more defensible.
So, is WordPress dying?
The easy-growth period may be ending. WordPress can no longer assume that every person who needs a website will begin by shopping for a theme. AI builders and closed platforms are taking legitimate market share, and the WordPress experience still carries friction the ecosystem has tolerated for too long.
But “dying” describes a platform whose relevance is collapsing. That is not what WordPress 7.0 and 7.1 look like. A provider-neutral AI client, discoverable abilities, external exposure controls, REST infrastructure and an MCP adapter are not the work of a CMS preparing for irrelevance. They are the beginnings of a system that can serve people, applications and agents through different interfaces.
The more interesting question is whether WordPress developers recognize the change soon enough.
If the ecosystem keeps defining a plugin as a settings page plus some hooks, WordPress will lose more ground to systems designed around clean APIs and automated workflows. If plugins begin exposing their best domain logic as secure, documented capabilities, WordPress gains a role that no AI website generator can easily copy.
It becomes the place where a business owns its content, products, customers, rules and actions—and decides which humans and machines may use them.
WordPress may become less visible in that world. Infrastructure often does. Databases do not need a hero section, and operating systems do not need to win a design award every year. They matter because everything else depends on them.
From where we sit at WPBay, that does not look like death.
It looks like a backend growing into its next job.
Frequently asked questions
Is WordPress market share really declining in 2026?
Yes. W3Techs’ daily survey shows WordPress declining from 43.4% of measured websites in September 2025 to 40.2% on September 27, 2026. The trend deserves attention, although it measures detectable website technology rather than every private, headless or application-level use of WordPress.
What is the agentic web?
The agentic web is an emerging model in which AI agents can discover information and perform structured actions for users. Instead of relying entirely on simulated clicks, agents can use declared tools, schemas and protocols to interact with websites and services more reliably.
Why is WordPress suited to become an agent backend?
WordPress already combines structured content, users, permissions, media, revisions, extensibility and a distributed REST API. Plugins add specialized business logic. The Abilities API can describe that logic through discoverable, typed operations that external clients can use without bypassing WordPress authorization.
Is the Abilities API only for AI?
No. Abilities can be consumed from PHP, JavaScript, REST, command interfaces, automation systems and agent adapters. AI is one important consumer, but the larger benefit is giving WordPress operations a consistent contract across interfaces.
Does MCP give an AI agent full access to WordPress?
It should not. The MCP adapter exposes only selected abilities, and each ability must enforce authorization. The acting identity, WordPress capabilities, input validation and confirmation rules still determine what an agent may do.
Will agents replace WordPress themes?
No. People will continue to use websites for trust, research, visual comparison, accessibility and direct control. Agent interfaces will become an additional entry point. Themes remain responsible for the human experience even when the same WordPress installation also serves applications and agents.
What does this change for WordPress plugin developers?
Plugin developers should separate business operations from admin screens, define predictable inputs and outputs, enforce permissions in one place and design mutations for safe retries and auditing. Exposing an ability should come after that foundation, not before it.
Sources and further reading
W3Techs: historical CMS usage trends and W3Techs methodology
WordPress 7.1 Field Guide, WordPress 7.1 release announcement and the public exposure flag developer note
AI Building Blocks for WordPress
Introducing the AI Client in WordPress 7.0 and Introducing the Connectors API
WooCommerce AI and agentic commerce roadmap and canonical WooCommerce abilities
