A single place in WordPress to capture site-wide content standards and context, so publishing tools can manage content that stays on-brand and consistent.
Summary
We’d like to explore Content Guidelines as a Gutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ experiment. The goal is to give site owners a first-class place in WordPress to capture the rules and context that shape how content should be written, edited, and managed.
A Gutenberg experiment is well-suited for this kind of work:
- It intersects with multiple editor surfaces (post editor, site editor, and potentially admin views)
- It enables early feedback from plugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party and host ecosystems before committing to a stable API An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways., while allowing us to design interfaces that dogfood modern WordPress components, wordpress/build, and other elements
- It de-risks future AI integrations in Core Core is the set of software required to run WordPress. The Core Development Team builds WordPress. by establishing the right foundations now
- It defines a new kind of site-level configuration that doesn’t have a clear precedent in WordPress
Gutenberg experiments let us validate whether this concept belongs in core, how it should be modeled, and where it should live in the admin experience before committing to a long-term API.
The initial PR is up at #75164 (we’ll continue to iterate there), and the tracking issue for broader discussion is at #75171.
Why this matters
Most sites already have content standards: voice and tone, structural rules, image guidance, accessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility) expectations, linking practices, and more. Today, those guidelines often live outside WordPress in documents, PDFs, wikis, or institutional knowledge. That makes them harder to find while writing and harder for any tool, human or automated, to apply consistently.
Content Guidelines isn’t an AI-only feature. It doesn’t depend on AI, but AI should depend on it. A unified store of guidelines makes standards discoverable, portable, and reusable, whether the person applying them is a writer, an editor, a plugin, or an AI assistant.
What Content Guidelines enables
Having a shared, structured store of guidelines creates compounding benefits over time – first for the people and tools already managing content, and increasingly as AI-assisted workflows become part of the publishing process.
A single source of truth for content standards. Today, editorial standards are scattered across wikis, PDFs, onboarding docs, and tribal knowledge. Content Guidelines gives them a canonical home inside WordPress, available at the moment they matter – during writing and editing, not after.
Consistency across authors and tools. On multi-author sites, keeping voice, structure, and formatting consistent is an ongoing challenge. When guidelines are part of the platform, every contributor and every tool works from the same expectations.
More steerable AI behavior. When AI-powered features can reference a site’s actual standards – voice and tone, preferred terminology, accessibility requirements, structural constraints – the results are site-specific rather than generic, with less need for repeated prompting or manual correction.
Guardrails for agents. As WordPress evolves to support and enable autonomous agents that act on behalf of a digital presence, (handling customer interactions, managing commerce workflows, moderating content) those agents need to understand the site’s voice, boundaries, and standards. Content Guidelines keeps public-facing agents aligned with a site’s brand and expectations, even without human review of every action.
A shared, portable foundation across the ecosystem. A consistent source of truth makes it easier for multiple features – whether core, host, or plugin – to behave coherently without creating conflicting rules across separate settings panels. With import and export, guidelines can move with a site, be reused across environments, or serve as a starting point for new sites.
What this experiment includes
The experiment focuses on establishing the foundation needed to make guidelines broadly useful:
- A UI UI is an acronym for User Interface - the layout of the page the user interacts with. Think ‘how are they doing that’ and less about what they are doing. for defining site-wide content guidelines and context
- Support for content guidelines at a global and optionally at a more granular level
- Storage that can evolve over time, including basic revision history
- A way for tools to retrieve guidelines reliably
The initial emphasis is on capturing and retrieving guidelines. AI-driven experiences like generation, review, and enforcement, which exist in AI Experiments, can build on top of that shared foundation.
How to follow along and share feedback
If you’d like to track progress or contribute feedback and use cases, the tracking issue is the best place to start: #75171.
The most helpful feedback right now is practical:
- What content standards would you want tools to consistently follow?
- Where do those guidelines live today?
- What schema and fields should we land on?
- Which workflows matter most: drafting, editing, rewriting, translation, image generation, review?
- What would make this immediately useful on day one?
Kudos to @matveb for reviewing this post.