Gutenberg and Block Themes vs Classic Themes: What to Build With in 2026

The block themes vs classic themes question is the one WordPress decision that developers argue about with actual religious energy, and most of what you will read about it is written by someone with a side to defend. I do not have one. I build classic themes with ACF-driven sections for most of my client work, I use the block editor every week where it genuinely shines, and I have rebuilt sites in both directions – classic to block and block back to classic. So this is a working developer’s verdict, not ideology: what each approach actually is, where each one wins, and what I would build for a specific site in 2026.

In this guide I will walk through the short history of Gutenberg and Full Site Editing in plain language, what a block theme technically is compared with a classic theme, the honest pros and cons of each for real client projects, the classic-plus-ACF approach I default to and its trade-offs, the middle grounds most articles ignore, a straight performance comparison, a decision table by site type, and what happens when you migrate. It draws on 12+ years and 500+ WordPress projects for small businesses and agencies in Germany, the UK, the US and Australia.

Table of contents

• A short history: Gutenberg, FSE and where core is heading
• What a block theme actually is (vs a classic theme)
• The honest case for block themes
• Where block themes hurt on client work
• The classic + ACF approach I use, and why
• The middle grounds nobody writes about
• Performance: the honest comparison
• Who should choose what: a decision table
• Migration: switching is a rebuild, not a toggle
• When block themes might become my client default
• How to evaluate a theme you are buying in 2026
• Frequently asked questions

A short history: Gutenberg, FSE and where core is heading

Until 2018, writing a page in WordPress meant one big text box – the classic editor – and everything around that box (header, footer, sidebars, layouts) lived in the theme’s PHP files. Then WordPress 5.0 shipped Gutenberg: instead of one text box, content became a stack of blocks – paragraph, heading, image, columns, and so on. That first release only changed the content area. The theme still controlled everything else.

The second phase, Full Site Editing (FSE), arrived with WordPress 5.9 in early 2022. With a block theme, the header, footer and every template are themselves made of blocks, editable in a visual Site Editor inside wp-admin. The theme stops being a set of PHP files that render pages and becomes a set of block templates plus a configuration file. Since then, every major WordPress release has poured most of its energy into this system: better patterns, style variations, fluid typography, the Styles panel, and steady polish of the editing experience.

Two facts matter for your decision, and both are true at once. First: block themes are the strategic direction of WordPress core – the default themes (Twenty Twenty-Two onwards) are all block themes, and new editor features land there first. Second: classic themes are fully supported, run tens of millions of sites including most of the largest ones, and there is no removal on any roadmap. Anyone telling you classic themes are “deprecated” is selling something; anyone telling you block themes are a fad has not looked at where core development effort goes. Both statements are marketing. The engineering reality is a long coexistence.

What a block theme actually is (vs a classic theme)

The classic theme model

A classic theme is PHP. Templates like front-page.php, single.php and page.php decide what renders; functions.php registers menus, image sizes and features via add_theme_support(); styling lives in the stylesheet the developer wrote. The editor – classic or block – is for content only. The site’s structure and design are code, changed by a developer, versioned in Git. This is the model behind almost every custom theme built for a business in the last decade, and it is what my WordPress theme development service delivers in most projects.

The block theme model

A block theme replaces most of that PHP with three things:

• theme.json – a single configuration file that defines the design tokens: colour palette, font sizes, spacing scale, layout widths, and which editor controls are switched on or off. WordPress generates CSS from it, for the front end and the editor at the same time.
• HTML templates and template parts – files in templates/ and parts/ that contain block markup, not PHP. A header is a template part made of a Site Logo block, a Navigation block and so on.
• The Site Editor, patterns and global styles – the admin UI where all of it is editable visually. Patterns are pre-arranged groups of blocks (a pricing section, a hero) that users insert and fill in; global styles let a site owner change the palette or type scale across the whole site without touching a file.

The mental shift is real: in a classic theme the developer ships rendered output; in a block theme the developer ships a starting state that the site owner can edit – all of it, including the header and footer. That single difference drives almost every pro and con below.

A quick side-by-side

The honest case for block themes

I will make the strongest fair case, because plenty of block-theme criticism from classic-theme developers is just discomfort with change.

• Visual full-site control for site owners. A capable owner can change the header, build a landing page from patterns, adjust the palette and ship it – no developer, no invoice, no waiting. For a hands-on owner who wants that control, it is genuinely empowering, and it is the thing no classic theme offers.
• Patterns are excellent. A well-designed pattern library is the best “build me a decent page quickly” tool WordPress has ever shipped in core. Insert, replace the text and images, done – and the result uses the theme’s own tokens, so it stays on-brand.
• Less lock-in than page builders. Blocks are core WordPress. There is no annual licence, no proprietary shortcode soup, and content is stored as portable HTML with comments. Compared with the builder ecosystem I discussed in custom development vs page builders, that is a real structural advantage – if a block plugin dies, your content degrades to plain HTML rather than a wall of broken shortcodes.
• Core-native performance. Block themes load only the CSS for blocks actually used on a page, theme.json output is lean, and there is no builder runtime. A disciplined block theme is fast by default.
• Design tokens are the right idea. theme.json forces the palette, type scale and spacing into one declared system that both the front end and the editor respect. Classic themes achieve the same with CSS custom properties, but core enforcing it is progress, and it makes the editor preview honest – what the client sees while editing is what renders.
• It is where the platform is going. New core features – fluid type, layout controls, style variations – land in the block system first. Building there means riding the platform’s momentum instead of reimplementing it.

Where block themes hurt on client work

Now the part the WordPress marketing pages skip – and note that these are problems for a specific context: building sites for non-technical business clients, which is most of my work and most of the industry’s.

The editor is still confusing for non-technical clients

The Site Editor has improved every release, but list view, nested groups, template vs content, “you are editing a template part that appears on every page” – this is a developer’s mental model, not a shop owner’s. I have watched clients open the Site Editor, feel lost inside two minutes, and never open it again. The people the feature was built to empower are often the people least equipped to use it safely.

Everything editable means everything breakable

This is my biggest practical objection. When a client can edit the header, a client will eventually break the header. When every page is an open canvas of movable blocks, the design integrity you were paid to deliver has a shelf life of one enthusiastic Tuesday afternoon. On a classic + ACF build, the worst a client can do is write a bad headline; on an unlocked block theme, they can drag the logo into the footer.

Locking things down is possible but awkward

Yes, there are answers: templateLock, block locking, lockedBlocks in patterns, trimming controls via theme.json, filtering allowed blocks, role-based capability tweaks. I use them. But you are opting out of openness feature by feature, the lock model has gaps and changes between versions, and a determined client in list view can still get somewhere you did not expect. Classic themes are locked by default and opened deliberately; block themes are open by default and locked laboriously. For agency handoff, the default matters enormously.

Complex dynamic sections still mean React development

The moment a client needs a section that queries and formats real data – a filterable team grid, a rates table from an API, a booking widget – patterns and core blocks stop being enough and you are writing a custom block. Native custom blocks are React: JSX, a build step, block.json, edit and save components, deprecation handling when you change the markup. That is real engineering, typically two to five times the effort of the equivalent ACF-driven PHP section, and it needs a JavaScript developer to maintain. This is exactly the work I take on in custom WordPress development projects, so I say this as someone who builds them, not someone avoiding them.

The third-party block ecosystem is wildly uneven

Block plugin suites range from excellent to page-builders-in-disguise that load 300 KB of CSS on every page. Many sites “built with the block editor” are actually built on one of these heavy libraries, which quietly reintroduces the lock-in and bloat that leaving page builders was supposed to fix. Every third-party block suite you add is a dependency with its own update record and its own idea of markup.

The classic + ACF approach I use, and why

Here is what I actually ship for most business and agency clients, so you can judge the alternative fairly. It is a custom classic theme where each page is assembled from structured sections – hero, services, testimonials, pricing, FAQ, contact – built as ACF flexible content layouts or field groups. The client edits fields: a headline, an image, a set of testimonial entries, a toggle for a background variant. The client never edits layout, spacing or structure, because those are code.

Why this remains my default

• Nothing to break. The design an agency signed off in Figma is the design the site shows in two years. Every field is validated, every image is cropped and compressed by code, every section renders from one template. Client-proof is not a feature I bolt on; it is the architecture.
• The editing experience is simpler, not poorer. A form that says “Headline, Text, Button label, Button link” is something every office manager understands in thirty seconds. No canvas, no list view, no way to get lost. My clients edit these sites happily for years without a support ticket.
• Dynamic sections are cheap. A section that pulls from an API or queries custom posts is a PHP template – an afternoon, not a React build with a deprecation strategy.
• Pixel-faithful design conversion. When converting a designer’s file, I write the CSS the design needs rather than composing from core blocks and fighting their markup – the workflow in my Figma to WordPress guide, and the core of my Figma to WordPress service.

The honest trade-off

The weakness is symmetrical with the strength: the client cannot create a new kind of section without me. If they need a “comparison slider” section that does not exist yet, that is a developer task – usually a small fixed price, delivered in days, but still a dependency. For a business that redesigns its pages twice a decade this trade is obviously right. For a marketing team shipping three new landing-page concepts a month, it is friction, and I tell those clients so before we start. A good developer choice is one you can state the downside of; this is mine.

The middle grounds nobody writes about

The debate is framed as binary. In practice, most of my 2026 builds sit in between, and these hybrids are often the best answer.

Classic theme + block editor for blog content only

This is my strongest default recommendation. Pages – home, services, about, contact – are structured ACF sections, locked and client-proof. Blog posts are written in the block editor, where it is genuinely the best writing tool WordPress has ever had: headings, images, lists, embeds, code, tables, all fluid and pleasant. Posts are long-form prose, so “client breaks the layout” barely applies; the post template still controls typography and width. You get Gutenberg where it shines and structure where it matters. Almost every business site I ship works this way.

Hybrid themes: classic with theme.json

A classic theme can adopt theme.json without becoming a block theme. You keep PHP templates and full control, but declare your palette, font sizes and spacing so the block editor offers exactly your brand’s options and nothing else – no rogue neon green, no 11 font sizes. You can also register your own block patterns for post content. This “classic plus tokens” setup is how I build now: the strictness of classic, the editor integration of block themes.

Custom blocks: ACF Blocks vs native React blocks

When a client does need custom blocks inside post content, there are two routes. ACF Blocks (in ACF Pro, around USD 49 per year) let you register a block with a PHP render template and ACF fields – an hour or two per block, maintainable by any PHP developer, ideal for presentational blocks like a stats row or a quote card. Native React blocks cost far more to build but give a true inline editing experience and no plugin dependency – the right call for interactive blocks, for products meant for distribution, or for editorial teams living in the editor all day. For a typical business site, ACF Blocks win on cost; for a publisher, native blocks win on experience.

Performance: the honest comparison

The performance argument gets abused by both camps, so here is the version I will stand behind after optimising a few hundred sites: a well-built classic theme and a well-built block theme are both fast, and the difference between them is smaller than the difference either has with a typical page-builder site.

A lean custom classic theme ships maybe 30-60 KB of CSS and little JavaScript. A disciplined block theme ships per-block core styles plus theme.json output – a similar order of magnitude, sometimes slightly less CSS on simple pages thanks to per-block loading, sometimes slightly more markup because core block HTML is div-heavier than hand-written templates. Either can score 90+ on PageSpeed mobile with proper image handling, font loading and hosting; either can be dragged into the 40s by neglect.

Where the real bloat lives is elsewhere: page builders shipping 300-500 KB of render CSS and JS on every page, heavy third-party block libraries doing much the same, sliders, seventeen plugins and 4 MB hero PNGs. The theme model is rarely the bottleneck; the additions are – the full breakdown is in my WordPress speed guide. If someone sells you a theme on speed alone, check what it loads on a blank install; that number matters more than its architecture.

Who should choose what: a decision table

Assuming a competent build in each case, here is how I would decide by site type in 2026:

The pattern behind the table: the more trained and frequent the editing, and the fewer untrained hands involved, the better block themes get. The more the site is a designed asset edited occasionally by non-technical people, the better classic + ACF gets.

Migration: switching is a rebuild, not a toggle

A question I get monthly: “can we switch our classic theme to a block theme?” You can activate one, but nothing meaningful carries over. Your PHP templates, ACF sections, menus-as-code and widget areas have no automatic translation into block templates. Moving from classic to block (or back) is a rebuild – budget it like a redesign, roughly EUR 1,500-6,000 at my rates depending on size, not like a theme swap. If you go that way, protect your rankings with the process in my redesign without losing SEO guide – URLs, redirects, metadata and content mapping matter far more than the theme model.

The reassuring half of the answer: content created in the block editor is portable. Blocks are stored in the post content as HTML with comment markers, so if you switch themes – or abandon the block editor entirely – your posts remain valid HTML and keep rendering. Compare that with page-builder content, which collapses into shortcode debris the day the builder is removed. ACF content is also portable in its own way: the field data lives in post meta, so a new theme can re-render it, though the templates that display it are theme code and move with the developer. Nothing here is a hostage situation; it is just work that someone has to scope honestly.

When block themes might become my client default

I re-evaluate this every year, and I can name the specific things that would flip my default for business clients. First, a simpler locked editing mode in core – a client-facing view that shows only the fields and patterns I allow, with the Site Editor’s power hidden behind a capability, without me assembling it from five locking mechanisms. Second, a stable, batteries-included path for dynamic sections that does not require a React build for every data-driven design. Third, more consistency release to release, so a build I hand over in January still edits the same way in December.

All three are trending in the right direction, which is why I keep building internal projects and content-heavy client sites on block themes to stay sharp. My honest expectation: within a few years, block themes with strict pattern libraries become my default for content-led sites and larger editorial clients, while classic + ACF keeps the designed-asset business sites for a long time yet. I would rather move a year late with a process that works than a year early on my clients’ budgets.

How to evaluate a theme you are buying in 2026

If you are not commissioning a custom build but buying a theme, the block vs classic label matters less than the theme’s discipline. My checklist, either architecture:

1. Update record: steady releases over at least two years and tested with the current WordPress version. An abandoned block theme is no safer than an abandoned classic one.
2. No bundled page builder: if the demo requires Elementor or WPBakery, you are buying a builder site with the drawbacks in my page-builders comparison, whatever the marketing says.
3. Speed on a blank install: install it on a clean site, run PageSpeed on the demo home page, and look at total CSS/JS weight. Under ~150 KB of combined assets before your content is a good sign; 500 KB+ on hello-world is your warning.
4. Editing model fits your team: open the editor as your least technical editor would. If they can break the header, assume they will.
5. Reasonable dependencies: one or two well-known plugins are fine; a required bundle of six “premium” plugins with lifetime-deal licences is technical debt in a zip file.

And if a purchased theme cannot tick those boxes, a small custom build is often closer in price than people expect – which is usually the point in the conversation where my quote surprises them pleasantly.

Need help choosing or building your WordPress theme?

I build custom WordPress themes both ways – classic with ACF-driven sections and block themes with theme.json and pattern libraries – and I will tell you honestly which one fits your site before any money changes hands. See my WordPress theme development service and portfolio, or send me a message with your project – I reply with a straight recommendation and a fixed quote within 24 hours.

Frequently asked questions

Block themes vs classic themes: which is better?

Neither is better universally. Block themes suit content sites and trained editorial teams who want visual full-site control; classic themes with structured ACF sections suit business and agency sites where design integrity and a simple, unbreakable editor matter more.

Are classic WordPress themes being deprecated?

No. Block themes are the strategic direction of core development, but classic themes remain fully supported, run a large majority of existing WordPress sites, and there is no removal plan on any roadmap.

Is Gutenberg the same thing as a block theme?

No. Gutenberg (the block editor) edits content and works with any modern theme; a block theme goes further and makes templates, header, footer and global styles block-based and editable in the Site Editor.

Are block themes faster than classic themes?

Not meaningfully – a well-built theme of either kind scores 90+ on PageSpeed. Real-world bloat comes from page builders, heavy block libraries, oversized images and excess plugins, not from the theme model.

Can I switch my classic theme to a block theme?

Technically you can activate one, but templates and structured content do not carry over – it is a rebuild, scoped and priced like a redesign, with proper redirects and SEO handling.

Do block themes replace ACF?

No. ACF remains the cleanest way to give clients structured, unbreakable editing in classic themes, and ACF Blocks are the cheapest way to build custom blocks without React development.

What should a small business choose in 2026?

My default recommendation: a custom classic theme with ACF-driven sections for pages and the block editor for blog posts – client-proof where it matters, modern where it helps, and typically delivered at a fixed price within a few weeks.