WordPress Full Site Editing (FSE) is the biggest architectural shift in WordPress in a decade. Introduced in WordPress 5.9 (January 2022) as part of the Gutenberg Phase 2 roadmap, FSE replaced the classic Customizer, the Widgets screen, and PHP template files with a unified, block-based Site Editor. Every part of your site — header, footer, sidebar, archive pages, 404 — is now editable visually, without touching code.
This guide covers how FSE actually works: the four pillars that every block theme is built on, what changed from the classic WordPress approach, and why block themes consistently outperform page-builder sites on Core Web Vitals.
What Changed: FSE vs. Classic WordPress
In a classic WordPress theme, your site’s structure is controlled by PHP template files: header.php, footer.php, index.php, single.php, archive.php. Visual design settings live in style.css, widget areas are registered in functions.php, and global options live in the Customizer. Making a site-wide layout change requires editing PHP files or navigating multiple separate admin screens.
Full Site Editing replaces all of this with four components that work together:
- theme.json — a single JSON file that defines your design system: colors, typography, spacing, and per-block defaults
- HTML templates — block markup files (
single.html,archive.html, etc.) that replace the old PHP template files - Template parts — reusable components (header, footer) used across multiple templates
- Global Styles — the visual design panel in the Site Editor that lets you override theme.json settings without touching files
The practical difference: in a block theme, the entire site is editable from a single interface — the Site Editor (wp-admin → Appearance → Editor). There’s no separate Widgets screen, no Customizer, no PHP to edit for layout changes.
theme.json: The Brain of a Block Theme
The most important file in any block theme is theme.json. It replaces what previously required dozens of add_theme_support() calls in functions.php and hundreds of lines of CSS.
A minimal theme.json defines three sections:
{
"$schema": "https://schemas.wp.org/trunk/theme.json",
"version": 3,
"settings": {
"color": {
"palette": [
{ "slug": "primary", "color": "#059669", "name": "Primary" },
{ "slug": "background", "color": "#ffffff", "name": "Background" }
]
},
"typography": {
"fontSizes": [
{ "slug": "small", "size": "0.875rem", "name": "Small" },
{ "slug": "medium", "size": "1rem", "name": "Medium" }
]
},
"spacing": {
"units": ["px", "em", "rem", "%"]
}
},
"styles": {
"color": { "background": "var(--wp--preset--color--background)" },
"typography": { "fontSize": "var(--wp--preset--font-size--medium)" },
"blocks": {
"core/button": {
"border": { "radius": "4px" }
}
}
}
}The settings section defines what options are available in the editor — which colors, font sizes, and spacing units an editor can choose from. The styles section defines the defaults — what those blocks actually look like before anyone changes anything. The blocks sub-key lets you set per-block defaults: all buttons get a 4px border-radius, all separators are a specific color, and so on — without a single line of CSS.
WordPress converts every settings.color.palette entry into a CSS custom property (--wp--preset--color--primary) that’s available to all blocks. This gives you a true design token system built into core WordPress.
For a deep dive into building a complete block theme from these foundations, the guide to high-performance block themes in WordPress 6.5+ covers the full directory structure, how block.json controls per-block asset loading, and performance optimisations specific to FSE-built sites.
Templates and Template Parts
Block theme templates live in the /templates/ directory as HTML files containing block markup. WordPress maps filenames to template hierarchy entries exactly as it did with PHP files:
index.html— fallback for all viewssingle.html— individual post viewpage.html— individual page viewarchive.html— post archive, category, tagfront-page.html— homepage (takes priority over index.html)404.html— not-found pagesearch.html— search results
A minimal single.html looks like this:
<!-- wp:template-part {"slug":"header","tagName":"header"} /-->
<main>
<!-- wp:group {"tagName":"article"} -->
<div class="wp-block-group">
<!-- wp:post-title {"level":1} /-->
<!-- wp:post-content /-->
</div>
<!-- /wp:group -->
</main>
<!-- wp:template-part {"slug":"footer","tagName":"footer"} /-->Template parts live in the /parts/ directory. header.html and footer.html are the standard entries — they’re referenced by multiple templates via wp:template-part block comments. Change the header template part once, and every template that includes it updates automatically.
Both templates and template parts are editable in the Site Editor without touching files. Any edits made in the editor are stored in the database as post-type entries (wp_template and wp_template_part), which take precedence over the theme files. You can revert to the file-level defaults at any time via the editor’s Reset option.
For advanced layout composition inside templates — reusable block sets and nested block containers — block patterns and InnerBlocks give you the tools to build scalable layouts without duplicating markup across templates.
Global Styles: The Visual Design System
Global Styles is the Site Editor’s design panel, accessible via the paintbrush icon in the top-right corner. It exposes everything defined in theme.json as a visual interface — color palettes, typography scale, spacing, and per-block overrides — without requiring any code changes.
WordPress 6.0 introduced Style Variations: complete alternative design schemes bundled with the theme as additional theme.json files in a /styles/ directory. A single theme can ship with a “dark” variant, a “high-contrast” variant, and a “pastel” variant — each one a different JSON file — and users can switch between them from the Global Styles panel in one click.
Global Styles also introduced per-block typography and color customisation without needing Additional CSS. Every block type has its own panel under Styles → Blocks where you can set the default text color, background, font size, and spacing for that block type across the entire site.
The Site Editor Interface
The Site Editor (wp-admin → Appearance → Editor) consolidates what previously required four separate admin screens:
- Navigation — replaces the Appearance → Menus screen; menus are now Navigation blocks editable in the editor
- Styles — replaces the Customizer; all design settings live here
- Pages — browse and edit pages directly in the Site Editor canvas
- Templates — edit the structural layouts for posts, archives, and pages
- Template Parts — edit the header, footer, and any reusable structural components
- Patterns — manage reusable block groups (synced or unsynced)
Every change made in the Site Editor is live-previewed on the canvas before saving. Template and Global Style changes affect the entire site; page edits affect only that page.
FSE vs. Page Builders: The Performance Case
The performance argument for FSE over page builders like Elementor or Divi comes down to how CSS is loaded. Classic themes and page builders load their full CSS bundle on every page, regardless of which features are actually used on that page. A site using Elementor loads Elementor’s entire stylesheet on every page, even on pages that only contain a heading and a paragraph.
Block themes load only the styles for blocks actually present on the page. This is controlled by each block’s block.json file, which declares its style and editorStyle assets — WordPress enqueues them only when that block is rendered. A page with only a paragraph, heading, and image loads three small stylesheets; a page with a query loop and a cover block loads those block’s stylesheets and nothing else.
The practical result: block theme sites regularly score in the 95–100 range on Google Lighthouse performance without aggressive optimisation, because the baseline CSS footprint starts small. Page builder sites typically need additional optimisation work to reach the same scores. The Core Web Vitals guide covers how LCP and INP scores differ between block-theme and page-builder architectures.
For a detailed comparison of when a page builder makes sense vs. when a hand-coded block theme is the right choice, page builders vs. custom code covers the trade-offs in depth — including the maintenance cost difference over time.
FSE and SEO
Block themes produce cleaner markup than classic themes or page builders for three structural reasons:
No div soup. Page builders wrap content in multiple layers of <div> containers for their layout systems. Block themes output semantic HTML — a Group block renders as a <div> only when needed, and template parts use their tagName attribute to output <header>, <footer>, and <main> directly. Googlebot crawls semantic HTML more efficiently than deeply nested generic containers.
Native INP handling. WordPress’s Interactivity API handles dynamic UI interactions in block themes without loading jQuery. Since Interaction to Next Paint (INP) measures responsiveness to user input, eliminating a 40KB jQuery dependency improves INP scores directly.
Core Web Vitals baseline. The per-block CSS loading model means Largest Contentful Paint (LCP) benefits automatically from a reduced render-blocking stylesheet count. Block themes don’t need the level of manual stylesheet deferral that page-builder sites require to pass Core Web Vitals.
How to Start Building with FSE
The quickest way to get hands-on with FSE is to activate a block theme. WordPress ships with block themes — Twenty Twenty-Four and Twenty Twenty-Five are both block themes, and both are well-documented. Third-party block themes like Frost, Ollie, and Kadence Blocks also demonstrate the full FSE feature set.
From there:
- Open Appearance → Editor to explore the Site Editor canvas
- Go to Styles (paintbrush icon) to see Global Styles and any Style Variations
- Open Templates to inspect how
single.htmlandfront-page.htmlare structured - Edit a Template Part to see how header and footer changes propagate sitewide
- Check
theme.jsonin the theme files to understand where the palette and typography scale come from
For building a custom block theme from scratch — registering a theme.json, writing your first templates, and structuring template parts — the custom theme development guide walks through the complete process. Building your own Gutenberg blocks to use inside FSE templates is covered in the custom block development guide.
If you’re migrating an existing site from a classic theme or a page builder to a block theme and want to avoid the common layout regression issues, the custom theme development service covers the full conversion — rebuilding your existing design as a hand-coded block theme with proper template hierarchy, theme.json design tokens, and no legacy page builder dependencies.
