Going headless solves a real set of problems and creates a different one. Most sites that decommission their theme did not need to. Here is how to tell whether yours is the exception, and what the decision costs on both sides.
Headless WordPress has spent several years being recommended for reasons that do not survive contact with a real project. It is a genuinely good architecture for a specific set of problems, and an expensive way to solve problems that a decent theme and an afternoon of caching would have fixed.
This is the version of the comparison we give clients who ask, including the parts that argue against the more expensive option.
What headless actually means here
In a traditional setup, WordPress does everything: it stores the content, and its theme renders the HTML a visitor receives.
In a headless setup, WordPress keeps the content and the editing experience, and stops rendering pages. A separate front end — commonly Next.js — reads content through the REST API or GraphQL and renders the site itself. The theme is decommissioned, and everything the theme used to do quietly on your behalf becomes something a developer explicitly writes.
That last sentence is the whole trade, in both directions.
What going headless genuinely fixes
A front end that has outgrown page templates. If your site is really an application — configurators, dashboards, logged-in state, heavy interactivity — you will fight the theme layer forever. Building that in a modern React framework and treating WordPress purely as the content store is the right shape, and it is where headless is least arguable.
One content source, several destinations. A website, a mobile app, an in-store screen, a partner feed. Once content has more than one consumer, an API-first back end stops being an indulgence and starts being the only sane design. That is a straightforward API and integration problem.
Performance you control at the millisecond level. A decoupled front end lets you statically render, stream, cache at the edge and ship a fraction of the JavaScript. The ceiling is genuinely higher than a theme-based build.
Isolating the attack surface. With WordPress behind the network boundary and only a rendered front end exposed, the most common class of WordPress compromise — an internet-facing login and a vulnerable plugin — is materially reduced. It is not a substitute for security audits and hardening, but it changes the shape of the risk.
What going headless costs you
Editors lose the map. Live preview, the block editor rendering what will actually ship, drag-and-drop layout, an accurate link checker — all of it has to be rebuilt or given up. This is the single most common source of regret we see, and it appears three months after launch, not during it. If the marketing team currently builds landing pages without a developer, going headless takes that away unless someone funds a full preview and layout implementation.
Plugins stop working. Anything that outputs HTML — forms, sliders, SEO output, cookie banners, related posts, schema markup — assumes a theme. On headless it either has to be re-implemented in the front end or replaced with a service. Teams budget for the rebuild of their own templates and forget the eleven plugins doing invisible work.
You now run two systems. Two deploy pipelines, two dependency trees, two sets of security updates, two things that can break at 2am. WordPress 7.1 arrived in August 2026 and the core update cadence continues regardless of what is rendering your pages; the difference is that now a core or plugin change can break a front end built by a different team on a different schedule.
SEO becomes something you implement rather than install. Canonical tags, structured data, sitemaps, hreflang, meta output and redirects are all handled by plugins in a traditional build. Headless means owning them in code — perfectly achievable, and a frequent source of the traffic drops that get blamed on the migration. Anyone rebuilding this way should have technical SEO involved before launch, not after the rankings move.
The four cases where it is worth it
- The site is genuinely an application. Sustained interactivity, authenticated state, complex client-side behaviour. Build it as a web application and let WordPress be the content layer.
- Content feeds more than one surface. Two or more consumers of the same content, now or clearly on the roadmap.
- Performance is a revenue line and you have exhausted the ordinary fixes. You have already removed the page builder, optimised images, added object caching and cut the plugin count — and you still need more.
- The front-end team already lives in React. Where a company has in-house React capability, a decoupled front end can be cheaper to maintain than a theme nobody there wants to touch.
If none of these describe your situation, the honest recommendation is a well-built traditional theme, and the difference in budget spent on content and conversion work instead.
The middle path most sites should take first
There is a wide space between a classic theme and a full decoupling, and it is where most of the value sits.
- Block-based theme, no page builder. Modern block themes cover a large share of what page builders were invented for, without shipping their weight. Removing a builder is often the single biggest performance win available to a WordPress site.
- WordPress as a headless source for one part of the site. A product finder, a pricing configurator, a customer dashboard — build that as a React island fed by the API and leave the other 200 pages rendering as they do now.
- Serious caching before serious architecture. Full-page caching, object caching, edge delivery and image optimisation are days of work. Decoupling is months.
We would rather spend a client's budget on the middle path and be proven wrong in a year than spend it on a rebuild that was never the constraint.
How to decide in one meeting
Put four questions to the room and write the answers down.
- Who publishes on this site, and what will they lose? If the answer is a marketing team building pages independently, price the preview and layout work honestly before going further.
- What are we actually trying to fix, in a number? Load time, editorial velocity, a security finding, a channel we cannot currently serve. If nobody can state it as a number, the project is aesthetic.
- Have we exhausted the cheap fixes? Plugin audit, page builder removal, image pipeline, caching, hosting. If not, do those first — they cost a fraction and they tell you whether the ceiling is real.
- Who maintains two systems? Name the person or the retainer. Not a team, a person.
Sites that go headless on the strength of those four answers rarely regret it. Sites that go headless because it sounded modern spend the following year rebuilding editorial tooling that they used to get for free.
Questions we get asked
Is headless better for SEO? No — it is neutral, and riskier by default. The performance ceiling is higher, and everything a plugin used to handle now has to be implemented deliberately. Sites that lose traffic after going headless usually lost it to missing canonicals, metadata and redirects rather than to the architecture.
Can editors still preview content? Only if someone builds it. Preview against a decoupled front end is real engineering work, and it is the feature most often descoped under budget pressure and most missed afterwards.
What does it cost to maintain? Two update streams instead of one, and a front-end framework with its own release cadence. Budget for a periodic dependency upgrade on the front end as well as core and plugin maintenance on the WordPress side.
Is Next.js the only option? No, though it is the most common pairing and the one with the deepest ecosystem for this pattern. Astro suits content-heavy sites with limited interactivity and ships less JavaScript by default, which is an advantage for Interaction to Next Paint.
Can we go headless gradually? Yes, and it is usually the right answer — decouple one high-value section, keep the rest on the theme, and let the results argue for the next step.
If you are weighing this up, our WordPress development team scopes both routes against the same brief, so you can see the two numbers side by side before anyone commits to an architecture.
Looking for more? Browse all resources.