WordPress 22.7 just introduced Gutenberg Guidelines, and the documentation makes it look like a simple settings page. But if you dig into the source code, you’ll see they are laying the plumbing for something much bigger: a unified source of truth for both human editors and AI agents. I’ve seen enough “editorial guide” plugins come and go to know that native integration is the only way this actually sticks.
For years, keeping a site’s voice consistent meant a PDF tucked away in a Slack channel that nobody ever opened. Now, we have a first-class citizen in the database to handle this. You can check out more about the general release in this overview of Gutenberg 22.7, but here I want to focus specifically on why this experiment is a shift in how we think about site data.
The Architecture of Gutenberg Guidelines
The first thing I did was check the database. Gutenberg Guidelines doesn’t just dump data into a serialized option. It uses a Custom Post Type (CPT) named wp_content_guideline. Each category—Site, Copy, Images, and Blocks—is stored as post meta with full revision support. Specifically, this means you get atomic updates and the ability to roll back changes when an editor goes rogue with the tone of voice.
The REST API integration is equally clean. The feature exposes endpoints at /wp/v2/content-guidelines. If you are building a custom block or an AI integration, you can filter by category or even by block type (e.g., ?block=core/paragraph). This is a massive win for performance because you aren’t fetching a 50KB JSON blob when you only need the rules for image alt text.
Extending Guidelines for Custom Needs
While the UI currently focuses on capture and retrieval, the real power is how we can hook into this. Although the plugin API for custom categories is still evolving, you can already start thinking about how to consume this data. Here is a quick example of how you might fetch these Gutenberg Guidelines via JavaScript to use in a custom pre-publish checklist:
async function bbioon_fetch_copy_guidelines() {
try {
const response = await fetch('/wp-json/wp/v2/content-guidelines?category=copy');
if (!response.ok) throw new Error('Network response was not ok');
const guidelines = await response.json();
// Log the editorial tone to the console for debugging
guidelines.forEach(item => {
console.log(`Guideline: ${item.meta.content_guideline_value}`);
});
} catch (error) {
console.error('Failed to fetch Gutenberg Guidelines:', error);
}
}Notice the manage_options requirement. The core team was smart enough to lock these endpoints down by default, so you don’t have to worry about your brand’s internal “voice and tone” rules leaking to unauthenticated users. It’s a common bottleneck I see in custom API development where developers forget basic capability checks, but Gutenberg handles the heavy lifting here.
Why This Matters for AI Strategy
We need to talk about the “why” behind this. As we move toward more automated workflows, AI needs context. Without Gutenberg Guidelines, an AI assistant is just guessing your brand’s personality. By providing a structured “source of truth” within the WordPress admin, we are essentially building a prompt-engineering library that is persistent across the whole site. I previously touched on this when discussing why this Guidelines experiment is huge for the ecosystem.
Look, if this Gutenberg Guidelines stuff is eating up your dev hours, let me handle it. I’ve been wrestling with WordPress since the 4.x days, and I know exactly how to bridge the gap between core experiments and production-ready features.
The Takeaway
Guidelines isn’t just a fancy text box; it’s a structural evolution. By moving content standards into a revision-tracked CPT with a dedicated REST API, WordPress is preparing for a future where content isn’t just written—it’s governed. Specifically, the inclusion of block-level rules means we can finally enforce “Alt Text” requirements or “Short Sentence” preferences at the component level rather than a generic site-wide rule. If you haven’t enabled the experiment yet, go to Gutenberg > Experiments and check it out. Just remember to keep an eye on the tracking issue on GitHub for breaking changes.
