Every six months or so a client asks me whether they should go headless on their next WordPress build. Usually they have read something that made it sound like the obvious modern choice. Sometimes it is. Most of the time it is not.
I have built headless WordPress sites, rescued a few that went wrong and turned down jobs where the team asking for it did not need it. What follows is how I think about the decision when a client puts it to me.
What headless WordPress actually is
A standard WordPress site uses PHP to assemble the page on the server and ship HTML to the browser. The editor and the front end share the same codebase. A headless build keeps WordPress as the content store and admin, then serves the front end from a separate application, usually built in React or Vue, that pulls content from WordPress through an API. WPGraphQL is the common bridge. The front end is hosted somewhere else, often a node platform or a static host.
You end up with two applications instead of one. Two deploy pipelines, two sets of dependencies, two places where a bug can live. That is the trade you are making before anything else.
When headless WordPress earns its keep
There are roughly four situations where the extra complexity pays for itself.
The first is omnichannel content. You have a marketing site, a mobile app, a partner microsite and a customer portal that all need to share the same product data and editorial content. Headless lets one WordPress install feed all of them through the API. The editor writes once, the content shows up everywhere. If you only have a single website to feed, this argument disappears.
The second is a development team that already lives in the JavaScript world. If your engineers spend their days in React or Next.js and only touch PHP under protest, headless reduces friction. You let WordPress do what it does well, content modelling and editorial and let your team build the front end in a stack they enjoy and ship faster in. If your team is full of seasoned PHP developers, headless adds friction rather than removing it.
The third is genuine performance pressure at scale. A high-traffic content site with editors publishing dozens of times a day and millions of monthly visitors can benefit from a static or edge-rendered front end that serves pages from a CDN. Time-to-first-byte improves. The origin server stops being a bottleneck. For a five-page brochure site, modern PHP hosting handles the load fine and a CDN in front of a normal WordPress install does the same job with less plumbing.
The fourth is when the front end needs interactivity that standard WordPress themes struggle with. Configurators, dashboards, multi-step booking flows, anything where the page behaves more like an application than a document. A React front end fits that shape better than a templated theme.
When it does not make sense
A single marketing site for one brand, with a content team that uses Gutenberg, no mobile app and no other consumer of the content, is the wrong shape for headless. The cost of running two applications buys you nothing the content team can feel.
A small team without a dedicated front-end developer should not run a headless build. When a plugin update breaks something, you need a person who can debug both WordPress and the front end. A solo marketer with a monthly maintenance retainer cannot.
Projects that need to launch in six weeks should usually skip headless. The architecture adds setup, infrastructure decisions and a longer testing surface. A standard WordPress build with a well-chosen theme structure gets to the same outcome in less time.
Editor experience is the one most teams underweight. Gutenberg gives you live previews of how content looks on the actual page. A headless build breaks that link. The editor writes content in WordPress, then sees it on the front end after a build or a preview environment refreshes. There are ways to bridge the gap, preview deployments, custom block previews, but none of them are as fluid as editing directly in the rendered theme. If your editors care about visual editing, headless is a step backwards.
The plugin compatibility risk
WordPress plugins assume they are running inside a WordPress theme. They enqueue scripts and styles. They output HTML in hooks. They render shortcodes that expect the theme to render them.
On a headless build, a lot of that does not work. Forms plugins, popup builders, page-level analytics plugins, anything that injects content on the front end, all need either a headless-aware equivalent or a custom front-end implementation. WPGraphQL covers core content and most ACF fields, but bespoke plugin output frequently has to be rebuilt on the front-end side.
Before committing to headless, list every plugin currently in use and check whether each one has a headless story. The answer for some will be "rewrite that feature ourselves on the front end". That is a real cost.
Hosting implications
A standard WordPress site runs on one host. A headless build runs on at least two. WordPress sits on managed PHP hosting somewhere, often a stripped-back configuration since the front end is not served from it. The front end sits on a node platform or static host with its own pricing model.
WP Engine Atlas is the obvious option if you want both sides under one vendor. It pairs managed WordPress with a node front-end host and a global CDN. Other teams pair a regular WordPress host with Vercel or Netlify on the front end. Either model works. Both cost more in total than running one WordPress install and both need someone who understands two deploy pipelines.
The total cost of a headless setup, hosting plus extra engineering plus longer maintenance windows, is usually two to three times the equivalent monolithic site. That is not a problem if the project justifies it. It is a real problem if it does not.
How I tell a client which way to go
I ask four questions. Do you have more than one front end consuming the content. Does your team already build in JavaScript. Do you have performance or interactivity requirements that a standard WordPress build cannot meet. Are you willing to fund the ongoing engineering cost of running two applications.
Two or more yeses, headless is worth a serious look. One yes or none, monolithic WordPress is almost certainly the better fit. If the brief is genuinely complex content modelling rather than headless rendering, I will sometimes suggest looking at Craft CMS instead, since it solves a different shape of problem more cleanly. I have written about what changes when a business moves from WordPress to Craft, if that is the question on the table.
If you want a sanity check on whether headless is right for your next project, get in touch and I will tell you what I think. If a standard WordPress build is the right answer, you can see what WordPress development looks like in practice. If Craft is the better fit, Craft CMS work is on the same site.
Frequently asked questions
Is headless WordPress always faster than standard WordPress?
No. A well-configured standard WordPress site with a CDN in front of it is often within a small margin of a headless build for typical marketing sites. Headless pulls ahead at scale, with very high traffic and frequent publishing, or when the front end can be served statically from the edge. Below that scale, the difference is small enough that the operational cost of running two applications outweighs the speed gain.
What happens to my plugins on a headless WordPress site?
Plugins that handle content modelling and admin behaviour, like ACF or post type managers, work fine. Plugins that render output on the front end, like forms, popups, analytics injectors and page builders, need a headless-aware equivalent or a custom implementation on the front end. Auditing the existing plugin list is one of the first jobs on any headless migration.
Do editors still get a preview on a headless WordPress site?
Yes, but it is rarely as smooth as standard WordPress. Preview environments can be wired up so the front end renders draft content and WP Engine Atlas and similar platforms have done work in this area. The link between editing in Gutenberg and seeing the rendered result is still less immediate than on a monolithic build and that is the biggest editor-experience cost of going headless.
When should I look at Craft CMS instead of headless WordPress?
When the underlying problem is complex content modelling rather than the rendering layer. Craft handles structured content, multi-site setups and editorial workflows more cleanly than WordPress, monolithic or headless. If a client is reaching for headless WordPress because their content architecture is painful, Craft is often the answer they actually want.
Not sure whether headless WordPress is right for you?
Tell me what the project needs to do and I will tell you honestly whether headless earns the extra cost or whether a standard build will do.
Get in touch
