WordPress 7.0 introduced a genuine foundation for building AI features into WordPress. That is different from installing a chatbot plugin or adding a writing assistant to the editor. It gives developers common infrastructure for connecting to AI providers, registering actions and building controlled workflows.
For organisations running complex, business-critical or heavily integrated WordPress websites, this is significant. It creates new possibilities for content operations, administration, search, automation and connected business systems.
It does not mean every WordPress 7 website is suddenly AI-powered, and it is not a reason to give an external model broad access to a production platform.
This article explains what WordPress 7 actually introduced, what it could allow organisations to build and how to approach adoption without creating unnecessary security, governance or operational risk.
What Actually Changed With WordPress 7?
The important change is not one finished AI feature. It is a set of building blocks that developers and plugin authors can use to create AI-assisted functionality more consistently.
The WP AI Client
The WP AI Client is a provider-agnostic PHP API built into WordPress Core. It gives plugins a standard way to send requests to generative AI models and receive their results.
Instead of every plugin building a separate integration for OpenAI, Anthropic, Google or another provider, the plugin can describe what it needs and use the common WordPress interface. WordPress then routes the request to a suitable model from a provider configured for that website.
This reduces some of the fragmentation associated with AI plugins. It also gives developers a more consistent basis for handling text, structured responses and other supported model outputs.
The Connectors API and Provider Settings
WordPress 7.0 also introduced the Connectors API and a central Settings → Connectors screen. The initial focus is AI providers, with featured connections for Anthropic, Google and OpenAI.
The screen helps site administrators install the relevant provider integration, add credentials and see connection status in one place. Developers can also register additional connectors.
This is useful infrastructure, but it is not the same as an AI feature. Connecting a provider does not automatically give that provider access to all WordPress content or switch on autonomous behaviour. A plugin or custom implementation still has to define the task, input, permissions and output.
The Abilities API
The Abilities API was introduced in WordPress 6.9 and expanded in WordPress 7.0 with a JavaScript counterpart for client-side and hybrid abilities.
It provides a standard way for WordPress Core and plugins to describe discrete actions that can be discovered and executed. Each ability can define its inputs, outputs, permission checks and execution logic.
An ability could retrieve site information, update content, run a diagnostic or perform another bounded action. AI agents can use abilities, but the API is not exclusively an AI permissions system. It can also support plugins, browser agents and conventional workflow automation.
The distinction matters. WordPress does not grant an AI system a new universal permission called “access the website”. Developers register specific actions and must apply appropriate WordPress capability checks to each one.
The WordPress MCP Adapter
The WordPress MCP Adapter is an official package within the AI Building Blocks for WordPress initiative, but it is not included in WordPress Core.
It can translate selected WordPress abilities into tools and resources that compatible AI applications can discover through the Model Context Protocol. In practice, this can allow an external assistant or development tool to query information or execute tightly defined WordPress functions.
Abilities are not automatically exposed through the adapter. They must be selected or explicitly marked for access, authenticated and protected by permission callbacks. That is an important safeguard, but it still requires careful implementation.
What WordPress 7 Does Not Do Automatically
WordPress 7.0 does not automatically:
- Generate or publish website content.
- Moderate comments or manage editorial approval.
- Give an AI model access to every page, form submission or user record.
- Turn registered abilities into a fully autonomous agent.
- Guarantee the quality, accuracy or security of AI features built by plugins.
- Remove the need for provider accounts, credentials, usage controls or contractual review.
The release gives developers better foundations. What gets built on top of those foundations, how it is governed and whether it is appropriate for the organisation remain separate decisions.
What Could These Capabilities Allow Organisations to Build?
The practical opportunity is broader than generic content generation.
Context-aware editorial assistance. A bespoke tool could help editors summarise long content, draft metadata, suggest internal links or check material against an organisation’s style and content model. The useful difference is that it can be designed around the actual WordPress structure rather than operating as a disconnected browser extension.
Content quality and governance checks. AI-assisted workflows could identify outdated content, missing summaries, inconsistent terminology or pages that require human review. The system could create a review task without being allowed to change or publish the page itself.
Administrative workflow automation. Bounded abilities could support repetitive tasks such as preparing reports, categorising submissions, creating draft records or summarising activity for operational teams.
Internal search and knowledge access. Organisations with large publishing estates could build internal assistants that retrieve approved WordPress content and help staff locate information, while keeping the underlying source material traceable.
Connected CRM and service workflows. A carefully designed WordPress CRM integration could use AI for classification, summarisation or workflow support while conventional application logic remains responsible for validation and record creation.
Bespoke operational tools. The strongest opportunities are often specific to one organisation: a legal review queue, multilingual content support, a membership-service assistant or a tool that prepares information from several systems for human approval.
These are development and integration projects, not settings to enable. For more complex requirements, they may sit closer to a WordPress web application than a conventional content plugin.
Why Business-Critical Websites Need a Cautious Approach
New infrastructure is not the same as a safe, finished product. Organisations using WordPress for revenue, applications, membership, regulated content or connected operations need to consider the complete risk model.
Data sent to external providers. Prompts can contain website content, user input or operational data. The organisation needs to know exactly what leaves WordPress, which provider receives it, where it is processed and what contractual or retention terms apply.
Permissions and authentication. Every ability or external connection should use the least privilege required. Read-only access is materially different from the ability to edit content, export data or trigger a business process.
Inaccurate output. AI-generated material can be plausible and wrong. For legal, medical, financial, public-sector or other sensitive content, an error may create more than a reputational problem.
Untrusted content and instructions. Systems that process user submissions, external documents or web content need to account for malicious or misleading instructions embedded in that material. AI output should never be treated as trusted application logic.
Provider reliability and cost. External models can become unavailable, change behaviour, introduce new limits or alter pricing. A critical website journey should not fail silently because an AI request timed out or exceeded a quota.
Credential management. API keys and service accounts need controlled storage, restricted administration and a clear rotation process. Connecting an AI provider through the dashboard does not remove the organisation’s responsibility for credential security.
Auditability and accountability. The organisation should be able to explain what the AI system received, what it returned, which action followed and whether a human approved the result.
Plugin and supply-chain risk. The quality of an AI feature still depends on the plugin or custom code implementing it. A standard Core API improves consistency, but it does not make every extension safe or maintainable.
Questions to Answer Before Enabling WordPress AI Features
Before an AI feature reaches a production website, the organisation should be able to answer the following questions.
- What business problem is this solving? A bounded, measurable use case is easier to govern than a general ambition to “add AI”.
- Which data can the feature access? List the content, user information, submissions and connected systems explicitly.
- Which provider and model will process the data? Review security, retention, location, contractual terms, availability and cost.
- What actions can the feature perform? Separate reading, drafting, editing, publishing, deleting, exporting and triggering other systems.
- Which WordPress user and capabilities are involved? Avoid using a broad administrator account where a restricted service identity would be sufficient.
- Where is human approval required? Consequential content and operational changes should normally remain reviewable.
- What is logged? Record relevant prompts, outputs, actions, failures and approvals without creating unnecessary new stores of sensitive data.
- Can the action be reversed? Version history, backups, rollback and data reconciliation should be part of the design.
- What happens when the provider fails? Define timeouts, retries, user messages and a safe non-AI fallback.
- How will cost and usage be controlled? Set limits, monitor consumption and prevent loops or uncontrolled bulk processing.
A Practical WordPress AI Adoption Process
There is no need to move directly from having no AI functionality to allowing an automated system to act on a production website. A phased process is safer and produces better evidence about whether the idea is useful.
- Assess the current platform. Review WordPress health, permissions, integrations, data flows, hosting, backups and technical debt. Introducing AI to an unstable platform compounds risk. A focused WordPress audit can establish the baseline.
- Choose one bounded use case. Start with a task that has a clear owner, input, output and success measure. Read-only or draft-only uses are usually more appropriate than autonomous publishing.
- Define governance before development. Agree approved providers, data restrictions, permissions, review requirements, logging and failure handling.
- Prototype away from production. Use synthetic or appropriately protected data to test whether the model can perform the task reliably enough to justify further work.
- Test on a representative staging environment. Include the relevant plugins, permissions and integrations without exposing real users to an immature workflow.
- Apply least privilege. Register only the abilities required, use narrow WordPress capabilities and avoid broad access to content or user data.
- Keep a human approval stage. Require review before publishing, sending, deleting or triggering a consequential business action.
- Monitor the live feature. Track errors, provider latency, usage, cost, output quality and the operational effect of failures.
- Expand only with evidence. Increase scope when the original use case is stable, valuable and understood by the people responsible for it.
Where Bespoke WordPress Development May Be Needed
Off-the-shelf plugins will be appropriate for some low-risk use cases. They are less likely to match the workflows that matter most to organisations with complex platforms.
Organisation-specific workflows. A content process involving legal review, regional approval, CRM activity or a proprietary taxonomy may require a purpose-built integration.
Controlled abilities and permissions. Custom development may be needed to register the exact actions required, connect them to appropriate WordPress capabilities and prevent the AI layer from doing anything else.
CRM and operational integrations. AI can assist with classification or summarisation, but conventional code still needs to handle authentication, validation, field mapping, retries and error reporting reliably.
Approval, logging and observability. Generic plugins may not provide the audit trail, cost monitoring, review states or incident visibility required by the organisation.
Internal search and knowledge tools. A useful assistant needs access to the right approved sources, permission-aware retrieval and links back to the original material. This is an information-architecture and application-design problem as much as an AI problem.
For larger organisations, this work belongs within a wider enterprise WordPress development plan rather than being introduced as an isolated experiment with no long-term owner.
The Real Opportunity for WordPress and AI
The value of WordPress 7 is not that it makes every website artificially intelligent. It gives the ecosystem a more coherent foundation for building AI-assisted features without every plugin inventing its own connection and execution model.
The strongest uses will reduce genuine operational friction. They may help an editor prepare a draft, surface content that needs review, summarise information for a service team or make an existing process faster without removing accountability.
The weakest uses will add another plugin, another external dependency and another source of unreviewed output to an already complex platform.
Business-critical website owners should therefore treat WordPress AI as a controlled development and integration opportunity. Start with the platform, define the use case, protect the data and keep ownership of the result.
Planning how AI could be introduced to an existing WordPress platform? Make Do can assess the website, identify realistic use cases and design a controlled route to adoption. Talk to the Make Do team about the opportunity and the risks involved.
