Back in August 2023 we published a guide to headless WordPress. It held up reasonably well on the concepts. On the specifics, it has aged badly, and we'd rather say so plainly than quietly delete it.

That post recommended Frontity, a framework that Automattic had acquired and effectively abandoned in 2022; the project had no meaningful development by the time we published, and it was formally discontinued not long after. It recommended Gatsby, which has since drifted into maintenance mode following Netlify's acquisition, to the point where its own community openly asks whether the project is dead. It pointed readers to Strattic for hosting, a service that has since been sunset, and to WP Engine Atlas, which still exists but now goes by the rather less memorable name of the Headless Platform. Even our headline statistic, that WordPress powered "nearly 40% of websites", is out of date.

So here's the full rewrite: what headless WordPress actually is, what's changed since 2023, the honest pros and cons, and, crucially, whether you should do it at all. Spoiler: our answer in 2026 is more nuanced than it used to be.

What headless WordPress is, in plain English

A traditional WordPress site does two jobs at once. It's the place where your team writes and manages content, and it's also the thing that builds the actual web pages your visitors see, using themes and plugins.

Headless WordPress splits those jobs apart. WordPress keeps doing what it's genuinely good at, giving editors a familiar place to write, organise and publish content. But the public-facing website, the "head", is built separately by developers using a modern front-end framework, and it fetches content from WordPress over an API.

Some quick jargon translation

• API (Application Programming Interface)
  An agreed way for two pieces of software to talk to each other. Here, it's how your website asks WordPress for content.
• REST API
  The version built into WordPress since 2016. Your front end requests a URL and gets structured data back, rather than a finished web page.
• GraphQL
  An alternative query language for APIs. Instead of making several requests and receiving more data than you need, you describe exactly the data you want (this post's title, author and first image, say) and get precisely that in one request. In WordPress land, the WPGraphQL plugin provides this.
• Decoupled
  Simply means the front end and back end are separate systems. "Headless" and "decoupled" are used more or less interchangeably.

That's it. No magic, just a separation of concerns.

What's changed since 2023

Quite a lot, which is exactly why this rewrite exists.

The tooling shakeout finished

Frontity is gone. Gatsby is technically alive but effectively frozen, and we wouldn't start a new project on it. Strattic has been shut down. The survivors are the boring, well-backed options: Next.js, Astro, and the WordPress REST API and WPGraphQL underneath them.

Honestly, that consolidation is healthy. Choosing a headless stack in 2026 is easier than it was in 2023 precisely because there are fewer plausible-but-doomed contenders.

WPGraphQL became first-party, in effect

In October 2024, WPGraphQL's creator Jason Bahl moved from WP Engine to Automattic, putting WPGraphQL on the path to becoming an official Canonical Community Plugin on WordPress.org. It remains community-owned and isn't merged into WordPress core itself, but for anyone betting a production site on it, having official ecosystem backing is a meaningful reassurance.

WordPress had its very public family row

In late 2024, a dispute erupted between Automattic and WP Engine, one of the biggest WordPress hosts, complete with blocked access to WordPress.org resources and duelling lawsuits. Courts ordered access restored, and while the litigation was still grinding on into 2026, the day-to-day disruption has largely settled.

We mention it because it rattled a lot of clients, and because it's a fair reminder that "open source" doesn't mean "free of governance risk". It hasn't changed our technical advice, but it has made some organisations think harder about how much of their stack depends on any one ecosystem.

Faust.js grew up and slimmed down

WP Engine's headless toolkit, Faust.js, is being reworked from a Next.js-only framework into a lighter, modular set of packages with adapters planned for Astro and SvelteKit as well. Notably, its preview functionality has been extracted into a standalone plugin, which helps with the single biggest headless pain point (more on that shortly).

The block editor matured, and AI arrived

WordPress's Gutenberg editor and site editor are now genuinely capable, and the project has been shipping AI features: the experimental Telex tool for generating custom blocks from plain-language prompts, and an Abilities API being developed for WordPress core that would let AI agents interact with WordPress programmatically.

Here's the uncomfortable bit for headless fans: most of that investment assumes WordPress is rendering your front end. Go headless, and you're opting out of a growing share of what WordPress ships.

The market share figure moved, in both directions

WordPress now powers about 41.5% of all websites, and 59.2% of sites with a known CMS. That's higher than the "nearly 40%" we quoted in 2023. WordPress actually kept growing through to a peak of around 43.2% in late 2025, but it has been declining steadily through the first half of 2026, dropping over a percentage point since December.

Still utterly dominant, but no longer on the trajectory it was. Still utterly dominant, no longer quite unassailable.

The honest pros

These were true in 2023 and they're still true now.

Speed, when done well

Modern front-end frameworks can serve pre-rendered, cached pages from a CDN (a network of servers close to your visitors). In our experience, the performance gap over a plugin-laden traditional WordPress theme is real and measurable, though we'd add a caveat the 2023 post didn't: a well-built, well-hosted traditional WordPress site can also be fast. Headless raises the ceiling; it doesn't excuse bad engineering.

A smaller attack surface

Your public site is essentially static files and API calls. The WordPress admin can sit behind a firewall or on a private URL, invisible to the drive-by exploit scanners that hammer every wp-login.php on the internet. That doesn't make you unhackable, but it removes the most common attack routes.

Content that travels

Publish once in WordPress, and the same content can feed your website, a mobile app, digital signage, whatever comes next. If you genuinely have multiple channels, this is the killer feature.

Total design freedom

Your front end isn't constrained by themes, page builders or WordPress's rendering pipeline. If you can build it in Next.js or Astro, you can ship it.

Editors keep an editor they know

This one matters more than any technical benefit. If your team has ten years of muscle memory in WordPress, headless lets you modernise the front end without retraining anyone.

The honest cons

This is where we'll be blunter than we were in 2023.

You now run two systems

Any headless architecture splits your stack into two parts: the CMS backend and the front-end host. But with WordPress, you carry the infrastructure weight of that backend. You still have to manage PHP versions, monitor database performance, and patch plugin security flaws. Managed SaaS options like Sanity or Payload handle that core engine maintenance for you. The real question isn't "one system or two?" It's whether your team wants to spend time patching server-side security vulnerabilities at 11 PM.

You need real developers, permanently

Not just for the build. Every new content feature, every layout change, every "can we just add a banner?" request touches code. The self-serve quality that made WordPress popular in the first place is substantially reduced.

The editing experience takes a genuine hit

We'll be honest about this because plenty of agencies aren't.

In traditional WordPress, an editor clicks Preview and sees exactly what will publish. In headless WordPress, the thing rendering the page lives in a different system, so previews don't work out of the box.

Solutions exist:

• Faust.js has decent preview support.
• The extracted previews plugin helps.
• You can wire up draft preview routes in Next.js yourself.

But every one of these is something a developer must build and maintain, and even the good implementations rarely match the immediacy of native previews.

The block editor makes this sharper, not softer: editors compose rich layouts in Gutenberg, then discover the headless front end renders those blocks differently, or not at all.

Budget for this properly, because it's the thing editors will complain about six months in.

You lose most of the plugin ecosystem

Plugins that render anything on the front end (forms, sliders, SEO output, e-commerce templates) either need headless-aware alternatives or have to be rebuilt in your front end.

The 60,000-plugin catalogue that justifies choosing WordPress shrinks dramatically the moment you go headless.

How we'd build it in 2026

If headless WordPress is the right call, this is the stack we'd reach for at Lemon Hive:

WordPress as the content hub

• Kept lean.
• WPGraphQL for the API layer (or the native REST API for simpler builds).
• Advanced Custom Fields to model structured content properly.
• As few front-end-rendering plugins as possible.

Front end

• Next.js for most builds.

The safest, best-supported pairing.

Incremental static regeneration (pages rebuild themselves when content changes, so you get static speed without stale content).

Mature preview tooling.

• Astro

Our pick for content-heavy marketing sites where interactivity is light because it ships dramatically less JavaScript.

• SvelteKit

Used where a client's team already lives there.

Hosting

• Vercel, Netlify or Cloudflare for the front end.
• Managed WordPress hosting behind it.
• WP Engine's Headless Platform (formerly Atlas) as a sensible single-vendor option if you'd rather one throat to choke.

Preview and editor experience

Budget this as a feature, not an afterthought:

• Draft preview routes.
• On-demand revalidation when editors hit publish.
• Honest conversations up front about what the editing workflow will feel like.

Who should go headless, and who should skip WordPress entirely

Here's the position that's changed most since 2023, and it cuts against our own commercial interest in bigger builds, so take it as sincere.

Headless WordPress makes sense as a pragmatic stepping stone

If you're an organisation with years of content, trained editors and workflows embedded in WordPress, going headless lets you modernise performance and front-end architecture without ripping out the tool your team knows.

That's a genuinely good trade, and we've made it work well for clients.

For greenfield builds, we'd almost always choose a purpose-built headless CMS instead

Sanity and Payload are our usual picks.

The reason is structural, not fashionable: WordPress fundamentally thinks in pages and posts, because that's what it was built to render.

When you want proper structured content (reusable product data, relationships between entities, content modelled around meaning rather than layout), you end up fighting WordPress's page-shaped view of the world, bolting on custom field plugins to approximate what purpose-built systems give you natively.

Sanity and Payload were designed API-first, so previews, structured content and developer workflows are core features rather than retrofits.

Plenty of sites shouldn't decouple at all

If you run a content site with one channel, a small team and no unusual performance ceiling, a well-built traditional WordPress site is simpler, cheaper and easier to live with.

Headless for its own sake is how you end up paying agency retainers to change a heading.

Our take

Headless WordPress in 2026 is a mature, viable architecture with consolidated tooling and fewer ways to pick a doomed framework than when we last wrote about it.

It's at its best for organisations with deep WordPress investment who need a faster, more flexible front end without retraining their editors.

It's at its weakest when treated as a default, because the preview pain is real, the maintenance burden is real, and purpose-built headless CMSes simply do structured content better than WordPress does.

We've built headless WordPress sites, traditional WordPress sites, and plenty on Sanity and Payload, so we're relaxed about which way your decision goes.

If you're weighing it up and want an opinion grounded in what actually breaks six months after launch, get in touch. We'll tell you honestly, even if the answer is "don't".