When clients ask whether they should go headless, my answer is almost always "no." Not because headless WordPress is bad — it isn't — but because the costs are real and the benefits are usually attainable through simpler means. Here's the framework I use to decide.
Headless WordPress separates the content management interface from the front-end presentation, typically by exposing content through the REST API or GraphQL to a separate front-end application built in React, Vue, Astro, or another framework. The promise: faster front-end performance, modern developer tooling, and the ability to decouple content from presentation.
The reality is more nuanced. Most projects considering headless WordPress are reaching for a solution to problems they don’t actually have — and would be better served by an API-first architecture on the WordPress monolith. The performance gains are often modest once you account for proper caching. The developer experience improvements come with operational complexity: now you have two systems to deploy, two systems to monitor, two systems to keep secure. And the “decouple content from presentation” benefit assumes you’ll use that content in multiple places — which most sites don’t.
When headless actually makes sense.
There are situations where headless is the right call. The clearest signals:
- You’re publishing the same content to multiple frontends — a website, a native app, a third-party platform.
- Your frontend requires interactivity that genuinely benefits from a JavaScript framework: complex state management, real-time features, offline support.
- You have a frontend team that knows React or Vue better than they know WordPress, and a backend team to match.
- Performance requirements exceed what a well-tuned monolithic WordPress can deliver — and you’ve actually measured this, not assumed it.
If you don’t have at least one of those, the operational tax of running two systems almost always exceeds the architectural benefit. The right architecture for most projects is something closer to a well-designed WordPress platform with API-first discipline baked in — not a separate frontend layer.
The real cost of running two systems.
Conversations about headless tend to focus on benefits. The costs are usually understated until they’re undeniable:
- Two deployments. Every release ships in two places. Versioning gets harder. Previews require both systems to be running. The CI/CD pipeline doubles in complexity.
- Two security surfaces. WordPress and the frontend each have their own dependencies, their own patch cadence, their own CVE pipelines. The work doubles.
- Two monitoring stacks. Errors in the frontend look different from errors in WordPress. You need observability on both.
- Two teams, or two skill sets. A WordPress developer who’s also fluent in modern React is rare and expensive. Most organizations end up needing both a WordPress specialist and a frontend specialist — at minimum.
- Two debugging contexts. “The site is broken” now requires answering “in WordPress or in the frontend?” before triage can even start.
These costs are sustainable when there’s actual headless value to offset them. They’re crushing when there isn’t.
A practical comparison.
| Dimension | Traditional WordPress | API-first WordPress | Headless WordPress |
|---|---|---|---|
| Initial cost | Lowest | Moderate | Highest |
| Complexity | Single stack | Single stack, clean architecture | Two stacks, two teams |
| Performance | Good with caching | Same or better | Best in theory; varies in practice |
| Frontend flexibility | Theme-bound | Theme-rendered, APIs ready for future use | Maximum (React, Vue, anything) |
| Time to launch | Fastest | Slightly slower than traditional | Significantly slower |
| Ongoing maintenance | Single system | Single system | Two systems, indefinitely |
| Right call when | Simple to mid-complexity sites | Most platform engagements | Multiple frontends or extreme requirements |
A note on the “modern frontend” argument.
The argument that “headless is more modern” is one of the weakest reasons to choose it. Modernness isn’t an architectural property, it’s a developer aesthetic. The fastest, most maintainable WordPress sites I work on use server-rendered HTML enhanced with progressive JavaScript. They’re plenty modern. They just don’t look like the architectural diagrams in conference talks.
The cost of choosing architecture for aesthetic reasons is paid in maintenance, hiring complexity, and operational overhead — every quarter, for as long as the architecture lasts. That’s a steep price for “modern.”
API-first as the middle path.
For most projects, API-first architecture on the WordPress monolith captures the real benefits of headless without the operational overhead. What that means in practice:
- Design your content model and access patterns assuming everything is accessed through the REST API, even when the current frontend renders server-side.
- Build admin tools and editorial workflows that use the same APIs your frontend would.
- Use a structured content model — flexible content layouts your team can actually edit — that produces clean data the API can serve without transformation.
- Cache aggressively at the API layer, not just at the page layer.
- Document the API surface as if a separate frontend already existed. Future-you will thank past-you.
This gives you the architectural cleanliness of headless: well-structured data, clean separation of concerns, the ability to add a separate frontend later — without immediately requiring it.
The right time to go headless is when you actually have a second frontend that needs the same data, not before.
The bigger point.
Architecture decisions compound. The “modern” choice today is the maintenance burden in three years. The patient choice, building cleanly within the platform you already have, is usually the right one until specific evidence demands otherwise.
Most teams reach for headless because of an aspiration about where they want to be, not because of constraints from where they are. The aspiration is fine; the work to get there is real. Until you have the actual second frontend, the cleanest path is the API-first WordPress monolith. It’s faster to build, cheaper to maintain, and easier to evolve when (or if) the second frontend ever materializes.
Frequently asked questions.
What’s the difference between API-first and headless WordPress?
API-first WordPress treats the REST API as the canonical access path to content, even when the site renders server-side. Everything is built so a future headless frontend could consume the same APIs. Headless WordPress goes further: the WordPress frontend isn’t used at all; a separate JavaScript application handles rendering. API-first gets you the architectural cleanliness; headless adds operational complexity on top.
When is going fully headless actually worth it?
When you have an actual second consumer of the content — a native app, a third-party syndication, a customer-facing application — that justifies running two systems. Or when frontend interactivity requirements genuinely exceed what server-rendered HTML can deliver. “We might want one someday” isn’t a sufficient reason; “we have one in active development” usually is.
Can you go API-first now and headless later?
Yes — and this is usually the smarter path. If you architect API-first from the start, the data model and access patterns are already in place. Adding a separate frontend later is a matter of building the frontend, not redesigning the backend. Most teams who skip the API-first step and go straight to headless end up rebuilding their content architecture twice.
Does API-first help with Core Web Vitals?
Indirectly. The discipline of building API-first encourages cleaner separation between content and presentation, which makes performance optimization easier. The site still renders server-side, so LCP, INP, and CLS work is the same. But because the architecture is clean, the optimization work is faster and the results stick.