What Full Site Editing changes in WordPress development

Full Site Editing is a core WordPress capability, not a plugin: it extends block editing beyond post content to the entire site, header, footer, templates, and global styles, all built and edited as blocks in one interface. Before it, content lived in the block editor while structure and layout lived in separate PHP theme files, two different systems a developer had to keep in sync by hand.

What actually changed under the hood

The block is the single unit everything is built from. A paragraph is a block. An image is a block. A header, a footer, an entire template, even the page layout itself, all the same underlying unit, just composed at different scales. That’s the actual shift: earlier WordPress had one system for editing content (blocks) and a separate one for defining structure (PHP template files). Full Site Editing collapses that into one consistent model, which is what makes everything below possible.

• Templates are HTML files, not PHP files. A block theme defines each template (single post, archive, 404) as block markup rather than a single.php or 404.php file. WordPress still falls back through the same hierarchy it always has, single template, then a general one, then the site default, just reading a different file format.
• Template parts are reusable structural pieces, a header or footer, edited once in the Site Editor and used everywhere that template part appears, rather than duplicated across separate theme files.
• Synced patterns (formerly called reusable blocks) update everywhere they’re used the moment the original is edited, the same reuse principle a component library applies to design, just built into WordPress core.
• theme.json is the site’s single style definition, colors, typography, and spacing declared once and referenced by the editor and every block, rather than scattered across a theme’s CSS and separate customizer settings.

The real benefits

• Structural changes no longer require touching PHP or a developer. A header, footer, or template can be edited in the same interface as page content, which means a genuine site-wide change is a content-editor task, not a code deployment.
• Global styles behave like a single source of truth. Since colors, type, and spacing are declared once in theme.json, a brand color change is one edit instead of a search through a theme’s CSS files.
• A page only loads the CSS for the blocks actually used on it, rather than a theme’s entire stylesheet loading regardless of what’s on the page, since block styles are generated per-block rather than bundled as one file for everything.
• Content and structure aren’t locked into a proprietary format. A block theme’s templates are plain block markup and JSON, portable and readable outside any single plugin’s system, which matters if the site ever needs to move platforms or maintainers.

Where this leaves new and existing projects

For a new WordPress project, there’s no real reason to start anywhere else: a block theme is the direction WordPress itself is building toward, and starting there means building on the architecture the whole ecosystem is converging on. Novembit builds new WordPress sites on block themes by default now.

For an existing site, moving to a block theme is a genuinely achievable project, not a rebuild from zero: an existing site’s templates and content already have a clear structure, and that structure maps directly onto the block model. The result is a site your own team can update directly through the editor, without a developer, and one that loads faster by default, since a page only serves the CSS for the blocks actually on it, not a full theme stylesheet.

Where AI actually helps

We use AI (Claude Code) directly in this workflow to streamline exactly this kind of migration. It reads an existing site’s classic PHP templates and page content and drafts the equivalent block markup, template parts, and a starting theme.json extracted from the site’s existing styles, giving us a working first version of the new structure instead of building every template by hand from a blank editor.

We still review and refine that draft ourselves: matching a brand’s specific design details, deciding how content should be organized into template parts, and confirming the result actually looks and behaves like the original site are calls a person makes. AI turns the migration into a review-and-refine process rather than a from-scratch rebuild, which is what makes moving an existing site to a block theme a genuinely practical option rather than a project to keep postponing.