Block Themes vs Classic Themes: Which Should You Build?

A classic theme is PHP templates. index.php, single.php, page.php, plus template parts, running the loop and outputting markup. The block editor still edits post content, but the page's structure — header, footer, sidebar, layout — is fixed in code.

A block theme replaces those PHP templates with HTML files composed of block markup, in a templates/ directory. Header and footer become template parts made of blocks. The Site Editor lets an administrator edit any of it through the interface, including the header, the footer and the archive layouts.

The consequence is the whole story: in a classic theme, changing the header means a developer. In a block theme, it means an editor with the right permissions — for better and for worse.

• Giving editors the ability to compose new page layouts without a developer or a page builder plugin.
• Global styles: one place to define colours, typography and spacing that applies everywhere, with an interface for adjusting it.
• Block patterns, which let you offer pre-designed sections editors can drop in and fill.
• Shipping less code — you're not writing PHP templates for layouts the block editor can express.
• Being where WordPress core development is going, so new features land there first.

• Locking a design down. If the header must look exactly like the brand guidelines say, a PHP template guarantees it and the Site Editor doesn't.
• Complex conditional logic in templates — different layouts by post type, user role, or data from an integration — which is plain PHP in a classic theme and awkward in block markup.
• Working with data that isn't posts: an external API, a custom table, a calculated value. Block themes need a custom block for that; a classic template just writes it.
• Predictability for developers. A classic theme's output is in files you can read; a block theme's is partly in the database after someone edits it.
• Existing sites. Converting a working classic theme to a block theme is a rebuild, and rarely pays for itself on its own.

theme.json is the most useful thing to come out of this change, and it isn't exclusive to block themes. A classic theme can ship one and get most of the benefit.

It defines your palette, font sizes, spacing scale and layout widths in one file, and WordPress uses it to populate the editor's controls. The effect is that the colour picker offers your five brand colours rather than an arbitrary spectrum, and the font size control offers your type scale rather than a free-text pixel value.

That constraint is what keeps a site looking coherent two years in. Without it, every editor makes locally reasonable choices that add up to eight typefaces and eleven shades of blue.

The most common regret I hear about block themes is that editors changed something they shouldn't have been able to. The Site Editor's power is real, and by default it's handed to anyone with administrator access.

This is manageable, but it's work you have to plan for. Lock blocks that shouldn't be moved or removed. Restrict which blocks are available. Build patterns for the layouts editors need so composing a page means choosing a pattern rather than assembling primitives. Consider whether the people editing should have Site Editor access at all, or whether Editor role is enough.

Budget for that work. A block theme without guard rails is cheaper to build and much more expensive to live with.

Ask who needs to change what, and how often.

• Editors only add content to existing layouts, and the design is fixed → classic theme is less work and safer.
• Editors regularly need new page layouts, and there's no budget for a developer each time → block theme earns its complexity.
• The site is mostly one or two templates driven by structured data or an integration → classic, with custom blocks where editors need to place things.
• A marketing team will build landing pages continuously → block theme, with a strong pattern library.
• Existing classic site that works → stay classic, and adopt theme.json for the styling benefits.

It isn't binary. A classic theme can register custom blocks, ship a theme.json, and offer block patterns. Many of the sites I build sit exactly there: PHP templates for the structural pages where the design must hold, custom blocks for the sections editors compose themselves, and theme.json constraining the palette and type.

That gets you most of the editor benefit without handing over the header. It's also the easiest position to move from later, in either direction.

Converting classic to block is a rebuild of the templates, not a conversion. Content survives — posts, pages, media, custom fields are untouched — but every template has to be recreated as block markup, and anything relying on template PHP has to become a block or a plugin.

It's worth doing when you're redesigning anyway, or when the editing bottleneck is costing real money. It is not worth doing to be current. A working classic theme is supported and will remain so.

Both approaches need the same discipline underneath: a sensible content model, business logic in plugins rather than the theme, assets loaded only where they're needed, and escaping on output. The theming approach is a layer on top of those, and it won't rescue a site that got them wrong.

If you're weighing this up for a specific project, the deciding question is almost always who edits the site and what they need to change. Tell me that, and the answer is usually obvious.