What’s The Future Hold For WordPress Themes?

Every few weeks, someone publishes an article saying WordPress is dying. Usually, the reason is a slow site, a clunky plugin, or a bad experience with an old theme.

But hidden inside that complaint is a real point that gets blown way out of proportion: the way WordPress themes get built has changed a lot. That’s a very different claim than “WordPress is dead.” And it’s the one worth digging into.

If you’re a developer, an agency owner, or just someone picking a theme for your site, the real answer isn’t panic. It’s a change in strategy.

Themes Aren’t Dead — The Way We Build Them Is

Do-everything PHP themes are on the way out (for some of us they always were). Not because WordPress is failing, but because the platform outgrew that model.

The Gutenberg block editor, FSE, theme.json, and page builders like Beaver Builder and WPBakery have split theme development into a few different jobs: block theme building, custom block coding, headless front-end work, and page builder customization.

If you’re still building themes the old way – static PHP templates, hardcoded layouts, the Customizer — you’re working against the direction WordPress has been heading since version 5.9. If you’ve moved toward block themes, theme.json, and reusable patterns, you’re already where things are going.

So, not dead; just shifting. Here’s exactly how, and what to do about it.

Is the Platform Actually Shrinking? WordPress by the Numbers

“WordPress in 2026 is like PostgreSQL or Nginx: mature, stable, and boring technology …not an insult,” but a sign of a platform that’s settled into being dependable rather than trendy.
dev.to

Before we get into themes, let’s look at the actual data behind the “dying” claim.

“WordPress is used by 59.1% of all the websites whose content management system we know. This is 41.2% of all websites” W3Techs.com (7/26/2026)

• WordPress still powers over 41% of all websites on the internet. Among sites that use any CMS at all, WordPress holds roughly 59–60% of that market — more than every other CMS combined.
  • 52% Version 7
  • 40.6% Version 6
  • 5.1% Version 5
  • 2.1% Version 4
  • 0.2% Version 3
• WP’s closest competitor by total web share is Shopify, at under 5%. Wix and Squarespace are further behind that.
• Over 90% of active WordPress sites now run WordPress 6.x. Most real installs are on block-editor-era versions, not old classic-theme setups.

None of that looks like a platform in decline. It looks like a platform that’s grown so large its growth rate is naturally leveling off — which is a very different story than dying.

The real headline isn’t “WordPress is failing.” It’s “the tools changed under WordPress’s feet, and so did the skills you need.”

How WordPress Themes Have Changed

From Classic PHP Themes to Block Themes

For most of WordPress’s history, a theme was a bundle of PHP files: header.php, footer.php, single.php, page.php. Add a functions.php file to wire up features, and CSS to handle the look. If you wanted to customize anything beyond what the theme allowed, you needed the Customizer, some code, or a child theme.

That changed with WordPress 5.9, which introduced block themes. A block theme uses blocks for every part of a site — navigation, header, content, and footer. Instead of PHP files controlling the structure, block themes use HTML templates made of blocks. That gives site owners direct, visual control over things that used to need a developer.

The difference matters for developers and site owners alike. Block themes let you edit your whole site visually — colors, fonts, layout, all of it — right from the editor. Classic themes still rely on PHP templates, functions.php, widgets, and the Customizer. And classic themes don’t work with the Site Editor at all. That tool is limited in its use to block themes only.

If a theme still leans on the Customizer for styling, or on widget areas for the footer, it’s a classic theme. If you can edit the header, footer, and templates right inside the Site Editor, it’s a block theme.

Full Site Editing and theme.json

“FSE… expands beyond posts and pages to the entire WordPress site… you can use blocks to design and customize all aspects of your site, including the header, footer, sidebar, and more.”
Rocket.net – Are Agencies Using The Gutenberg Block Editor?

Full Site Editing (FSE) is the umbrella term for the tools that make block themes work. That includes the Site Editor, the Styles panel, template parts for things like headers and footers, and blocks like Navigation and Query Loop. Those blocks used to require custom PHP code or a plugin.

At the heart of every block theme sits theme.json. This one file defines a site’s global styles: colors, fonts, spacing, layout widths, and which controls show up in the editor. Instead of scattering add_theme_support() calls across functions.php, you set your design choices once in theme.json. Both the editor and the live site follow those rules automatically.

This is the biggest workflow change for developers. theme.json turns theme design into something closer to a real design system, not a pile of CSS overrides. If you’re updating your skills, start here.

Classic Themes vs. Block Themes, Side by Side

	Classic Themes	Block Themes
Template files	PHP (header.php, single.php, etc.)	HTML files built from blocks
Global styling	Customizer + theme options panels	theme.json + the Styles panel
Header/footer editing	Widget areas, limited Customizer controls	Fully editable in the Site Editor
Navigation	Menus screen	Navigation block
Site Editor support	Not available	Fully supported
Best fit for	Complex custom PHP, older plugins, teams already deep in PHP	New builds, clients who want visual control, teams using theme.json
Where WordPress is investing	Maintained, not a priority	The focus of Gutenberg development

Neither one is “wrong.” Classic themes are still fully supported, and they’re often the right call for sites that lean on custom PHP or older plugins. But new builds — and any project where the client wants hands-on visual control – are leaning toward block themes. That’s simply where WordPress is putting its energy. 

Why Starter Themes Have Replaced Monolithic Themes

There’s a market reason big, heavily styled themes aren’t as common anymore: site owners expect to control their own design. Back when the Customizer was the only visual tool around, a theme’s built-in styling was most of its value. Now the Site Editor lets non-developers change colors, layouts, and fonts directly. A WordPress theme that locks those choices down in 2026+ just gets in the way.

That’s pushed the market toward lightweight starter themes and frameworks; tools that give you structure without dictating the design:

• Underscores (_s) — Automattic’s classic, bare-bones starter. Still a common starting point for PHP-based builds.
• Create Block Theme — the official WordPress.org plugin for building and exporting block themes right from the Site Editor.
• Bricks Builder — a visual, developer-friendly builder popular with agencies that want speed without giving up code-level control.
• GenerateBlocks / Kadence Blocks — lightweight block libraries that extend the native editor instead of replacing it.
• Genesis Framework — a long-running foundation built for performance and SEO, still used for classic PHP builds.

The pattern is the same everywhere: developers build the skeleton. Clients fill in the design using tools that simply didn’t exist a few years ago. Or, for agencies, developers build the skeleton; front-end designers create the look.

The New Theme Development Stack

If theme development in 2018 meant PHP, Sass, and jQuery, today’s version looks more like this: Gutenberg (FSE), React, CSS/Tailwind, Dynamic Blocks, and Block Patterns.

Gutenberg

The block editor isn’t just a feature anymore — it’s the foundation almost everything else sits on. Post content, page templates, the Site Editor itself. If you want to build custom functionality, you need to understand how blocks work.

React

Gutenberg’s editor is a React app, and custom blocks are built with WordPress’s own React packages (@wordpress/blocks, @wordpress/block-editor, @wordpress/components). Want to build something beyond what native blocks or page builders offer, like a custom pricing table? You’ll write React and register it through the Block API. Not a shortcode. Not a widget.

CSS/Tailwind

Visual editors and theme.json handle a lot of layout work now, but they don’t replace real CSS knowledge. Custom block styling and tricky responsive layouts still need a developer who can go past what the Styles panel offers. Tailwind shows up a lot in custom blocks and headless front ends, even though block themes themselves lean on theme.json instead of utility classes.

Dynamic Blocks

Static blocks save their markup right into the post. Dynamic blocks are rendered on the server with PHP, at the moment someone loads the page. You need these for anything showing live data: recent posts, current stock, traffic on maps, you get it: personalized content.

Block Patterns

Block Patterns take a page out of Tailwinds’ book (hello, UI Block). Patterns are ready-made groups of blocks — a hero section, a pricing table, a team bio layout — that users drop in and customize. A strong pattern library matters as much as a strong set of templates now, because patterns are how most people build pages today.

The Rise of Page Builders (Beaver Builder, WPBakery, GenerateBlocks, Kadence)

Page builders haven’t gone away just because block themes exist (reddit thread). If anything, the two have grown closer together. Beaver Builder, WPBakery, et al build on top of, or work alongside, the block editor now, instead of sitting completely outside it..

GenerateBlocks and Kadence Blocks take a lighter touch, adding blocks to Gutenberg rather than replacing the whole editing experience.

For developers, this means picking a lane matters more than it used to. “WordPress developer” used to be one job. Now the market rewards people who go deep in one specific area — Block Pattern Libraries, custom Beaver Builder modules, native block themes — over people who dabble in all of them.

You can see this in how developers talk about their own work, too: the ones who’ve shifted toward complex customization, site migrations, and ongoing maintenance (instead of competing head-to-head with drag-and-drop tools on basic builds) say the work isn’t drying up. It’s just moving toward higher-value jobs.

Whether a page builder is even the right call for your project is worth thinking through first. We cover that in more detail in Should You Use a WordPress Page Builder or Not?

Headless WordPress: When Themes Aren’t Even the Frontend

For some projects, the whole theme question doesn’t apply, because WordPress isn’t rendering the site at all. In a headless setup, WordPress just manages content. Its REST API or WPGraphQL exposes that content, and a separate framework — Next.js, Nuxt, Astro, or similar — handles everything you see.

Headless makes sense when:

• The front end needs to be very fast or highly interactive (think: complex filtering, app-like features, real-time data).
• The same content must power more than one front end — a website, an app, a kiosk.
• Your dev team is JavaScript-first and wants full control over how things render, rather than working inside a theme’s limits.
• Your marketing team needs to be able to publish without breaking the site. 

It’s a real trade-off, not a free upgrade. Headless setups usually mean two deployments instead of one, more work to get previews right, and a higher setup cost. Worth it for the right project. Overkill for a small business site that a good block theme already handles well.

The main point here: headless doesn’t compete with block themes. It sits next to them as a different answer to a different problem. Both are proof that “theme development” has gotten bigger, not smaller.

Is There Still a Market for Premium Themes?

Yes, there’s still a market for premium themes but it looks different now. The old model (buy a heavily designed theme, activate it, tweak it lightly through the Customizer) is fading. It just doesn’t match how much control the Site Editor gives people directly. A theme that locks design decisions behind its own custom panel feels outdated next to one that uses WordPress’s native tools.

What’s replacing it: premium block theme collections and pattern libraries built specifically for FSE. They’re sold less as “your whole site, done” and more as a solid, well-coded starting point plus a big library of ready-to-use patterns.

Theme shops that adapted early – building cleanly on theme.json, shipping patterns, working with the Site Editor instead of against it — are doing well. The shops still stuck selling classic, Customizer-only themes are the ones actually losing ground. Which fits the bigger point of this whole article: it’s a shift, not a death.

What This Means for Developers

“Master Block Themes: Become proficient in block theme development and the Gutenberg editor.”
Rocket.net – Top 7 WordPress Theme Development Trends in 2025

The bar has moved, not disappeared. If you want to stay relevant in theme and front-end work, focus on this, roughly in order:

1. Learn block theme structure. Build one from scratch using theme.json, template parts, and the Site Editor. Do it as a real project, not just a tutorial. WordPress’s own block theme docs are the best place to start.
2. Get comfortable with React and the Block API. You don’t need to become a full-time JavaScript engineer. You do need to register a custom block, handle attributes, and work with InspectorControls.
3. Go deep on theme.json. Settings, styles, custom presets, and how they flow into the editor and the live site; this is core knowledge now, not an advanced topic.
4. Pick a specialty. Native block themes, one specific page builder, or headless front-end work. Trying to be equally strong at all of them is harder to sustain, and harder to sell, than going deep on one.
5. Don’t drop PHP. Dynamic blocks, custom post types, REST API endpoints, performance tuning – that’s all still PHP. It’s not being replaced. It’s working alongside the new stack.

What This Means for Agencies

Position yourself as the agency who fixes what page builders can’t handle.

For agencies, the shift moves where the billable hours come from; it doesn’t remove them. Basic “install a theme, tweak the colors” work is now something clients expect fast and cheap, since the Site Editor made a lot of that self-serve. The higher-margin work has shifted toward:

• Custom block libraries and design systems built for a client’s brand, reusable on future projects.
• Database Migrations — moving sites off heavy page builders and onto clean block themes, or onto headless setups and back again.
• Performance and technical audits, since Core Web Vitals and hosting setup now decide whether a “modern” WordPress site actually feels modern.
• Ongoing retainer work: maintenance, security, and small feature builds for sites that started as DIY projects and outgrew that setup.

Agencies that reposition around this kind of work, instead of competing head-on with page builders on basic builds, tend to report steady or growing demand.

What This Means for Site Owners

If you’re picking a theme, not building one, here’s the short version:

• Go with a block theme for new builds. You get more direct control with no code, and it’s where WordPress is putting its development energy.
• Check Site Editor support before you buy. If a theme routes major customization through its own custom panel instead of the native Styles interface, expect friction later.
• Don’t assume “page builder” and “block theme” are opposites. Many builders now work with the block editor instead of replacing it. Ask specifically how a theme handles global styles and whether it plays nicely with theme.json.
• Match the tool to the site, not the trend. A small business site rarely needs a headless build. A busy publisher or a product with lots of interactive features might.

Want a deeper walkthrough of what actually matters when picking a theme – budget, support, performance, design flexibility?

Check out Top 5 Considerations for Picking the Best WordPress Theme.

WordPress Theme FAQs

Is WordPress theme development dying?

No. Development is shifting from complete, static themes toward block themes, custom blocks, patterns, and, for some projects, headless front ends. The skills changed more than the demand did.

What’s the difference between a classic theme and a block theme?

Classic themes use PHP template files, functions.php, widgets, and the Customizer. Block themes use HTML templates built from blocks, work with the Site Editor, and use theme.json for global styles. Classic themes don’t support the Site Editor at all.

Do I still need to know PHP for WordPress theme development?

Yes. PHP still runs dynamic blocks, custom post types, template logic, and most of WordPress’s backend. What’s changed is that PHP now works alongside React and JSON config files, instead of being the only language in the stack.

Are page builders like Beaver Builder and WPBakery replacing block themes?

Not really. They’re increasingly built to work with the block editor, not around it. Which one makes sense depends on your project and your team’s existing skills.

Is headless WordPress necessary for a modern website?

No. It’s the right call for specific needs: very high performance requirements, heavy interactivity, or content shared across multiple platforms. Most business and content sites do just fine with a well-built block theme.

What should a WordPress developer learn first to stay current?

Start by building a block theme from scratch with theme.json and the Site Editor. Then move into custom block development with React and the Block API.

Final Thoughts

The “WordPress is dying” story mixes up two very different things: how healthy the platform is, and how people build on it. WordPress still runs a huge share of the web, and the core team has spent years actively investing in the block editor, Full Site Editing, and theme.json. That’s not what a dying platform looks like. That’s a platform deliberately rebuilding its own foundation.

What actually died is the idea that a theme should be one big, static, all-in-one product. What replaced it is more flexible, easier for site owners to control, and — if you’re willing to update your skills — honestly, more interesting to build. Themes aren’t dead. They just stopped looking like themes used to.

Fast & Secure Hosting? Yes, Please!

Grow your business with lightning-fast, secure, and optimized websites that are easy to set up & manage. Top-tier agencies and online businesses choose Rocket.net as their trusted managed WordPress hosting provider – why shouldn’t you, too?