If you’ve built sites with WordPress for a while, you’re living through one of its biggest platform shifts since the move to the block editor.

Classic themes are the “traditional” WordPress way: PHP template files, the Customizer, widgets, menus, and a workflow that (often) depends on plugins or page builders for advanced layout control.

Full Site Editing (FSE) themes, more accurately called block themes, bring a different mental model: your headers, footers, templates, and layout are composed of blocks and edited in the Site Editor, with styling centralized through Global Styles and theme.json. WordPress formally introduced block themes in WordPress 5.9. 

This post will help you choose, without hype, by breaking down how each theme type works, where each shines, what can go wrong, and how to decide based on real-world constraints (clients, speed, maintainability, plugin stacks, team skills, and growth plans).

Quick definitions

The WordPress Theme Handbook is pretty direct:

• A block theme is built primarily with HTML templates plus a theme configuration file (theme.json), and is designed so you can edit all parts of the site in the Site Editor. 
• A classic theme is the original model, primarily PHP, CSS, and JavaScript, leveraging hooks/filters and the classic theme architecture. 

Also: not all themes are compatible with Full Site Editing. Classic themes don’t provide that capability; block themes do.

Why this decision matters more than ever

Two data points explain why theme architecture is now a strategic choice, not just a design preference:

1. WordPress powers a huge portion of the web. As of February 1, 2026, W3Techs reports WordPress is used by 42.8% of all websites and 60.0% of websites using a known CMS.
2. Most WordPress sites are on modern major versions (meaning FSE features are “available” even if not used). W3Techs reports WordPress version 6 is used by 91.2% of WordPress sites it detects.

So: the ecosystem is big, and the platform’s “default direction” is clearly block-first, yet classic is still everywhere because it’s mature, stable, and deeply integrated into how many businesses run WordPress.

How block themes (FSE) actually work under the hood

1) Templates become HTML + block markup

Block themes use an HTML-based template system in /templates and /parts. A minimal indicator of a block theme is the presence of index.html in the templates directory. 

What that changes for you:

• Templates are editable (to varying degrees) inside WordPress.
• Layout is represented as blocks (including “theme blocks” like Site Title, Navigation, Query Loop, etc.).
• Less “hard-coded” PHP layout… but not necessarily less complexity.

2) Styles become “design tokens” via theme.json

Block themes centralize design rules (colors, typography, spacing, layout widths, block supports, etc.) in theme.json, and those settings feed the editor UI and front-end output. WordPress documentation and platform resources describe theme.json as the mechanism enabling structured, site-wide styling and editor configuration.

3) Global Styles and patterns become the primary workflow

Instead of “Customizer settings + widget areas + theme options panel,” you’re often working with:

• Global Styles (site-wide typography, colors, spacing, block defaults)
• Style variations (switch entire looks without changing theme)
• Block patterns (pre-built sections/pages)

And you do it largely in the Site Editor.

How classic themes actually work (and why they still win in many cases)

Classic themes are typically:

• PHP template files (single.php, page.php, archive.php, etc.)
• Functions and hooks in functions.php
• Customizer settings, widgets, menus
• Often a child theme for customization

What that changes for you:

• You can build extremely dynamic, logic-heavy templates in PHP.
• You can control output at a granular level via hooks/filters.
• You’re working with a model that’s been hardened by ~two decades of production usage and plugin compatibility.

The “hybrid” reality most people forget

It’s not only “classic vs FSE.”

Many sites end up hybrid in practice:

• A classic theme that supports some block features
• Or a block theme that still relies on custom plugins/blocks for dynamic sections
• Or a classic theme + page builder approach (Elementor, etc.)

In fact, W3Techs’ detected subcategory usage suggests page builder and commerce ecosystems remain massive; for example, it reports Elementor on 30.7% of WordPress sites and WooCommerce on 20.2%. 

That means your theme choice often needs to respect an existing ecosystem—especially for stores, membership sites, LMS sites, or builder-based marketing sites.

Side-by-side comparison: block themes vs classic themes

Dimension	Block (FSE) themes	Classic themes
Site-wide editing	Native Site Editor control for templates, headers/footers, layout	Typically not editable site-wide without code or builder
Styling system	Global Styles + theme.json (centralized tokens)	CSS + Customizer + theme options (often fragmented)
Speed of layout changes	Fast for non-devs (patterns, template edits)	Slower without devs or a builder
Developer model	Block templates + theme.json + custom blocks	PHP templates + hooks/filters + Customizer APIs
Plugin compatibility	Improving quickly, but edge cases exist	Generally best-in-class compatibility
Client handoff	Strong if you want clients to “own” layout safely	Strong if you want to limit client layout control
Long-term direction	Aligned with core roadmap and default themes	Still supported, but not the platform’s “center of gravity”

Pros of Full Site Editing (block themes)

1) True site-wide control without a page builder

For many sites, FSE is the first time WordPress core offers a builder-like ability to modify global layout (headers, footers, templates) without installing a third-party builder.

If you build SMB marketing sites, landing pages, brochure sites, blogs, and lightweight service sites—this can be a huge cost and speed advantage.

2) Consistent design with fewer “mystery settings”

In classic builds, design often gets scattered across:

• Theme options panel
• Customizer controls
• Widget settings
• Page builder templates
• Custom CSS
• Plugin-specific styling

Block themes push you toward a single design system: Global Styles + theme.json. 

3) Patterns = repeatable sections (and better scaling)

Patterns help teams scale production:

• Designers create approved sections
• Marketers assemble pages
• Layout remains consistent

This is one of the most “agency-friendly” benefits of FSE when implemented intentionally (with a pattern library and guardrails).

4) Better future-proofing for WordPress core evolution

Block themes aren’t a side feature; they were formally introduced and prioritized with WordPress 5.9. The official docs and learning resources increasingly assume block concepts as the default path. 

If you’re building new sites today, aligning with the “direction of travel” often reduces future rework.

Cons of Full Site Editing (block themes)

1) The learning curve is real (especially for teams)

FSE requires new mental models:

• Template hierarchy exists, but now you edit templates as block layouts
• Styling becomes “tokens and presets”
• You manage variations, patterns, and block defaults

Teams used to “Customizer + page builder + a few theme settings” can feel disoriented at first.

2) You can accidentally give clients too much power

Yes, clients can finally edit headers and templates.

But that also means they can:

• Break layout consistency
• Change global styles and affect every page
• Create “almost the same but slightly different” sections that bloat maintenance

You can mitigate this with:

• Good pattern systems
• Locked-down block settings
• Clear governance (what’s editable vs not)

…but it’s a real operational concern.

3) Advanced dynamic layouts still require development

If you need:

• Highly customized queries
• Complex conditional rendering
• Deep integration with custom post types + custom fields
• Sophisticated WooCommerce custom templates

…you often end up writing custom blocks, custom plugins, or bridging logic anyway.

FSE reduces the need for a page builder, not the need for engineering when your product requirements are complex.

4) Tooling and debugging can feel immature compared to PHP templates

In classic themes, you can reason about templates in code and debug with mature workflows.

In block themes:

• Markup is block-based
• Some structure is managed through editor UI
• The boundary between “content” and “template” can blur

That’s not bad—just different, and sometimes harder to troubleshoot under time pressure.

Pros of classic themes

1) Maturity and compatibility across the ecosystem

Classic themes remain the “default assumption” for countless plugins, especially older or enterprise-grade stacks.

If your site relies on a complex chain of plugins—classic is often the safest choice.

2) Maximum control for developers

When you need:

• Precise output control
• Performance micro-optimizations
• Complex logic in templates
• Custom post type rendering with nuanced conditions

PHP templates + hooks can be a dream.

3) Stable workflows for agencies with established stacks

Many agencies have:

• A starter theme
• A child theme system
• A repeatable set of plugins
• A proven QA checklist

Classic themes fit right into that operational machine.

4) Strong guardrails by default

Ironically, classic themes can be better for client handoff when you want to limit scope creep.

Clients can edit content, but they can’t casually redesign global layout (unless you add builder tools).

Cons of classic themes

1) Site-wide layout changes often require dev time (or a builder)

Want to change header layout, rebuild templates, or modify archive structure?

Classic usually means:

• developer work, or
• installing a builder and living with its constraints.

2) Styling can become fragmented

Classic sites often accumulate:

• Theme options panel settings
• Customizer settings
• Plugin styling
• Builder templates
• Custom CSS patches

That fragmentation increases maintenance cost and makes redesigns harder than they need to be.

3) The “classic + builder” stack can add weight and complexity

Not always—but often.
Some sites end up with:

• A heavy builder
• Multiple add-on packs
• Inline styles and extra scripts
• More moving parts that can conflict

This isn’t a guaranteed outcome, but it’s a common one—especially when requirements grow over time.

A practical decision framework: which theme type should you choose?

Choose a block (FSE) theme if…

• You’re building a new site and want the most modern workflow
• Your pages are mostly marketing, content, landing pages, lightweight services
• You want a design system approach (Global Styles + patterns)
• You want clients to have safe control over layout (with governance)
• You’re aiming to reduce dependency on third-party builders

Also, block themes are no longer “rare.” The WordPress theme directory currently lists 1,493 block themes under the Full Site Editing tag.

Choose a classic theme if…

• You have an existing classic build that’s stable and profitable
• You rely on complex plugin stacks where compatibility is mission-critical
• You need deep PHP-level customization and dynamic templating
• Your team is optimized for classic workflows and timelines are tight
• You want stricter client guardrails by default

Choose a hybrid approach if…

• You want a gradual transition
• You need classic-level control in some areas, but block-based editing in others
• You’re modernizing an older site without a full redesign budget

Migration: moving from classic to FSE without chaos

If you’re considering switching, treat it like a product migration—not “just a theme change.”

Step 1: Audit what your theme is actually responsible for

Common theme responsibilities:

• Header/footer layout
• Navigation behavior
• Blog/archive templates
• Custom post type templates
• Widget areas and sidebars
• Custom shortcodes or template functions
• CSS overrides

Step 2: Identify what must remain stable

Examples:

• Revenue-critical landing pages
• Checkout flow (especially stores)
• SEO-critical templates (archives, schema output, breadcrumbs)
• Core Web Vitals / performance targets

Step 3: Rebuild with patterns + template strategy

A good block-theme migration is not “freeform editing.”
It’s:

• A curated pattern library
• A defined set of templates
• Clear rules for editors

Step 4: Train editors (or you’ll lose the benefits)

Most FSE disappointments are training failures, not technical failures.

Create a 1–2 page internal guide:

• Approved patterns
• Do/don’t layout rules
• How to adjust global styles safely
• How to avoid “one-off snowflake sections”

Common myths (and what’s actually true)

Myth 1: “FSE is only for beginners.”

Not true. FSE can power sophisticated systems—but complex dynamic requirements still require engineering. The difference is where you draw the line between “editor-controlled layout” and “coded components.”

Myth 2: “Classic themes are going away.”

Also not true. Classic themes remain fully supported and widely used. WordPress positions FSE as the modern path, but it hasn’t abandoned classic architecture. (And given the scale of the ecosystem, it can’t casually do so.)

Myth 3: “Block themes are automatically faster.”

Not guaranteed. Performance depends on:

• The theme’s code quality
• Asset loading strategy
• Block choices and plugin stack
• Image/video handling and caching

FSE can reduce some bloat (especially if it replaces a heavy builder), but it’s not a magic switch.

What we’d do in 2026 if we were starting fresh

• For most SMB marketing/content sites: start with a solid block theme, build a pattern library, and implement governance.
• For complex dynamic builds (highly customized CPTs/fields, deep WooCommerce customization, membership/LMS): either stay classic or go hybrid—unless you have the engineering budget to build custom blocks and properly QA templates end-to-end.
• For existing stable classic sites: don’t migrate just because it’s new. Migrate when the business reason is clear: lower maintenance cost, faster iteration, less reliance on a builder, or a redesign that would happen anyway.