Most teams treat WordPress as the output layer: design lives in Figma, content rules live in a Google Doc, and the CMS is where everything gets poured in at the end. That works until you add AI into the workflow, or until your editor asks why the homepage hero doesn’t match the brand guidelines they swear they followed.
The alternative—raised in a recent WP Tavern conversation with Brian Coords from Automattic—is to flip the model: make WordPress the source of truth for patterns, content guidelines, and design tokens. Store them in the block editor, in custom fields, or as reusable patterns. Let AI tools, editorial workflows, and even external frontends pull from that single canonical source instead of hunting across Figma, Notion, and a scattered Google Drive.
This isn’t a universal prescription. If you’re running headless with a design system already versioned in Storybook and consumed by three platforms, adding WordPress as another source creates more friction than it solves. But if you’re a fractional team shipping a block theme or a lightly headless site, and your client’s editors are the ones who need to maintain consistency without a dedicated design ops person, this approach can collapse a lot of expensive coordination overhead.
When WordPress should own the system
Three conditions make this model worth the setup cost:
- Your editors are the maintainers. If the people updating content are also the ones who need to enforce brand rules, storing those rules in the CMS means they don’t need to context-switch to Figma or ask a designer for the latest hex code.
- You’re using AI to generate or suggest content. AI tools work better when they can reference structured guidelines in the same system where the output will live. A pattern library in WordPress becomes a training set; a content guideline stored as a custom post type becomes a prompt constraint. Coords points out that this tight loop—where the site itself tells the AI what’s allowed—reduces the drift between what gets generated and what’s actually usable.
- You’re not managing a multi-platform design system. If this WordPress site is the product, not one of five surfaces pulling from a shared token repo, then WordPress can be the system. You’re not fighting to keep it in sync with iOS, Android, and a React web app.
What you store and how
The mechanics are simpler than the philosophy. You’re using WordPress features that already exist:
- Reusable block patterns for layout and content modules. These become the canonical versions; editors compose from them, AI references them when generating new pages.
- Custom post types or custom fields for content guidelines (tone, structure, required sections). An AI prompt can pull from a “Content Rules” CPT before drafting a post.
- Global styles and theme.json for design tokens (colors, typography, spacing). If you’re on a block theme, this is already your source of truth for the frontend. Extend it to be the source for any tooling that needs to know what “brand blue” is.
The trade-off is that you’re now maintaining these in WordPress, which means version control is less elegant than a Git repo, and non-technical stakeholders need editor access to change a color or a pattern. That’s a feature if your client is hands-on; it’s a liability if they’re not.
When this doesn’t work
If you’re running headless and your Next.js frontend has its own component library, duplicating design tokens in WordPress creates a sync problem you don’t need. In that case, the design system should live in code (Storybook, a tokens package, whatever), and WordPress is just a content API. You might still store content guidelines in WordPress as structured data, but the visual design system stays in the frontend repo.
Similarly, if your team already has a mature design ops workflow—designers version everything in Figma, engineers pull tokens via a plugin, and that process works—adding WordPress as another source is solving a problem you don’t have. This model is for teams where the CMS is already the collaboration surface and adding another tool would be overhead, not clarity.
Why this matters for fractional work
When you’re the only senior engineer and your client doesn’t have a design team on retainer, every external dependency is a coordination tax. If the brand guidelines live in a Figma file the client can’t edit, and the content rules live in a Notion doc that’s six months out of date, you spend more time reconciling sources than building features.
Centralizing that in WordPress—where the client already has access, where the content already lives, where the AI tools you’re experimenting with can hook in—means fewer places to check, fewer handoffs, and a clearer answer when someone asks, “What’s the current rule for hero images?” The site is the source of truth, and everyone’s looking at the same site.
Key takeaways
- Storing patterns, content guidelines, and design tokens in WordPress itself creates a single source of truth that editors, AI tools, and developers can all reference—eliminating drift between what’s documented and what’s live.
- This approach works best when your editors are the maintainers, when you’re using AI to generate content, and when WordPress is the product rather than one surface in a multi-platform design system.
- If you’re running headless with a mature frontend component library, or if your team already has a working design ops process, adding WordPress as another source creates more sync overhead than it solves.
