The WordPress Block Editor in 2026: What Gutenberg Can and Can't Do

The WordPress block editor — Gutenberg, if you have been around long enough to remember the fight over it — has quietly become the most under-recommended tool in the WordPress stack. It costs nothing, ships in core, requires no licence, no renewal and no vendor relationship, and it produces markedly leaner pages than any commercial page builder. It also cannot do several things people assume every builder does. This guide covers both halves, because the gap between them is where the decision lives.

We will say the uncomfortable thing early, since this site also reviews paid builders: for a large share of sites, the correct recommendation is to install nothing and use what you already have.

Where the project has actually got to

Gutenberg has a published four-phase roadmap, and knowing which phase you are standing in explains most of the editor's behaviour. Phase 1, easier editing, is finished — that was the original block editor for posts and pages. Phase 2, customisation, is finished and mature: block themes, full-site editing, patterns and global styles all belong to it. Phase 3, collaboration, is the one under active development right now. Phase 4, multilingual, has not started.

Two releases in 2026 moved the needle. WordPress 7.0 "Armstrong" arrived on 20 May with the WP AI Client — a core interface for wiring external AI models into WordPress — plus PHP-only blocks that need no JavaScript build step, more Site Editor design tooling, speculative loading and a refreshed admin. WordPress 7.1 "Mary Lou" followed on 19 August with responsive styling controls, a redesigned media editor and better image processing. Those responsive controls matter more than the release notes suggest: fine-grained control over how a layout behaves at different widths was one of the last obvious reasons to reach for a page builder.

Block themes and full-site editing

This is the part that turns the block editor from a post editor into something you can build a site with, and it hinges entirely on one choice. Install a block theme and Appearance → Editor appears, giving you your header, footer, archive pages, single-post template, search results and 404 page on the same canvas as your content, with a global styles panel governing colour and typography site-wide.

Install a classic theme and none of that exists. You get the old Customizer, widget areas and menu screens instead. Most sites built before 2023 and most themes sold before then are classic, which is why so many people conclude that full-site editing is not real — they are on a theme that never had it. Choose deliberately in week one, because switching theme types later means rebuilding your layouts.

Worth knowing: Elementor and Divi largely sidestep this system with their own theme builders. Running both a page builder and full-site editing means maintaining two overlapping design systems on one site, and it is a common source of "why won't this header change" confusion.

Patterns, and why they replaced reusable blocks

A pattern is a pre-arranged group of blocks you drop in and edit — a hero section, a pricing row, a team grid, a call-to-action band. Core ships with a set, your theme adds more, and the public pattern directory has thousands. This is the feature that answers the most common objection to Gutenberg, which is that starting from a blank canvas is slow. You rarely need to.

The distinction that trips people up is syncing. An ordinary pattern is a starting point: insert it, change it, and your changes are local to that page. A synced pattern — what older tutorials call a reusable block — stays linked, so editing it once updates every place it appears. Use synced patterns for anything that must stay identical across the site, such as a contact block or a disclosure notice, and unsynced ones for layout scaffolding. Getting this backwards produces either fifty copies of an outdated phone number or a home page that changes when you edit a landing page.

Phase 3 and Phase 4: collaboration in, multilingual out

Collaboration is the active phase, and 2026 showed how that work reaches you. Real-time collaborative editing was in WordPress 7.0 and was pulled at the release-candidate stage, then deferred. What shipped instead, in 7.1, is Notes: inline feedback and mentions attached to content — the down-scoped version of the same ambition. If your team currently drafts in a document and pastes into WordPress at the end, Notes narrows that gap without closing it. Expect the rest to arrive incrementally across the 2026 and 2027 releases rather than in one launch.

Phase 4 is the one with real budget consequences. Multilingual support is the last phase on the roadmap and work on it has not begun. Practically, that means core WordPress has no native way to run a site in two languages, and there is no near-term date at which it will.

If your site needs to exist in more than one language, WPML or Polylang is a permanent line item, not a stopgap until core catches up. Price it as an indefinite dependency, because Phase 4 has not started.

When Gutenberg alone is genuinely enough

More often than the page-builder market would like. If your site is content-led — a blog, a documentation site, a brochure site for a business that sells by phone or by meeting, a portfolio built around images and words — a good block theme plus patterns plus global styles will get you a site that looks professional and behaves properly on a phone. You will spend a weekend learning it instead of a weekend learning Elementor.

Two arguments push harder than aesthetics. The first is output: the block editor emits no builder wrapper markup and loads no extra CSS or JavaScript framework, so its pages are lighter than a commercial builder's rendering the same design. That is the honest performance advantage, and it costs nothing to take. The second is money, and it is not marginal. Drop the premium builder from a self-hosted build and the three-year cost falls to $165.52 on a prepaid budget host — against $1,084.00 for a mainstream hosted builder over the same period, and $1,130.04 for WordPress with a paid builder on value hosting.

That single decision — builder or no builder — moves the total more than the choice of host does, and it is the pivot our WordPress vs website builders comparison turns on. Gutenberg is the reason "WordPress is cheaper" can still be true.

Where it still frustrates

The gaps are specific rather than general, which makes them easy to check against your own requirements:

• No popup builder. Nothing in core does modals, slide-ins or exit intent. If popups are part of how you capture leads, you are buying a plugin regardless.
• No form builder. There is no core forms feature beyond comments. Free plugins cover this well, but it is another dependency to vet and update.
• No conditional display logic. You cannot natively say "show this block only to logged-in users on Tuesdays." Page builders can.
• Weaker fine-grained positioning. Responsive styling improved in 7.1, but pixel-level control still lags a dedicated builder.
• No comparable loop control. The Query Loop block works, but it does not match what Elementor's Theme Builder or Divi's equivalent give you for custom archive layouts.
• Essentially no motion design. Scroll animations, hover choreography and interaction states are absent, and the third-party template ecosystem is shallower than the builders'.

The decision, in one move

Read that list of gaps and check whether any of them describes a requirement rather than a preference. Popups, forms with conditional logic, custom archive templates, animation: if none of those is on your list, build with the block editor and keep the $99. If two or more are, buy the builder and stop feeling bad about it — that is what it is for.

The mistake worth avoiding is installing a page builder reflexively because a tutorial told you to in 2019. The editor you already have has changed considerably since then, and it is free.