Headless WordPress shows up in a lot of conference talks and agency pitch decks. The premise sounds great: keep WordPress as a content backend, render the front end with a JavaScript framework, and get a faster, more flexible site. For some teams that is exactly right. For most WordPress site owners, it is a lot of new complexity in exchange for problems the traditional stack already handles.
What “headless” actually means
In a traditional WordPress setup, WordPress does two jobs: it stores your content in the database, and it renders the HTML your visitors see, using PHP templates, themes, and the REST API only for auxiliary things like the block editor. In a headless setup, WordPress keeps the first job and hands off the second one. Some other application, usually built in a framework like Next.js or Nuxt, pulls content out of WordPress through the REST API or GraphQL (via a plugin like WPGraphQL) and renders the front end itself, often on a completely separate hosting platform.
WordPress becomes a headless CMS: an admin panel and a content API, nothing more. The visitor never touches a WordPress-rendered page.
What it genuinely buys you
The case for headless is real, not imaginary. It just applies to specific situations.
- Front-end flexibility. If your team already builds in React or Vue and wants full control over component architecture, animations, and app-like interactions, decoupling lets you do that without fighting WordPress’s PHP templating model.
- Multi-channel content. If the same content needs to power a website, a mobile app, and maybe a kiosk or a partner integration, a single content API feeding multiple front ends is cleaner than maintaining parallel WordPress themes.
- Static or edge-first delivery. Some headless setups pre-render pages to static HTML and serve them from a global edge network, which can produce extremely fast Time to First Byte for content that does not change often.
- Separation of concerns for large teams. Content editors work in WordPress, front-end developers work in their own repo and deploy pipeline, and the two teams rarely block each other.
None of that is fashion. It is a legitimate architecture for the right problem.
The hidden costs nobody puts on the slide
Here is what tends to get left out of the pitch: WordPress already solved a lot of problems that headless reintroduces, and now you have to solve them again yourself, usually with less mature tooling.
Preview and editorial workflow
In a normal WordPress install, clicking “Preview” just works. In a headless setup, your front end and your CMS are different applications, so previewing a draft means building a preview mode that authenticates the request, fetches unpublished content from the API, and renders it through your custom front end, usually with its own caching layer bypassed. This is solvable, but it is real engineering work, not a checkbox.
Plugin compatibility
A huge share of the WordPress plugin ecosystem assumes it can hook into wp_head, enqueue scripts, or render its own markup directly into a page template. SEO plugins that generate schema markup, page builders, forms plugins with client-side validation, membership plugins that gate content by rendering different HTML: many of these either do not work headless at all or require you to manually reimplement their output in your front end. You do not just lose convenience here, you lose entire categories of “install and forget” functionality.
Authentication and forms
Login, comments, and form submissions all assumed a server-rendered page with a session. Headless breaks that assumption. You will typically need a separate authentication flow (often JWT-based) between your front end and WordPress, plus custom handling for anything that used to be a simple POST to admin-post.php. Contact forms, in particular, often need custom API endpoints instead of the plugin’s built-in handling.
Caching, twice
Traditional WordPress hosting solves page speed with full-page caching (LiteSpeed Cache pairs naturally with a LiteSpeed server for this) plus persistent object caching through Redis or Memcached as a drop-in, and a CDN like Cloudflare in front for edge caching, WAF protection, and HTTP/3. In a headless setup you still need caching, but now it is split across two systems: WordPress’s own API responses need caching, and your front-end framework needs its own rendering and data-fetching cache strategy. You have not eliminated the caching problem, you have doubled it and split it across two codebases.
Two things to keep secure and updated
You now maintain a WordPress install (PHP, plugins, core, on the mainstream PHP 8.1 to 8.3 range most hosts run today) and a separate JavaScript application with its own dependency tree, its own hosting platform, its own deployment pipeline, and its own security patching cadence. That is genuinely more surface area to manage, not less.
Who genuinely needs it
Headless makes sense when one or more of these is true for your project:
- You are shipping content to more than one front end (web, native app, third-party integration) from a single source of truth.
- Your front-end team is already deeply invested in a JavaScript framework and has the capacity to build and maintain preview, auth, and form handling themselves.
- Your traffic and interaction patterns genuinely demand an app-like, highly interactive front end that a traditional theme cannot deliver well.
- You have a dedicated engineering team, not just a site owner and a few plugins, because someone has to own that second application indefinitely.
If none of that describes your situation, you are very likely better served by traditional WordPress, tuned properly.
The middle ground most sites actually need
Before reaching for headless to solve a performance complaint, it is worth checking whether the traditional stack, configured well, already gets you where you need to be. A well-cached WordPress site running PHP 8.3 with OPcache, LiteSpeed full-page caching, Redis object caching, and Cloudflare at the edge can comfortably hit good Core Web Vitals numbers: an LCP at or under 2.5 seconds, INP at or under 200 milliseconds, and CLS under 0.1. That is the same performance bar headless sites are chasing, achieved without rebuilding your plugin ecosystem from scratch. A managed host that already runs this stack (ServerBorn’s setup is built around exactly this combination) removes most of the performance argument for going headless in the first place.
If you do decide to go headless, do it deliberately: budget for a second application’s worth of maintenance, plan preview and auth from day one, and audit your plugin list for anything that assumes server-rendered HTML before you commit.
Takeaway
Headless WordPress is a real, valuable architecture for multi-channel publishing and teams with dedicated front-end engineering. It is not a performance shortcut, and it is not free. For the majority of WordPress site owners, a properly tuned traditional stack, caching at the page level and the object level plus a solid CDN, delivers the speed and reliability people actually want, without taking on a second codebase to maintain.