How to Integrate AI in WordPress in 2026
Since May 2026, WordPress ships AI plumbing as part of its core. This is different than shipping with AI.
That distinction is the whole answer to how to integrate AI in WordPress this year. Every real integration now goes in one of two directions: outbound, where your site calls a language model, or inbound, where an external AI agent calls your site. Outbound runs through the WP AI Client bundled in WordPress 7.0. Inbound runs through the Abilities API plus the MCP Adapter, which is not in core.
I wrote a taxonomy of the five categories of WordPress AI integration a couple of months back, covering what each type looks like in production. This post sits above that one. It covers the plumbing all five categories now run on.
What "AI integration" means in WordPress after 7.0
WordPress 7.0's AI layer is four pieces of infrastructure: a provider-agnostic PHP client for talking to models, a registry of declared actions, a settings screen where site owners store credentials, and a Connectors API underneath that screen for developers registering new connection types. Per the WordPress 7.0 field guide, core handles request routing while site owners manage API keys in Settings > Connectors. No provider is bundled with core. The WordPress project maintains three official provider plugins, for Anthropic, Google, and OpenAI, and anyone can write another.
So a fresh WordPress 7.0 install has AI capability and zero AI features at the same time. You get the second one by installing something on top: a plugin somebody else wrote, or code you write yourself.
WordPress 6.9 started this in December 2025 with the PHP side of the Abilities API. WordPress 7.0 added the JavaScript counterpart for client-side abilities like inserting blocks or moving around the editor, which is the piece that matters for browser agents. All of it belongs to the project's AI Building Blocks initiative, which is worth knowing as a search term because the naming across blog posts and dev notes is inconsistent.
Outbound: how WordPress calls an AI model
Outbound integration means your PHP code sends a prompt and gets a result back, with core handling which provider answers. The entry point in WordPress 7.0 is wp_ai_client_prompt(), a fluent builder documented in the core dev note published in March 2026:
$text = wp_ai_client_prompt( 'Summarize the benefits of caching in WordPress.' )
->using_temperature( 0.7 )
->generate_text();
if ( is_wp_error( $text ) ) {
return;
}
If you have been building against the standalone wordpress/php-ai-client package, the migration is a find-and-replace: AI_Client::prompt() becomes wp_ai_client_prompt(), and you drop the Composer dependency once you require WordPress 7.0.
Two methods matter more than anything else in that builder for production work. is_supported_for_text_generation() tells you whether the site actually has a provider configured before you render an AI button, and it costs nothing because it runs against known model capabilities rather than making a call. The wp_ai_client_prevent_prompt filter lets you block prompts outright, which is how you stop an editor role from burning tokens on a site where only admins should be generating anything.
That second one exists because unrestricted generation is a spending surface. I maintain WP-AutoInsight, a WordPress AI plugin with over 3,000 active installations, and the questions that keep coming back have almost nothing to do with model quality. They are about who on the site can trigger a generation and what that costs when several people do it on the same afternoon. WordPress core's official AI plugin now ships request logs in the admin screen, which reads to me like the first honest acknowledgment from the platform that these features cost money.
Outbound is also where content pipelines live, and the biggest wins usually happen outside WordPress entirely. The n8n pipelines I built for an e-commerce client cut content production costs by 60 to 80 percent, and WordPress was the publishing endpoint rather than the brain.
Inbound: how an AI agent calls your WordPress site
Inbound integration means Claude, Cursor, or any other MCP client can enumerate what your site is able to do and run those actions with your permissions. This is the newer half, and the half most guides still get wrong.
An ability is a declared action with a name, an input schema, an output schema, and a permission callback. Registering one makes it available to core and to any other plugin or automation tool that asks. Exposing it to an outside agent takes a second piece: the MCP Adapter, maintained at WordPress/mcp-adapter, installed as a plugin or through composer require wordpress/mcp-adapter. Per the adapter's own installation docs, it requires WordPress 6.9 or higher and PHP 7.4 or higher. It is not bundled with core, and there is no sign that it will be soon.
Two things to check before you copy a tutorial. First, if a guide tells you to install Automattic/wordpress-mcp, close it. That repository was archived on January 19, 2026, and the migration notice points to the adapter. Second, the adapter is at version 0.6.0 and changing fast. The 0.6.0 release raised the WordPress floor to 6.9 and flipped an exposure default: abilities marked meta.public: true now show up on the default MCP server unless they explicitly opt out with meta.mcp.public.
Read that last one twice if you run client sites.
A default that changes direction between minor releases is exactly how a site ends up exposing more than its owner intended, and the capability checks that still apply underneath are only as good as the WordPress role you connected with. I wrote a whole post about what happens when an AI agent has the keys to everything, and the MCP Adapter is the most legitimate, best-engineered version of that risk currently available. Connect it with a scoped user on staging before you point anything at production.
What WordPress 7.1 actually added for AI
Not much, and that is worth saying plainly because plenty of coverage implied otherwise. WordPress 7.1 "Mary Lou" shipped on schedule on August 19, 2026, and its single AI contribution was authentication: the Connectors screen now accepts username and application-password login alongside API keys, per the release's beta announcement on WordPress.org. The proposed Guidelines system was declined for this cycle, and the larger AI Client work moved to 7.2.
How to integrate AI in WordPress without breaking production
Start with the direction, then the smallest surface that direction allows.
For outbound, that means one feature and one role allowed to trigger it, with logging switched on from day one. Generating alt text is a good first target because the output is short and a bad result is obvious the moment you look at it. Draft generation is a bad first target for the opposite reasons.
For inbound, that means one ability and one scoped user, on a staging site. Register the ability yourself rather than switching on a bundle you did not write, because every ability you expose is a function an agent can call while you are asleep.
The proportions surprise people. When I built a production RAG chatbot against a live WooCommerce catalog for a Canadian health and wellness client, the model integration took hours. Everything else took months: keeping the bot away from customer data, keeping it grounded in real SKUs instead of plausible ones, keeping compliance copy where the regulator expects it, and making sure a hostile prompt could not turn a support chat into a discount authority. The AI call was the cheap part of that build by a wide margin.
For the developer side of all this, where the AI writes the plugin instead of living inside it, Claude Code for WordPress development covers the workflow I actually use.
So what do you build first
If you publish content and want AI in the editor, install the official AI plugin, connect one provider, and watch the request log for a month before you add a second feature.
If you are a developer shipping to clients, register abilities for the things your plugin already does. That work pays off twice, once for core's AI features and once for whatever agent shows up next year, and it costs you a schema and a permission callback.
If you want Claude to manage your site directly, the MCP Adapter is the supported path. It is also pre-1.0, so it deserves a scoped user on staging rather than an admin account and optimism.
And if someone tells you WordPress 7.0 made AI integration a solved problem, ask them which direction they mean.
If you are trying to work out whether your site should be calling a model, answering an agent, or neither, that decision is most of what I do in WordPress AI integration work. The contact form is the fastest way to start that conversation.