What is WordPress Full Site Editing?

WordPress Full Site Editing (FSE) is a design and development system built directly into WordPress core. It lets you build and customise every structural part of your website using the same block-based editor you already use to write posts. Headers, footers, templates, global colour palettes, typography: all of it, one interface.

FSE arrived with WordPress 5.9 in January 2022 and has been expanding steadily with every major release since. The core idea was to replace the patchwork of theme customisers, widget areas, and PHP template files that had accumulated over WordPress’s two-decade history with a single, unified visual environment called the Site Editor.

It didn’t happen overnight, and it isn’t finished yet. We’ve been working with FSE since its earliest releases here at WP Custom Themes, and our honest assessment is this: it’s far enough along that any serious WordPress project started today should be evaluated against it.

How WordPress Full Site Editing Works

FSE isn’t a plugin you install. It’s a native capability of WordPress that activates when you’re running a block theme. Classic themes, including older versions of Twenty Twenty or third-party themes that predate 5.9, don’t unlock the Site Editor. That’s the first thing to understand, and it’s the source of most of the confused support questions we see from clients who’ve just upgraded WordPress and can’t find the Editor menu.

Here’s how the system works end to end.

Step 1: Install a block theme

The WordPress Theme Directory flags FSE-compatible themes clearly. Purpose-built block themes that require nothing extra to function include Twenty Twenty-Four, Ollie, Spectra One, and Blocksy. For service businesses and e-commerce brands, we built Sophia Lite: a multipurpose block theme designed for health, beauty, wellness, retail, and professional services, with five style variations included out of the box. When you activate a block theme, the Appearance menu in wp-admin replaces the old Customise and Widgets links with a single item: Editor.

Step 2: Open the Site Editor

Navigate to Appearance > Editor. You’ll see a canvas rendering your site’s current front-end appearance, with a left-hand navigation panel listing Templates, Patterns, and Style options.

Step 3: Edit a template

Templates are the structural wrappers around your content. The Single Post template controls what surrounds every individual blog post: the header block, post title, featured image, content area, and footer. Click any element on the canvas to select and edit it. Changes here propagate to every page using that template.

Step 4: Adjust Global Styles

The Styles panel (the half-circle icon in the top-right toolbar) controls site-wide typography, colour palettes, button styles, and spacing. Change the heading font once and it updates across the entire site. No CSS editing required for most adjustments.

Step 5: Save

Saving in the Site Editor writes your changes to the database as block markup. Unlike classic theme files, you don’t need FTP or a child theme to preserve changes. They survive theme updates automatically.

The Key Components of FSE

The Site Editor

This is the top-level interface: the canvas where you assemble and edit every structural element of your site. Think of it as a Figma-like environment built into WordPress, except changes publish directly to your live site rather than staying in a design file.

When we first started using the Site Editor with client projects, the most immediate shift was how much less context-switching the work involved. Previously, a single homepage redesign meant bouncing between the post editor, the Customiser, and a page builder. In the Site Editor, that same work stays in one place from start to finish.

Block Templates

Templates define the layout skeleton for different page types: Homepage, Single Post, Archive, 404, Search Results, and so on. Each template is made entirely of blocks. There are no PHP template files to hunt down.

A news site can create a custom “Breaking News” template with a bold banner block at the top and assign it to any post tagged “breaking.” Every such post automatically inherits the layout without editorial staff touching the template again. We’ve set up exactly this kind of arrangement for content-heavy clients who need editorial flexibility without ongoing developer involvement.

Template Parts

Template Parts are reusable sections that appear across multiple templates. The Header and Footer are the canonical examples. Edit the Header template part once and the change propagates to every template that includes it.

In our experience, this is where FSE delivers its most immediate practical value. An e-commerce client running a promotional sale can add a free-shipping announcement bar to the Header template part and have it live across every page of their site in under two minutes. No developer call required.

Global Styles

Global Styles is a design-token system controlled through theme.json at the theme level and the Styles panel in the UI. It governs typography, colour palette, spacing scale, border radius, and element-specific styles for buttons, links, and headings.

When we built Sophia Lite, defining the full colour palette and type scale in theme.json before touching a single template saved us significant rework downstream. A brand that later refreshes its primary colour opens Global Styles, changes one swatch, and every button, link highlight, and accent across the entire site updates instantly.

Block Patterns

Patterns are pre-designed, reusable block arrangements: layout snippets ranging from a simple hero section to a complete pricing table. They can be saved from the Site Editor, shared via the WordPress Pattern Directory, or bundled inside a theme.

We ship a library of patterns with Sophia Lite specifically so clients in service-based industries can build polished pages without starting from a blank canvas. A beauty salon owner can drop in a pre-built services grid or a testimonial row and have something that looks professionally designed from the first click.

The Navigation Block

A dedicated block for building menus, replacing the old Menus screen under Appearance. It supports nested menus, mobile hamburger toggles, and icon buttons. Membership sites often use it in combination with a third-party visibility plugin to show different menu items to logged-in versus logged-out visitors.

Who Uses WordPress FSE? Five Real-World Use Cases

Freelance web designers who previously relied on Elementor or Divi now have a native alternative. FSE lets them build bespoke sites without licensing a page builder. When the site hands back to the client, there’s one less plugin that could accidentally get deactivated. We hear this concern regularly from freelancers who’ve had clients inadvertently break a layout by letting a page builder licence lapse.

Digital agencies managing Multisite installations use block themes with shared template parts and patterns across all child sites. One update to a Header template part can roll out to a network of franchise websites simultaneously. For agencies managing ten or more sites under one roof, that kind of centralised control changes the economics of ongoing maintenance.

Publishers and media outlets benefit from custom templates for different content types: standard article, photo essay, long-form feature, sponsored content. Editorial teams can create and assign templates without pulling in a developer. We’ve found this particularly valuable for clients with small in-house teams who need to move quickly on new content formats.

WooCommerce store owners gained meaningful FSE integration when WooCommerce 8.3 shipped in November 2023, making block-based Cart and Checkout pages the default experience for new stores. We’ve worked with several WooCommerce clients since that release, and the ability to redesign product listing layouts visually, without touching PHP or spinning up a child theme, has meaningfully shortened project timelines.

Theme developers building for resale use FSE’s theme.json architecture to ship themes that are lighter, faster, and more customisable by end users than classic themes. Building Sophia Lite gave us a direct understanding of this tradeoff: a single well-structured theme.json file replaced what would have been hundreds of lines of CSS in a classic theme, and the result is a codebase that’s far easier to maintain and extend.

Why FSE Matters: The Core Benefits

One editor for everything. Before FSE, a typical WordPress workflow split design work across three or four separate screens: the post editor, the Customiser, the Widgets screen, and the Menus screen. FSE consolidates this into one interface. We’ve watched clients who previously needed a walkthrough for every small change navigate the Site Editor confidently after a single onboarding session.

No child theme required to customise. Historically, editing a theme’s header.php directly meant those changes were wiped on the next theme update. FSE writes Site Editor changes to the database, so they survive updates cleanly.

Faster iteration. Because changes are visual and live on the canvas, designers can prototype layouts faster than editing PHP or CSS by hand. A header redesign that used to take an hour of file editing and browser refreshing can be done in minutes.

Smaller performance footprint. Block themes ship with significantly less CSS than many classic themes and page builder combinations. A leaner stylesheet frequently translates to better Core Web Vitals scores, which matters for both user experience and search rankings.

Lower long-term costs for clients. Clients who understand blocks can make layout changes themselves without calling a developer for every minor tweak. For agencies, that reduces support burden. For clients, it reduces ongoing spend.

Risks and Limitations Worth Knowing

FSE isn’t a universal upgrade switch. We’ve run into enough friction points with real client projects to say this plainly rather than gloss over it.

Steep learning curve for classic-theme veterans. Developers who spent years working with PHP template files, get_header(), wp_nav_menus(), and widget areas face a significant mental model shift. The conventions FSE replaces have been stable since WordPress 2.x, and that’s a long muscle memory to retrain. Our own team felt this when we first moved serious client work into the Site Editor.

Plugin compatibility gaps. Not every WordPress plugin is block-editor aware. Plugins that inject content via shortcodes, widget hooks (dynamic_sidebar), or the classic Customiser may not behave predictably inside block templates. Always audit plugins before migrating a production site to a block theme. We treat this step as non-negotiable before any FSE migration we take on.

The template editor is still maturing. As of WordPress 6.x, some advanced use cases (conditional template logic, user-role-based template parts, complex query loops) require either custom PHP blocks or third-party plugins. The Site Editor doesn’t yet replace everything a developer could do in PHP.

Difficult to revert a migration. Switching a site from a classic theme to a block theme isn’t trivially reversible. Widget data, Customiser settings, and menu configurations don’t transfer automatically. If you go in, go in with eyes open.

Limited design expression without code. Global Styles covers most design tokens, but complex animations, micro-interactions, and highly bespoke layouts still require custom CSS or JavaScript. FSE isn’t a full no-code solution for sophisticated designs, and we’re upfront with clients about that boundary.

Frequently Asked Questions about FSE

Is WordPress Full Site Editing replacing the Classic Editor?

Not exactly. The Classic Editor plugin and the classic block inside Gutenberg still work for writing post content. FSE is specifically about editing site structure: headers, footers, and templates, not post content. That said, both the post editor and the Site Editor run on the same Gutenberg block engine, so they share the same interaction model and keyboard shortcuts.

Do I need to use a block theme for WordPress Full Site Editing?

Yes. FSE features (the Site Editor, Global Styles, block templates) are only available when a block theme is active. If your current theme is a classic theme, you won’t see the Appearance > Editor menu item. The WordPress Theme Directory’s “Full Site Editing” filter shows compatible themes.

Can I still use page builders like Elementor with FSE?

You can, but it creates friction. Elementor has its own template system that runs parallel to and sometimes conflicts with FSE’s block templates. Using both simultaneously isn’t recommended. Our advice to clients is straightforward: pick one paradigm for a given site and commit to it.

Will switching to a block theme break my existing website?

It can. Classic theme features (widgetised sidebars, Customiser settings, nav menus registered via register_nav_menus()) don’t carry over automatically. We always rebuild templates on a staging environment first, run a thorough visual check, and deploy only once everything is confirmed. Don’t switch themes on a live production site without that step.

What is theme.json in WordPress FSE?

theme.json is a configuration file in the root of a block theme that defines the site’s default design tokens: colour palette, font families, type scale, spacing scale, and which block-level settings users can control. It’s the architectural backbone of FSE. When we developed Sophia Lite, getting theme.json right early was the single decision that made everything else easier. A well-structured theme.json lets a developer lock down a client’s design system while still allowing safe, self-service customisation through the Styles panel.

Best Practices for WordPress Full Site Editing

Start with a purpose-built block theme, not a converted classic theme

Some theme developers have bolted FSE compatibility onto classic themes, producing hybrid themes that behave unpredictably. Start clean with a theme designed for FSE from the ground up, where block patterns, style variations, and theme.json are built in from day one rather than retrofitted. It’s the approach we took with Sophia Lite and the one we recommend to every client considering FSE.

Define your Global Styles before building templates. Set your colour palette, typography, and spacing in theme.json and the Styles panel before you touch a single template. This ensures design consistency and makes future brand updates a one-step operation.

Use template parts aggressively. Any element that appears on more than one template (site header, footer, sidebar, announcement bar) belongs in a template part. This is the FSE equivalent of the DRY (Don’t Repeat Yourself) principle, and it’s the habit that separates clean FSE builds from messy ones in our experience.

Audit your plugins before migrating. Run through every active plugin and confirm it works inside the block editor without relying on widget hooks or the Customiser. Plugins that inject content via the_content filters generally work fine. Those that register widget areas may not.

Stage migrations, never do them live. Use a staging environment to rebuild your site’s templates in FSE. Use a visual regression tool or screenshot comparison to confirm nothing broke before pushing to production. Most managed WordPress hosts provide staging environments as standard, and we use them without exception on every migration we handle.

Keep custom CSS minimal and documented. When you do need to write CSS beyond Global Styles, add it in small, targeted blocks via the Additional CSS panel or a custom stylesheet, and leave comments explaining why it exists. FSE is designed to reduce CSS dependency, so resist the urge to port your old stylesheet wholesale.

Version-control your theme.json and template files. If you’re developing a custom block theme, commit theme.json and the /templates directory to Git. Unlike database-stored content, these files are portable, reviewable, and recoverable.

Where WordPress FSE Is Heading

The Gutenberg project roadmap has expanded FSE capabilities with each major release, and the pace has been consistent. WordPress 6.5 introduced the Font Library (a UI for managing custom fonts inside the Site Editor without touching code) alongside the Block Bindings API, which lets block attributes connect directly to custom fields or other data sources. A heading block can now pull its content dynamically from post metadata without a developer writing a custom block from scratch.

The trajectory is clear. Over the next several major versions, FSE is expected to absorb more of the functionality currently handled by page builders, custom field plugins, and theme frameworks. We’re already building new client projects with that direction in mind, and we’d encourage any agency or developer still sitting on the fence to start getting hands-on time with the Site Editor now rather than later.

If you’re evaluating FSE for a new project, install Twenty Twenty-Four or Sophia Lite on a staging site and spend an hour in the Site Editor. Build a custom header template part, adjust Global Styles, and create one block pattern. That hands-on hour will tell you more about where FSE stands today than any documentation, including this one.