Skip to content
WordPress 6 min read Sajid Aslam

WordPress Block Themes and Full Site Editing Explained

Full site editing moved headers, footers and templates into the block editor. Here is what that changes for the people running a business site.

WordPress Site Editor showing templates, template parts and global styles

Short answer

Full site editing lets you edit the whole site, including headers, footers and page templates, in the WordPress block editor. It works with block themes, which define layouts as block templates and design settings in a theme.json file. For business sites it gives editors visual control, while a well-built theme limits what they can break.

WordPress full site editing is the set of features that lets you edit an entire site, not just page content, in the block editor. Headers, footers, archive layouts, the 404 page and global styles all become editable through the Site Editor rather than through theme code or a Customizer panel. It works with block themes, which WordPress introduced in version 5.9 in early 2022, and it has matured with every release since.

For a business, the question is not whether full site editing is clever. It is whether it makes your site easier and safer to run. Usually it does, if the theme is built with guardrails. This article explains how the pieces fit together.

Classic themes vs block themes

A classic theme builds pages with PHP template files. The header and footer live in code. Layout changes need a developer, or a page builder layered on top.

A block theme builds pages from block templates, stored as HTML files containing block markup. The header, footer and every template are made of blocks, so they can be edited visually in the Site Editor. Design settings live in a single configuration file, theme.json.

Classic themeBlock theme
TemplatesPHP filesHTML files of blocks
Header and footerCode, sometimes Customizer optionsEditable template parts
Design settingsCSS and Customizertheme.json and Global Styles
Who can change layoutsDevelopersAdministrators in the Site Editor
Page builder needed for layout controlOftenRarely
Where it is goingSupported, little new developmentWhere WordPress core development is focused

There are also hybrid themes: classic themes that adopt parts of the block system, such as theme.json for design settings or block template parts for headers. These are a sensible migration path for an existing site.

The building blocks of full site editing

theme.json

The theme.json file defines the design system: the colour palette, font families and sizes, spacing scale, layout widths and default styles for each block. It also controls what editors are allowed to change. You can, for example, restrict colours to the brand palette and switch off custom colour pickers entirely.

This is the most useful part of full site editing for a business. A brand colour is defined once, and every button, heading and background that uses it updates together.

Templates and template parts

Templates define layouts for types of content: the single post, the page, the archive, the search results, the 404. Template parts are reusable sections, mainly the header and footer. Both are edited in the Site Editor under Appearance, then Editor.

Patterns

Patterns are pre-designed groups of blocks, such as a hero section, a pricing table or a call-to-action band. Editors insert them and change the text and images. Synced patterns (previously called reusable blocks) update everywhere when edited once, which suits elements such as a contact strip that appears on every service page.

Good patterns are what make a block theme pleasant to use. Instead of building a section from scratch, an editor picks the approved version and fills it in.

Global Styles

Global Styles is the interface for theme.json. Administrators can adjust typography, colours and spacing site-wide without code, and style variations let a theme offer alternative looks.

What this means for the people editing the site

For a typical business site, full site editing changes three things:

  1. Headers and footers stop being developer tasks. Adding a menu item, changing the phone number in the footer or adding a banner is now an editing job.
  2. New page layouts can be assembled from patterns. A new landing page can be built from approved sections without a builder plugin.
  3. The design stays consistent. Because styles come from theme.json, editors are working within the brand rather than choosing colours by eye.

The risk is the mirror image: more power means more to break. An administrator who edits the single-post template by accident changes every blog post at once. That is why I keep template editing to one or two trained people and give everyone else an Editor role, which can change content but not templates.

Block themes and performance

Block themes tend to produce lighter pages than page builders, because WordPress only loads the CSS for blocks that are actually on the page, and the markup is simpler. That is not automatic: a block theme stuffed with third-party block libraries can be as heavy as any builder. But the starting point is better.

Where full site editing still falls short

Being honest about the limits:

  • Complex dynamic layouts that pull together custom fields, filters and conditional logic still need custom blocks or template code. The block bindings feature added in WordPress 6.5 lets core blocks display custom field values, which helps, but it is not a full replacement for custom development.
  • Content stored in templates is easy to lose track of. Text typed directly into a template is not searchable as page content.
  • Changes made in the Site Editor are stored in the database, which means the theme files and the live site can drift apart. A developer needs to export changes back into the theme when they matter.
  • Some plugins still assume a classic theme, particularly older WooCommerce extensions and page-specific tools.

Accessibility in a block theme

Full site editing makes it easier to keep a site accessible and easier to break it. On the helpful side, core blocks produce reasonably semantic markup, the navigation block handles keyboard and mobile menus, and theme.json lets you restrict editors to a colour palette that has been checked for contrast. On the risky side, editors can now pick heading levels, colours and layouts that used to be fixed in code.

The guardrails that matter:

  • define only colour combinations that pass WCAG AA contrast, and remove the custom colour picker
  • build patterns with correct heading levels so editors do not have to choose
  • require alt text on images as part of editor training
  • test templates with a keyboard and a screen reader before handing over

Website accessibility for small businesses covers the wider standard and what UK businesses should aim for.

Should your site use a block theme?

SituationRecommendation
New site, editors want layout controlBlock theme with locked patterns
New site, highly structured content (services, locations, products)Block or hybrid theme with custom post types and fields
Existing classic theme, working wellKeep it; adopt theme.json if refreshing the design
Existing page builder site, slow and hard to maintainConsider a block theme rebuild
Very complex application-like featuresCustom theme or headless, case by case

The structured-content row is worth expanding. A block theme does not replace a proper content model. If you have services, team members or case studies, they should still be custom post types with defined fields, which WordPress custom post types and custom fields explains. Full site editing then controls how they are displayed.

How I build block themes for business sites

  1. Define the brand in theme.json: palette, fonts, spacing, layout widths, with custom colours and font sizes switched off.
  2. Build templates for each content type and a small set of template parts.
  3. Create a pattern library for the sections the business actually uses, and lock the structural ones so the layout cannot be broken.
  4. Set user roles so most editors change content, not templates.
  5. Keep the theme in version control and export Site Editor changes back into it.

That gives editors real control while keeping the site consistent. It is also the approach behind the custom builds described in custom WordPress theme vs premium theme.

Next step

If you are planning a new site or a rebuild and want to know whether a block theme fits, the WordPress development service covers block, hybrid and classic builds, and I will recommend whichever suits how your team edits. The WordPress website development guide covers the other structural decisions that sit alongside the theme choice.

Related services

Related reading

FAQ

Questions about this

If yours isn't here, send it over — I reply within one working day.

No. Classic themes are still fully supported by WordPress and there is no announced end date for them. Switching makes sense when you are rebuilding anyway, or when your editors need to change layouts that a classic theme locks away. Rebuilding a working classic site purely to adopt full site editing is rarely worth the cost.

For many business sites it can be. The block editor now handles layouts, patterns and global styles that used to need a page builder, and it produces lighter pages. Page builders still offer more visual effects and a more familiar drag-and-drop feel. If your site relies on heavy builder features, moving off it is a rebuild rather than a switch.

They can change more than on a classic theme, which includes changing things they should not. A well-built block theme limits this by locking key patterns, restricting colour and font choices to the brand palette in theme.json, and keeping template editing to administrators. Setting those guardrails is part of the build.