Headless WordPress: Powerful, but Often Unnecessary (and Expensive)

What Headless WordPress Actually Means

In a traditional WordPress setup, PHP renders your pages on the server and delivers complete HTML to the browser. Theme files control layout, styling, and logic. Everything lives under one roof.

In a headless architecture, WordPress becomes a content API only. The entire frontend—what users actually see and interact with—is built separately using frameworks like Next.js, Nuxt, Astro, or Gatsby. WordPress serves JSON data via REST or GraphQL, and the frontend consumes it.

It sounds elegant on paper. In practice, it means running two separate systems instead of one.

The Myth: "Headless = More Modern = Better"

This is the narrative you hear at conferences and read on agency blogs: headless is the future, monolithic is legacy, and if you are not decoupled you are behind.

But "modern" is not a feature. It is a marketing term. The question is never "is this modern?" but rather "does this solve a problem my project actually has?"

For a brochure site, a corporate website, or even a mid-complexity WooCommerce shop, traditional WordPress with a well-built custom theme is not "legacy." It is the right tool for the job—battle-tested, maintainable, and cost-effective.

Headless Means Double the Stack and Double the Complexity

With a traditional WordPress setup, your stack is straightforward:

• WordPress core (PHP)
• Theme (templates, CSS, JS)
• Plugins (extending functionality)

With headless, you suddenly need to manage:

• WordPress backend (still PHP, still needs updates)
• API layer (REST API or WPGraphQL configuration)
• Frontend framework (Next.js, Astro, Nuxt, etc.)
• Build pipeline (CI/CD for the JS frontend)
• Separate hosting (Vercel, Netlify, or custom Node server)
• Caching strategy (far more complex with two layers)
• Preview system (rebuilt from scratch)

This is not "more modern." It is more stuff to manage—more deployment pipelines, more potential points of failure, and more things that can break on a Tuesday afternoon when you least expect it.

Performance: Yes, but Only in Specific Cases

The number one selling point for headless is performance. And yes, a statically generated Next.js frontend served from a CDN edge can be incredibly fast. But here is what the pitch conveniently leaves out:

• A well-built custom theme with proper caching and image optimisation already scores 95+ on PageSpeed
• WordPress with a good hosting stack (e.g., Nginx + Redis + PHP 8.x) is already very fast
• The performance bottleneck is often the backend and database queries, not the frontend rendering
• If your headless frontend makes 200 API calls per page load, performance actually gets worse

Headless improves performance only when implemented correctly. And "correctly" means dedicated time, budget, and ongoing maintenance. For most agency projects, optimising the traditional stack yields the same results at a fraction of the cost.

Preview, Drafts, and Editorial Workflows: The Pain Point

This is where headless WordPress gets truly frustrating, and it is consistently underestimated.

In traditional WordPress, preview just works. Click "Preview," see the page exactly as it will appear. Drafts, revisions, scheduled posts—all built-in, all functional out of the box.

In headless, you need to rebuild all of this:

• Authenticated preview routes on your frontend
• Token-based authentication between WordPress and the JS app
• Dynamic routing for unpublished content
• Draft content handling—fetching unpublished posts via API requires special permissions
• User permissions mirrored across both systems

And even after all that work, the preview rendering often does not match the live frontend exactly. The client clicks "Preview" and sees something slightly different from what goes live. That erodes trust.

WordPress gave you all of this for free. With headless, you are paying to recreate what already existed.

Plugin Ecosystem: You Pay for WordPress but Lose WordPress

WordPress is powerful because of its ecosystem. Thousands of battle-tested plugins handle:

• SEO (Yoast, Rank Math)
• Forms (Contact Form 7, Gravity Forms)
• Multilingual (WPML, Polylang)
• Membership and access control
• Caching (WP Super Cache, WP Rocket)
• Redirects, custom post types, content management

In a headless setup, half of these plugins become useless or incomplete. Why? Because they generate HTML output that your frontend never renders. They control frontend behaviour that no longer exists.

Your SEO plugin still generates meta tags—but your React frontend ignores them. Your form plugin creates beautiful HTML forms—but they have no place in your Next.js app. You end up rebuilding form handling, SEO management, redirects, and multilingual routing in JavaScript.

The result? You pay for WordPress's licence, hosting, and maintenance, but you lose the very thing that makes WordPress worth using.

Deploy and Maintenance: The Real Cost Over Time

A traditional WordPress site after two years? You update core, update plugins, maybe refresh the theme. It still works. You can hand it to any WordPress developer and they will understand it immediately.

A headless WordPress site after two years? You are likely facing:

• Outdated JavaScript dependencies with security warnings
• Build pipelines that no longer work after Node version changes
• Deprecated packages that need replacing
• More frequent security patches across two systems
• Deploy failures from breaking changes in the JS ecosystem
• Sudden breakages after a Node.js or framework major update

This is the most brutally honest difference. The JavaScript ecosystem moves fast—and that speed is a liability when it comes to long-term maintenance. WordPress is boring, and boring is a feature for production systems.

The Risk of Overengineering Medium-Sized Projects

A headless frontend must handle everything that WordPress themes handle for free:

• API failures and timeouts—what happens when the WordPress backend is unreachable?
• Content fallbacks—graceful degradation instead of blank pages
• Cache inconsistency—stale content when the frontend cache and backend data diverge
• Cache invalidation—one of the hardest problems in computer science
• Deploy vs. publish timing—content published in WordPress does not appear until the frontend rebuilds

In practice, what was once a "simple website" becomes a distributed system. And distributed systems require distributed-systems thinking: eventual consistency, retry logic, circuit breakers, monitoring.

For a large-scale application, this is expected. For a 20-page agency website? It is overengineering, plain and simple.

The Elephant in the Room: CV-Driven Development

Let me say the quiet part out loud. A significant number of headless WordPress projects are not driven by project requirements. They are driven by developer preferences.

• The developer wants to work with Next.js and React
• The agency wants to say they do "Jamstack"
• The team wants to position themselves as modern
• Someone wants to avoid PHP—not because PHP is wrong for the job, but because it is unfashionable

None of these are project requirements. They are career requirements. And they are valid career goals—but they should never be the reason a client pays for a more complex, more expensive, harder-to-maintain architecture.

As professionals, we owe it to our clients to recommend the architecture that best fits their needs, not the one that looks best on our portfolio.

When Headless WordPress Actually Makes Sense

I am not anti-headless. I am anti-headless-by-default. There are legitimate scenarios where decoupled architecture is the right call:

• True web applications: dashboards, SPAs, or products with complex interactive UX that go far beyond content pages
• Multi-channel content delivery: the same content needs to serve web, native mobile apps, kiosks, or IoT devices via API
• Dedicated engineering teams: you have frontend and backend specialists with the budget for ongoing maintenance
• Extreme scalability needs: millions of page views requiring edge-cached static pages with advanced CDN strategies
• Clear separation of concerns: content publishing and digital product development need to operate independently

If your project ticks two or more of these boxes, headless is worth the investment. But these are minority cases in the WordPress ecosystem. The vast majority of WordPress projects are content-driven websites that are perfectly served by a well-built traditional setup.

If You Want a Headless CMS, Maybe Don't Use WordPress

Here is the uncomfortable question: if you have genuinely decided that headless is the right architecture for your project, why are you still using WordPress?

There are CMS platforms built headless-first:

• Strapi — open-source, self-hosted, API-first
• Directus — wraps any SQL database with a clean API
• Sanity — real-time collaboration with a powerful query language
• Contentful — enterprise-grade SaaS with rich content modelling

These tools were designed from scratch to be headless. Their APIs are cleaner, their content modelling is more flexible, and they do not carry 20 years of PHP rendering assumptions.

Using WordPress headless is often an awkward compromise: you are bending a tool designed for server-rendered pages into something it was not built to be. It works, but it is never elegant.

Choose Based on the Project, Not the Trend

Headless WordPress is a valid architecture. It solves real problems for the right projects. But it is not a universal upgrade, and it is certainly not "WordPress done better."

For most agency websites, the traditional WordPress stack—custom theme, optimised hosting, proven plugins—delivers the same end result with less complexity, lower cost, and dramatically easier maintenance.

Before going headless, ask yourself three questions:

• Does my project have a genuine technical need that traditional WordPress cannot meet?
• Do I have the budget and team to maintain two separate systems long-term?
• Am I choosing this architecture for the project's benefit, or for my own?

If the answer to any of these is no, stick with what works. In technology, the best architecture is the one that solves the problem with the least unnecessary complexity.