Gutenberg 22.7 shipped Gutenberg Guidelines, and the documentation makes it look like a settings page. Read the source and it is clearly plumbing for something larger: one place where both human editors and AI agents can read the site’s editorial rules. I have watched enough “editorial guide” plugins come and go to know that only native integration survives.
For years, keeping a site’s voice consistent meant a PDF sitting in a Slack channel that nobody opened. Now the rules live in the database. There is a wider overview of the release in my notes on Gutenberg 22.7; this post sticks to the storage side and why it changes how you treat site data.
How Gutenberg Guidelines are stored
The first thing I did was check the database. Gutenberg Guidelines does not dump everything into a serialized option. It registers a custom post type called wp_content_guideline, and each category (Site, Copy, Images, Blocks) is stored as post meta with revision support. So you get atomic updates, and you can roll a change back when an editor gets creative with the tone of voice.
The REST side is just as tidy. The endpoints sit at /wp/v2/content-guidelines, and if you are building a custom block or an AI integration you can filter by category or by block type, as in ?block=core/paragraph. That filtering is worth having: you are not pulling down a 50KB JSON blob when all you need is the rule for image alt text.
Extending guidelines for your own rules
The UI only captures and retrieves for now, and the plugin API for custom categories is still moving, but nothing stops you from consuming the data today. This fetches the copy Gutenberg Guidelines in JavaScript, roughly the shape you would want behind 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);
}
}Note the manage_options requirement. Core locks these endpoints down by default, so your internal “voice and tone” rules are not readable by unauthenticated visitors. Forgetting the capability check is the usual mistake in hand-rolled API work, and here you do not get the chance to make it.
What this gives an AI assistant
Automated workflows need context, and an assistant with no guidelines is guessing at your brand’s personality. Structured rules stored in the admin are effectively a prompt library that persists across the whole site, which is the part I got excited about when I wrote that the Guidelines experiment is huge for the ecosystem.
If this Gutenberg Guidelines work is eating your dev hours, hand it over. I have been wrestling with WordPress since the 4.x days and I know where core experiments break in production.
What to do with it now
Putting content standards in a revision-tracked CPT with its own REST API turns editorial rules into data that other code can act on. The block-level rules are the practical part: an alt text requirement or a short-sentence preference can apply to one component instead of the whole site. The experiment lives under Gutenberg > Experiments if you want to switch it on, and the tracking issue on GitHub is where the breaking changes turn up.
