WordPress has started an experiment I have wanted since the early days of the block editor: Gutenberg Content Guidelines. It lives in Gutenberg as an experiment for now, and the goal is a first-class, machine-readable home for site-wide content standards. The “experiment” label undersells it, because this changes where editorial logic lives.
If you have built for multi-author sites or agencies, you know the drill. Brand voice, accessibility rules and image standards end up in a PDF nobody opens or a pinned Slack message. Authors ignore them, and developers wind up hardcoding checks into custom meta boxes to enforce them. WordPress is trying to move that logic into the editor itself.
Why Gutenberg Content Guidelines matter
The value is not the UI where editors read the rules. It is that the guidelines are machine-readable. AI publishing tools are ordinary now, and they need one place to look up what a site allows. With this, an AI assistant or a third-party plugin can query the site’s standards before it writes a word.
It also takes some risk out of future AI integrations. Right now, five AI plugins mean five separate “tone of voice” settings. Gutenberg Content Guidelines would give all of them one API to read from. Core has been drifting toward structured data for a while, as I noted going through the WordPress 7.0 developer features, and this fits that direction.
Under the hood
The experiment is tracked in PR #75164, and it sets up persistent storage for these rules. That includes basic revision history, since brand guidelines change, plus a retrieval system tools can depend on. What interests me most is pulling those rules into custom block configuration through a standard hook or data store.
Say you wanted to check a post against the site’s voice guidelines before it moves to pending status. The logic might end up looking something like this, though the API is still speculative:
<?php
/**
* Speculative example of checking site-wide guidelines
*/
function bbioon_validate_content_against_guidelines( $post_id ) {
// This is a conceptual example of how an API might be accessed
$guidelines = get_site_content_guidelines( 'tone_of_voice' );
if ( empty( $guidelines ) ) {
return;
}
// Logic to pass guidelines to an LLM or validator tool
// bbioon_check_compliance( $post_id, $guidelines );
}
add_action( 'wp_insert_post', 'bbioon_validate_content_against_guidelines' );
That beats hardcoding strings into your theme’s functions.php or spreading them across three plugins. If you want more on where Gutenberg is heading, I have notes on pattern overrides in Gutenberg 22.4.
If this Gutenberg Content Guidelines stuff is eating your dev hours, I can take it off your hands. I have been wrestling with WordPress since the 4.x days.
What I would watch next
Content Guidelines reads like a site-management feature that AI tools will end up depending on. Setting the guardrails now matters more if autonomous agents start handling commerce and customer conversations, since whatever they do will be bounded by whatever the site declares. Tracking issue #75171 is where the schema is being worked out.
