WordPress block themes: an honest take from a studio that builds both

Alipio Gabriel · · Updated · 5 min read
WordPress block themes: an honest take from a studio that builds both

WordPress block themes are genuinely exciting. They are also genuinely misunderstood, and we have fielded enough confused client questions this year to think it is worth writing down properly. So here is what we actually know from building both.

What a block theme actually is (and is not)

A classic WordPress theme controls your header, footer, and page templates through PHP files. A block theme replaces all of that with HTML template files made entirely of blocks. Your Site Editor in WordPress 6.x becomes the place where you edit everything: global styles, typography scales, color palettes, the navigation, the footer, every template. No PHP required to modify the layout.

That sounds like total freedom, and in some ways it is. But it also means the guard rails are lower. A client who can edit the footer block template can accidentally wreck the footer block template. That is a real tradeoff worth naming upfront.

Block themes also ship with a theme.json file that controls design tokens globally: spacing scales, font sizes, color palettes. For developers, that is a cleaner system than scattering CSS custom properties across a stylesheet. For clients, it is invisible. But it matters enormously for consistency and long-term maintainability.

The honest case for going full block in 2025

If you are starting a new project today, a well-built block theme on WordPress 6.5 or later is fast, lean, and genuinely future-proof. There is no page-builder JavaScript bundle sitting between your content and the browser. A stripped-down block theme can score in the high 90s on Core Web Vitals without heroic optimization effort, which matters more every year for search. We cover that ground in detail when clients come to us for WordPress speed optimization, and fewer moving parts is almost always the right starting point.

The Site Editor also makes handing off a site to a content team more approachable than it used to be. One interface, consistent patterns, no hunting through Customizer panels and Elementor Pro pop-outs at the same time. For teams without a dedicated developer on staff, that consistency is worth a lot.

Where block themes still frustrate people

The ecosystem is young. If your project needs a mature WooCommerce setup with heavily customized product pages, cart flows, and checkout logic, classic themes with a builder like Beaver Builder or a custom child theme are still more predictable in our experience. WooCommerce block support is improving fast, but edge cases surface in production, and debugging a styling conflict between a WooCommerce block and a theme.json global style is not a fun afternoon.

Complex web applications are a different category entirely. If what you actually need is a custom database, user roles, API integrations, and application logic, the block editor is largely beside the point. That kind of project falls under custom web apps, and the theme choice becomes a secondary concern.

Plugin compatibility is the other friction point people underestimate. Most established plugins work fine, but a handful of older ones assume classic theme hooks that simply do not exist in a block theme. Worth checking before you commit to a stack.

Are block themes good for SEO?

Yes, with the right setup. The performance advantage is real: leaner markup, no builder overhead, and a smaller JavaScript footprint all contribute to faster load times, which Google weighs directly in rankings. A block theme also makes it straightforward to set semantic heading hierarchies and clean HTML structure, both of which matter for crawlability. That said, the theme alone does not do the SEO work. A proper SEO and technical audit on top of a well-built block theme is still the combination that actually moves the needle.

How we actually decide on a given project

We scope every build before we touch a single file. The theme architecture follows the requirements, not the other way around. Here is the shortlist we work through:

  • Is the client team going to edit templates themselves, or just page content? Template editing favors block themes with locked patterns.
  • Does the project lean on WooCommerce heavily, with custom checkout flows? A classic or hybrid setup is still safer for now.
  • How aggressive are the performance targets? Block themes have a structural edge, and we take that seriously.
  • Is there an existing design system or brand identity to translate? Brand and visual system work done in Figma maps cleanly to theme.json tokens in a block theme.
  • What is the maintenance situation post-launch? Sites on our care plans need to be maintainable without specialized knowledge on every call.

One thing we would push back on

The framing that WordPress block themes are “the future” and classic themes are “legacy” is too clean. Classic themes built on solid PHP and a restrained builder are not going anywhere, and calling them legacy because Gutenberg exists is a little like calling a cast iron pan obsolete because someone invented the air fryer. Different tools, different jobs.

What is genuinely true is that if you are commissioning a custom WordPress build today and your requirements fit the block paradigm, we would lean toward it. The performance baseline is better, the long-term maintenance surface is smaller, and the editor experience is catching up fast. We just will not pretend it is the right call for every single project, because it is not.

If you are trying to figure out which direction makes sense for your site, we are happy to talk it through. Book a free 30-minute call and we will give you a straight answer based on what you are actually building.

Share