AI & WordPress

Built-in AI integration in WordPress

WordPress is no longer “AI-adjacent only through third-party plugins.” From WordPress 6.9, core ships an Abilities API — a registry where plugins declare discrete, permission-checked capabilities (read SEO scores, update a post meta field, run a sync job). The optional MCP Adapter exposes those abilities to external AI agents via the Model Context Protocol.

WordPress 7.0 extends this with the Connectors API and AI Client: a unified way to register AI providers (OpenAI, Google, Anthropic, and others), store API credentials server-side, and call models from PHP or the block editor — without each plugin reinventing OAuth, key storage, and HTTP clients.

The three layers

• Connectors — wp_register_connector() registers an AI provider. Admins connect credentials once in Settings → Connectors (or via the AI plugin UI). Keys stay on the server.
• AI Client — PHP and JavaScript APIs that send prompts to a connected provider, with structured responses and function-call resolution against registered abilities.
• Abilities — wp_register_ability() declares what your plugin allows an AI workflow to do on the site — with schemas, permission callbacks, and audit-friendly boundaries.

External agents typically reach WordPress through MCP and abilities. In-editor and server-side features use connectors + AI Client directly inside WordPress — the pattern production plugins will adopt for “assist on save” workflows.

What AI connectors enable today

Once an administrator connects a provider, any plugin that uses the AI Client can request generations — titles, excerpts, alt text, summaries, structured JSON — without bundling its own SDK or billing UI.

• Central credential management — one place to add, rotate, or revoke API keys; plugins consume connectors instead of custom settings screens.
• Provider-agnostic calls — swap OpenAI for Google Gemini in settings; plugin code targets the AI Client abstraction.
• Editor-adjacent workflows — the AI plugin (when installed) adds admin UI for image, title, excerpt, and alt-text generation using connected providers.
• Ability-aware prompts — models can call registered abilities (e.g. read post meta, list inventory rows) through the AI Client function resolver — grounded in real site data, not hallucinated context.
• Security by default — permission callbacks on every ability; connector keys never ship to the browser or REST responses.

This is the foundation for event-driven AI in WordPress: hooks you already use (save_post, rest_after_insert_post, block editor saves) can trigger connector-backed suggestions while abilities enforce what the model is allowed to read or write.

Connectors vs Abilities vs MCP

4WP.dev covers MCP in depth on the MCP guide and ships 4WP MCP Abilities for agent tooling. AI & WordPress focuses on in-core connectors and editor/server workflows — the path for plugins that react when content changes.

Planned case study: 4WP SEO Helper + content-change AI

4WP SEO Helper already tracks site-wide SEO inventory, Google Search Console sync, and per-URL Dynamics — an event history when content, SEO meta, indexing, or GSC signals change. The next practical step is wiring WordPress AI connectors into that pipeline so editors get grounded suggestions at the moment they save — not in a separate chat window.

What exists today (v2.1)

• SEO Inventory — P1–P3 lanes, completeness scores, bulk meta updates via Yoast / AIOSEO adapters.
• History / Dynamics — records content, seo, gsc, and indexing events per post when something materially changes.
• Editor sidebar — SEO scores, cross-posting drafts, and llms.txt preview from post content.
• REST inventory API — external tools can read and sync SEO rows (foundation for agent workflows).

Planned integration (next major release)

When a post is saved and the body or title changes beyond a threshold, SEO Helper would:

1. Detect the change — reuse the existing History fingerprint logic (TYPE_CONTENT) so AI runs only on meaningful edits, not every autosave.
2. Build context — pass title, excerpt, focus keyphrases, inventory priority, and a plain-text summary of blocks to the AI Client (via a connected provider).
3. Suggest SEO meta — propose meta title, description, and additional focus keyphrases aligned with the updated content — shown in the editor sidebar for review, not auto-applied.
4. Register abilities — expose read-only abilities (inventory row, GSC snapshot) and optional write abilities (apply suggested meta) so the same flow works from MCP agents and from in-editor UI.
5. Log the assist — append a Dynamics event when suggestions were generated or accepted, keeping audit trail beside human edits.

Design principles for this feature:

• Human-in-the-loop — AI proposes; the editor approves. No silent overwrites of Yoast/AIOSEO fields.
• Connector-native — uses WordPress AI connectors and AI Client; no duplicate API key screens in SEO Helper settings.
• Ability-gated writes — any auto-apply path goes through wp_register_ability() with capability checks matching inventory permissions.
• Graceful fallback — if no connector is configured, SEO Helper behaves exactly as today.

This pattern — content hook → AI Client → abilities → optional meta write — is reusable across 4WP plugins (FAQ drafts, notification copy, block alt text) and is the direction WordPress core is standardizing around.

Related on 4WP.dev

• MCP for WordPress — connect external AI agents via the Model Context Protocol.
• AI Workflows — broader automation and agentic patterns for WordPress teams.
• 4WP SEO Helper — SEO inventory, Search Console, and Dynamics (GitHub).
• 4WP MCP Abilities — abilities exposed for MCP clients.
• REST API — custom routes that complement abilities for headless and tooling.

← Back to AI Workflows