WordPress Block Themes and Full Site Editing: Ready for Client Sites?

For most of WordPress's life, the theme was code and the content was content. Editors wrote posts; developers owned the header, the footer and every template. Block themes blur that line on purpose. The whole site, from headers and footers to archive layouts and the 404 page, becomes editable in the browser. Depending on how it is set up, that is either a big step forward or a disaster waiting for an enthusiastic intern. I have shipped enough block theme builds to have firm views on when they are ready for client work.

What a block theme actually is

A classic theme is a set of PHP templates: header.php, single.php, footer.php, with the design baked into code. A block theme replaces those with HTML files made of block markup, stored in a templates folder, with shared pieces such as the header and footer in a parts folder. Those files are the defaults. Once someone edits a template in the Site Editor, the customised version is saved to the database and takes over.

Four pieces do most of the work:

• The Site Editor (Appearance → Editor), where templates, template parts, styles and navigation are edited visually.
• theme.json, one configuration file for colour palettes, font sizes, spacing scales, layout widths and which design controls editors are allowed to touch.
• Patterns, pre-built groups of blocks (a pricing row, a testimonial strip) that editors insert and fill in.
• Template parts, named regions like the header and footer, shared across every template that uses them.

theme.json is the part that matters most

If you only take one idea from block themes, take this one. theme.json turns your design system into data. Instead of scattering brand colours across stylesheets and hoping editors pick the right shade, you declare the palette once and WordPress generates the CSS custom properties and the editor controls from it. You can also switch off the controls that cause brand drift.

{
  "version": 3,
  "settings": {
    "color": {
      "custom": false,
      "customGradient": false,
      "palette": [
        { "slug": "brand", "color": "#0b3d91", "name": "Brand" },
        { "slug": "ink", "color": "#111111", "name": "Ink" }
      ]
    },
    "typography": { "customFontSize": false }
  }
}

With custom colours and custom font sizes switched off, an editor can pick from your palette and your type scale and nothing else. That single file does more for brand consistency than any style guide PDF. It is the WordPress answer to the problem I described in how generic themes quietly damage your brand: fewer choices, well made.

Patterns, synced patterns and template parts

Patterns are where block themes start to pay off for clients. A regular pattern is a starting point: insert it, and the blocks become independent copies the editor can change freely. A synced pattern (what WordPress used to call a reusable block) is one source of truth: edit it once and every page using it updates. That is ideal for a contact strip, a legal disclaimer or an opening-hours block that appears in a dozen places.

Template parts do the same job at the layout level. Change the header part and the header changes everywhere. The rule I give clients: patterns are for content sections, template parts are for site structure, and only a small number of people should be able to edit either.

Themes can ship patterns as PHP files in a patterns folder, registered automatically from a header comment. That means your section library lives in version control, not only in someone's database.

Locking things down for editors

This is the part that decides whether a block theme survives contact with a real team. Out of the box, anyone with the right role can move, delete or restyle almost anything. On client sites I lock things deliberately:

• Content-only locking. Wrapping a pattern in a Group block with "templateLock":"contentOnly" lets editors change the text and images but not the structure. They get the fields they need; the layout stays intact.
• Block-level locks. The lock attribute stops individual blocks being moved or removed, which is useful for a hero or a legally required notice.
• Restricted design controls. theme.json switches off custom colours, font sizes and spacing values, so "just make it a bit bigger" is not an option.
• Roles. The Site Editor needs the edit_theme_options capability, which by default only administrators have. Keep it that way. Editors edit pages; administrators edit the site.

Get this right and you end up with something close to what I build on Shopify with custom sections a team can actually edit: freedom inside guard rails.

Block themes vs classic themes vs page builders

	Classic theme	Block theme	Page builder (Elementor etc.)
Where layout lives	PHP templates in code	HTML templates and theme.json	The builder's own data format
Editing	Content only; layout needs a developer	Visual editing of the whole site	Drag-and-drop everything
Front-end weight	Depends on the theme	Lean; core block CSS loads only when used	Usually heavier, with extra CSS and JS on every page
Brand control	Strong, but only through code	Strong, via theme.json and locking	Weak unless heavily configured
Lock-in	Low	Low; it is core WordPress	High; content is tied to the builder

The lock-in row is the one that matters commercially. I still inherit plenty of page builder sites. They are quick to build and hard to leave: turn the builder off and pages either fall apart into unstyled fragments or fill with shortcodes, depending on the builder. Block themes give editors most of the visual control that made builders popular, using core WordPress, so there is nothing to migrate away from later.

The performance case

Block themes are not automatically fast, but they start from a better place. In a block theme, WordPress loads the stylesheet for each core block only when that block appears on the page, instead of one large stylesheet for everything. There is no builder framework to load and far fewer wrapper divs.

On the rebuilds I have done, moving from a page builder to a block theme is usually the biggest single improvement, larger than any caching plugin. It will not fix a slow host or twenty heavy plugins, which is why I pair a rebuild with a look at the usual WordPress speed culprits and a proper plugin audit. Less JavaScript on the page also helps interaction responsiveness, which is where most sites now fall down on INP.

When block themes are ready for client sites

• Marketing and brochure sites where the team edits landing pages regularly.
• Content-led sites and blogs where consistent templates matter more than one-off layouts.
• New builds, where you can design the pattern library from day one.
• Teams moving off a page builder who want visual editing without the lock-in.

When I would still hold back

• Heavy WooCommerce customisation that depends on classic template overrides and plugin hooks. Support is improving, but test every extension you rely on first.
• Plugins that assume a classic theme, particularly older membership, course or directory plugins that inject their own templates.
• Complex, app-like front ends. If the site behaves like an application, WordPress may be better as a content back end. The trade-offs are in headless WordPress with Next.js.
• Teams with no appetite for governance. If nobody will own the locking and roles, the flexibility turns into drift.

There is also a middle road: a classic theme can adopt theme.json and patterns without going fully block-based. For an established site that works, that is often the sensible first step.

How I build them

I start from a minimal starter rather than a feature-packed commercial theme, define the design tokens in theme.json first, build a small pattern library for the sections the client actually needs, lock those patterns to content-only, and keep all templates and patterns in Git so the database copy is never the only copy. Then I hand over a short guide explaining what editors can change and what they should ask about.

After launch it goes into the same routine as any site in my website maintenance guide. Templates customised in the database need checking against theme updates so nothing silently falls out of step.

Weighing up a block theme, or stuck with a page builder you want to leave? Tell me about your site and I will tell you honestly whether a rebuild is worth it.