"Let's go Headless!" I hear it more and more in agency technical briefs. But in most cases, Headless WordPress introduces costs, complexity, and fragility with no real return. Here's why.
1. What is Headless WordPress (in brief)
In a Headless architecture, WordPress is used only as a backend: it manages content through the dashboard, but doesn't generate HTML pages. The frontend is delegated to a separate JavaScript framework — usually Next.js, Nuxt, Astro, or Gatsby — which consumes content via REST API or WPGraphQL.
The idea is appealing: "use WordPress for what it does best (managing content) and a modern framework for rendering." In theory, it sounds perfect. In practice, you're building two applications instead of one.
2. Double stack: double complexity
A traditional WordPress is a single deploy: PHP, MySQL, a theme that generates HTML. A Headless WordPress is at least two separate projects: the WordPress backend (hosting, database, plugins, API) and the JavaScript frontend (Node.js, framework, build pipeline, separate hosting).
Two stacks mean:
- Two hosting environments to configure, monitor, and pay for.
- Two deploy pipelines with their respective CI/CD.
- Two skill sets required on the team (PHP + advanced JavaScript).
- Two points of failure. If the backend goes down, the frontend has no content. If the frontend breaks, the site is offline even if WordPress is working.
For a corporate website or a magazine, this complexity isn't justified. You're literally doubling the attack surface and operational costs to get... what exactly?
3. The performance myth
"Headless is faster!" It's the argument I hear most often, and it's the most misleading. Yes, a React/Next.js frontend can be blazing fast. But a traditional WordPress with good caching is blazing fast too.
A monolithic WordPress with a well-configured caching strategy (page cache, Redis object cache, CDN) serves static pages in 50-100ms TTFB. There's no user-perceptible difference.
The irony is that many Headless setups are slower than a cached WordPress. Why? Because the frontend has to make API calls to the backend for every request (or at build time with SSG), introducing network latency. And if you use ISR (Incremental Static Regeneration) with Next.js, you have a layer of complexity that often degrades performance on non-cached requests (stale content).
Core Web Vitals don't magically improve with Headless. They improve with good frontend architecture, image optimization, and server configuration — all things you can do perfectly well on a traditional WordPress.
4. Maintenance costs: the hidden bill
When you present the initial quote for a Headless project, the client sees a cost. What they don't see is the long-term maintenance cost, and that's where Headless really hurts.
- WordPress updates: Every major WordPress update can break the APIs. Custom fields change structure, REST APIs evolve, plugins update their endpoints. Every update requires testing on the frontend.
- Frontend updates: Next.js releases a major version roughly every year. Every upgrade may require refactoring. npm dependencies expire, vulnerabilities accumulate.
- Two hosting environments to maintain: The WordPress backend needs PHP, MySQL, SSL certificates. The frontend needs Node.js, build server, edge functions. Double the cost, double the monitoring.
With traditional WordPress, you pay for one hosting, update plugins, and the theme works. With Headless, every update is potentially a project in itself.
5. Editorial workflow: the real disaster
This is where Headless fails spectacularly, and it's the point agencies always underestimate. WordPress is loved by clients for a reason: the editor is intuitive. Gutenberg, with its blocks, lets you build pages visually. The client sees what they're doing.
In a Headless setup, the client opens WordPress and sees... custom fields. ACF, Meta Box, or custom fields with no visual context. They write text, save, and then... don't know how it looks. There's no real preview. No "see how it turns out" like in Gutenberg.
The workflow becomes:
- The client enters content in custom fields.
- Saves as draft.
- Has to go to a separate URL to see the preview (if it works).
- If something's wrong, goes back to the dashboard and guesses which field to change.
This is a 10-year step backward from the editorial experience WordPress natively offers. And the client definitely notices.
6. Preview and drafts: the Achilles' heel
Content preview is the most underestimated technical problem in Headless. In traditional WordPress, you click "Preview" and see the page exactly as it will appear. It just works.
In Headless, preview requires:
- A dedicated API endpoint for draft (unpublished) content.
- An authentication system between WordPress and the frontend for protected previews.
- Draft mode / Preview mode in the frontend framework (e.g., Next.js Draft Mode) to be configured and maintained.
- Handling JWT tokens or cookies to authenticate preview requests.
In practice, Headless preview is slow, often broken, and the first area where maintenance costs explode. I've seen projects where the preview simply "stopped working" after a WordPress or framework update, and nobody knows why.
7. The plugin ecosystem: goodbye
WordPress has 60,000+ plugins. Most of them work because they assume they're on a WordPress frontend. Forms, SEO, analytics, cookie consent, popups, membership: everything is built to integrate with the WordPress theme.
In Headless, you lose almost the entire ecosystem:
- Contact Form 7 / Gravity Forms: They don't work. You have to rebuild forms in the frontend and create custom API endpoints.
- Yoast / Rank Math: SEO meta tags have to be read via API and manually injected into the frontend. Features like the XML sitemap? Rebuild from scratch.
- WooCommerce: Works via API, but you lose the checkout, the cart, the entire user experience. Rebuilding a checkout in React is a project in itself.
- WPML / Polylang: Multilingual management has to be completely reimplemented in the frontend.
In practice, every plugin you used in traditional WordPress becomes a frontend component to develop from scratch. WordPress's speed advantage evaporates.
8. "WordPress as backend" - an illusion
The strong argument for Headless is: "Use WordPress for what it does best: managing content." But is that really true?
If you use WordPress only as a backend API, you're using maybe 20% of its capabilities. The theme? Useless. Templates? Not needed. Visual Gutenberg blocks? Not visible. Shortcodes? Don't work. The Customizer? Eliminated.
At that point, WordPress becomes a mediocre headless CMS compared to native solutions like Strapi, Sanity, Contentful, or Directus, which were born for that purpose and offer:
- Cleaner, better-documented APIs.
- Flexible content models without additional plugins.
- Native webhooks for rebuild triggers.
- No legacy PHP and template engine baggage.
If you truly want to go Headless, using WordPress as a backend is often the worst choice. It's like buying a Ferrari and using it only to carry grocery bags: it works, but you're paying for things you don't use and giving up things you need.
9. CV-driven development
Here we get to the central point, the uncomfortable one. Why do so many developers push for Headless?
In most cases, it's not because the project requires it. It's because the developer wants to work with React/Next.js. It's more technically interesting, looks better on the resume, and the market pays more for "modern" JavaScript developers.
This is CV-driven development: choosing technology based on what benefits the developer's career, not what serves the client's project.
Recognizing the pattern is straightforward:
- "It's more modern" — but the client isn't paying for modernity.
- "Performance will be better" — without concrete benchmarks to back it up.
- "This way we're ready for the future" — the future of which requirement, exactly?
- "It's the industry standard" — no, it's the standard of a specific segment (SaaS and large publishers).
A good consultant proposes the best solution for the client's problem, not the one that benefits them professionally. If a corporate or editorial website can be built and managed perfectly with traditional WordPress, proposing Headless is a disservice.
10. When Headless truly makes sense
I'm not anti-Headless. I'm anti-Headless where it's not needed. There are real scenarios where Headless architecture is the right call:
- Multi-channel publishing: If the same content needs to feed a website, a native mobile app, an in-store kiosk, and a newsletter, then an API-first backend makes sense. But do you really need all those channels?
- Complex web applications: If the frontend has heavy interactive logic (real-time dashboards, 3D configurators, SPA applications with complex state), a JS framework is justified — but at that point, maybe you don't need WordPress at all.
- Enterprise teams with dedicated resources: If you have a dedicated frontend team, a dedicated backend team, in-house DevOps, and budget for continuous maintenance, Headless becomes manageable. But we're talking about organizations with 10+ developers, not agencies with 3-5 people.
- Content that rarely changes: A documentation site with thousands of static pages and rare updates can benefit from an SSG build. But even here, good page caching on WordPress does the same job.
The key question is: does the architectural advantage of Headless justify the additional development cost, maintenance burden, and loss of usability for the client? In my experience, for 80% of projects the answer is no.
Verdict: power vs. pragmatism
Headless WordPress is a powerful technology. But "powerful" doesn't mean "necessary." For the vast majority of corporate websites, magazines, e-commerce, and editorial portals, a well-built traditional WordPress delivers:
- Excellent performance (with proper caching).
- Development and maintenance costs cut in half.
- Intuitive editorial workflow for the client.
- Full access to the plugin ecosystem.
- A single stack to monitor and maintain.
Before proposing Headless to an agency, ask yourself: are you solving a client's problem or a resume problem? The honest answer makes the difference between a sustainable project and technical debt disguised as innovation.