WordPress 7.0 RC1 is out, and on paper the April 9 release looks like an easy glide. Follow the AI Contributor group for a week, though, and it is obvious the real work is happening inside the AI Experiments plugin. The WordPress 7.0 AI features are less about a few new buttons than about how a site will talk to everything else in the ecosystem.
I have watched experimental features break sites since the 4.x days, so my optimism comes with conditions. The team is currently balancing a “Try AI” callout against serious plumbing like the Model Context Protocol (MCP). What follows is the part that matters if you run this in production.
From RC1 to April 9
The target is still April 9, 2026. Real-time collaboration is the open argument internally, and it could shift the timing of RC2 without moving the ship date. If the window gets tight, advanced connector filtering is the piece most likely to slide to 7.1.
If you have not started testing, start now. My WordPress AI Connector Plugins testing guide walks through how an existing stack copes with the new API layers.
AI Experiments v0.7: provenance and classification
The AI Experiments plugin, v0.6 now and v0.7 next, is where the actual experimenting happens. The addition I care about most is content provenance tracking through C2PA. With deepfakes and AI-generated spam everywhere, being able to check where a piece of text or an image came from, right in the media library, is worth real money to enterprise teams.
- Content classification suggests tags and categories from the content, title, and excerpt. That saves a lot of cleanup on a site with messy taxonomies.
- The meta description experiment hooks into existing SEO plugins and writes those tedious snippets for you.
- Content resizing adjusts layout inside the editor.
The MCP adapter, and why interop matters
MCP is the biggest technical shift in the release. Instead of a bespoke workaround per model, one for Claude, one for ChatGPT, one for Gemini, MCP gives them a standard way to discover what a WordPress site can do. The site becomes a resource a model reads without special-casing.
Naming took up a chunk of the last meeting. The open question is wp_supports_ai() against wp_allows_ai(), and which one sits better with existing Core patterns. Registering a custom connector looks roughly like this:
<?php
/**
* Example of checking for AI support in WordPress 7.0
*/
function bbioon_check_ai_compatibility() {
// Checking if the current environment allows AI-driven features
if ( function_exists( 'wp_supports_ai' ) && wp_supports_ai() ) {
// Register your MCP adapter or AI connector here
bbioon_register_custom_ai_connector();
} else {
error_log( 'WordPress 7.0 AI Features are not enabled on this environment.' );
}
}
add_action( 'init', 'bbioon_check_ai_compatibility' );
Branding, and the icon that looked broken
One detail from the summary stuck with me. The team paused a set of plugin icons built around a WordPress logo breaking apart, because it read as AI breaking WordPress. Perception of stability counts for as much as the code underneath it. There is more on that in why the AI client ecosystem matters.
If the 7.0 AI work is eating your dev hours, I can take it on. I have been working with WordPress since the 4.x days.
Standardize now, or refactor after 7.1
MCP and C2PA are not hype-chasing. They are the parts built to outlast this cycle. If you are shipping custom AI integrations today, follow the Gutenberg 22.7 Content Guidelines while you do it. Skipping them buys you a refactor once 7.1 lands.
