WordPress Full Site Editing Is Doomed. Bandaid or Genuine Step Forward?

Full Site Editing was announced as the inflection point. The moment WordPress would stop being a blogging engine bolted to a theme system and become a real visual builder. A unified editor for every pixel — headers, footers, templates, queries, archives, the lot — all driven by blocks, all stored as structured content, all editable by anyone with a mouse. The press release wrote itself. The future was Gutenberg, and Gutenberg was the future.

That was 2021. We are now five years in. The future has arrived, looked around, and quietly let itself out the back door. FSE is shipped. FSE is documented. FSE is, technically, the default. And almost nobody who builds WordPress for a living uses it on a real client project unless they have been physically restrained.

This is not a hot take. This is the lived experience of every agency owner I speak to. They tried it. They wanted it to work. They are quietly back on Elementor, or Bricks, or — increasingly — not on WordPress at all. Let us examine the patient.

The pitch was good. The pitch is always good.

The argument for Full Site Editing was, on paper, unassailable. WordPress had spent a decade fragmenting into a patchwork of page builders, custom post type plugins, theme frameworks, custom field engines, and bespoke shortcode soup. Every site was a Frankenstein. Every handover document ran to forty pages. Every developer who inherited a site spent the first week reverse-engineering somebody else's plugin choices before writing a single line of new code.

FSE promised to end this. One editor. One paradigm. One data model. Themes would become block themes — declarative JSON describing layouts, templates, and global styles. Everything would live in the database as portable block markup. The visual editor would touch every part of the site, not just the post body. The walls between content and presentation would dissolve. Developers would build blocks. Editors would assemble pages. Designers would set tokens in theme.json and watch them propagate. The end of chaos.

“It was a beautiful pitch. It was also a complete misreading of why WordPress had fragmented in the first place.”

WordPress did not fragment because the core team failed to ship a visual builder. It fragmented because thousands of agencies, freelancers, and product teams independently concluded that the underlying platform was not suitable for building modern websites, and they routed around it. The page builder ecosystem was not a gap in the product — it was a vote of no confidence. FSE assumed that if WordPress finally shipped its own builder, the market would come home. The market had moved on.

What FSE actually shipped

Let us be precise about what arrived. Full Site Editing is not a single feature. It is a constellation of overlapping subsystems, each at a different stage of maturity, each with its own documentation, each interacting with the others in ways nobody at Automattic has ever drawn a diagram of. The Site Editor. The Template Editor. The Pattern library. Block themes. theme.json. Global styles. Style variations. Block bindings. Block hooks. Synced patterns. The Navigation block. The Query Loop block. Each one ships, each one breaks, each one quietly receives breaking changes in minor releases.

The Site Editor itself is the centrepiece, and it is the part most developers have actually tried to use. It loads in an iframe. It nests editors inside editors. It has three different sidebar panels that show different controls depending on what you have selected, where you clicked, and the alignment of the moons of Jupiter. The keyboard shortcuts conflict with the browser. The undo stack is unreliable. Saving template changes triggers a modal asking you to also save the template parts, the global styles, and a third thing labelled simply 'changes' that nobody can identify.

None of this is a bug. All of it is by design. The design is the problem.

Why agencies quietly walked away

The agency objection to FSE is not aesthetic. Agencies do not avoid it because it is ugly, although it is. They avoid it for the same reason they would avoid handing a client a delivery van with the steering wheel mounted on the roof. It is not fit for the job they are being paid to do.

• →Client editing surface is uncontrollable. Hand a non-technical editor a block theme and within a week they have deleted the header template, replaced it with three stacked images of their dog, and emailed support asking why the menu is gone. The Site Editor exposes every layer of the site to every user with edit permissions, and the permission model has not caught up.
• →Locking is a joke. Yes, blocks can be locked. The locking interface is buried, inconsistent, and routinely bypassed by switching to the code editor view. Anyone who has tried to ship a tightly art-directed client site with FSE knows you are essentially relying on the client not knowing what to click.
• →Performance is dismal. Block themes ship duplicate styles, inline CSS per block, and an asset pipeline that has never met a critical-rendering-path graph it could not damage. Lighthouse scores on stock block themes are routinely worse than the page builder sites they were supposed to replace.
• →The migration path from a classic theme is hostile. There is no automated conversion. You rebuild from scratch, or you run a classic theme alongside the Site Editor and accept that half the global styles panel does nothing.
• →Custom blocks are still a build-tool quagmire. You still need Node, npm, @wordpress/scripts, a webpack config you do not control, and a deployment story that involves committing build artefacts to a Git repository hosted on a server that does not run Node. Five years on.

Each of these is, individually, fixable. Collectively, they are not — because fixing them requires the WordPress project to make decisions it has been congenitally unable to make for fifteen years. Decisions about backwards compatibility. Decisions about which legacy APIs to deprecate. Decisions about whether the platform is for end users, for developers, or for the seventy-three plugin authors who will scream the loudest in the Make WordPress Slack.

The backwards compatibility curse

Every modern platform that has succeeded in the last decade — Next.js, Astro, Shopify Hydrogen, Webflow, Framer — has made deliberate, public, sometimes painful breaking changes to escape its own legacy. WordPress cannot. The compatibility promise is the platform's foundational marketing claim and its load-bearing technical constraint. Sites built on the 2010 default theme must still work in 2026. Plugins written against APIs introduced when David Cameron was prime minister must continue to load without warnings.

This is admirable. It is also catastrophic. It means FSE cannot replace the classic editor — it must coexist with it. It means block themes cannot replace classic themes — both must be supported. It means the Customizer is still in there, doing things, even though the Site Editor was supposed to replace it. It means every site is now running two competing template systems, two competing styling systems, and two competing mental models, with a thin shim of marketing copy on top pretending this is all one cohesive product.

“FSE is not a redesign of WordPress. It is a second WordPress, glued to the first one, and you are expected to pretend the seam is a feature.”

This is the bandaid question, answered. FSE is not a step forward because it cannot replace what came before. It can only be layered on top of it. Every release adds more surface area, more configuration, more documentation, more places for the editor to fail in ways that require a developer to diagnose. The total complexity of the platform monotonically increases. The promise of unification produces, in practice, the opposite of unification.

The governance problem nobody wants to name

Full Site Editing was not designed in the open. It was designed by a small group inside Automattic and shipped to the wider WordPress community as a fait accompli, with the expectation that the community would adapt theme authoring, plugin development, hosting infrastructure, and client education to match. The community has not. Five years of Gutenberg releases have not produced a single bestselling commercial block theme. The top-rated themes on the directory are still classic themes with Gutenberg compatibility bolted on. The market has voted, and the votes are in.

The recent governance turbulence — the trademark disputes, the contributor exodus, the public arguments about who owns what — is not unrelated. FSE shipped because one company decided it would ship. The platform's commercial ecosystem was never given a real seat at the table, and now that ecosystem is making its own decisions. Page builders are doubling down. Headless adopters are leaving entirely. Bricks, Breakdance, and Oxygen are not waiting for FSE to become viable. Astro and Sanity are not waiting for WordPress at all.

Is there a version of FSE that could have worked?

Yes. A version that broke compatibility. A version that shipped as WordPress 6 with a hard cutover, the way Drupal 7 to Drupal 8 was handled, the way Angular 1 to Angular 2 was handled. Painful, divisive, ecosystem-fracturing — but at the end of it, a single coherent platform with a single mental model. WordPress was constitutionally incapable of doing this. The compatibility promise made it impossible. The economics of the existing plugin and theme market made it impossible. The political structure of the project made it impossible.

So instead we got the version that ships alongside everything, replaces nothing, and quietly accumulates complexity in the hope that one day enough sharp edges will be filed off that adoption flips. It will not flip. Adoption does not flip in mature platforms. Adoption is set in the first eighteen months, and FSE missed its window in 2022 when the early adopters tried it and went back to Elementor.

What this means for you

If you are running an agency and still building on WordPress, the immediate practical advice is unchanged. Do not stake new projects on FSE. Pick a page builder with a clear data model and stick to it. Resist the temptation to mix block themes and classic themes in a single site. Be honest with clients about which editor surface they will actually use, and lock down everything else.

The longer-term advice is the same advice this site has been giving for two years. FSE is not an isolated failure. It is the most expensive, most visible, most well-funded attempt the WordPress project has made to modernise itself, and it has been quietly rejected by the market it was built for. That is data. That is a signal. The platform's flagship feature of the decade is the feature nobody wants. Draw the obvious conclusion.

Bandaid, then. Not a step.

Full Site Editing is a bandaid. It is a bandaid applied to a structural injury, by a patient who refuses to acknowledge the injury exists, using materials that do not match the wound, in a hospital where the surgeons cannot agree on who is in charge. The bandaid is large. The bandaid is expensive. The bandaid is, in places, very competently applied — there are individual blocks and individual subsystems that are genuinely well-designed.

But a bandaid is not a step forward. A step forward would have been a new platform. WordPress could not ship a new platform, so it shipped a bandaid and called it a revolution. The revolution did not come. The bandaid is peeling. And the patient, increasingly, is being wheeled out of the building by agencies who have realised they can do better elsewhere.

If you are still inside the building, take the hint. The exit is well-signposted, and the wait at the door gets longer every quarter.