Ask a JavaScript agency whether you should go headless and the answer is usually yes. Ask the person who has to keep the lights on after launch, and the answer gets quieter. Headless WordPress — WordPress as a content API behind a separately-built frontend — is a real architecture with real wins. But the marketing tends to price only the wins. This article prices the whole thing: the up-front build, the recurring infrastructure, the maintenance tax that nobody quotes you, and the traffic level at which it actually starts paying for itself.

The line item nobody quotes: you are now buying two stacks

A traditional WordPress site is one bill: hosting that runs PHP and MySQL, serves HTML, and renders the admin. Going headless splits that in two. WordPress still runs somewhere (it has to — it is your CMS and your editor login), and a second environment runs your frontend.

Concretely, your monthly infrastructure now looks like:

The WordPress backend — still on managed hosting (Kinsta, WP Engine, Cloudways, SiteGround), typically $30–$300/mo depending on traffic. You do not get to downgrade this just because visitors never hit it directly; editors, the API, and image processing all live here.
The frontend host — Vercel, Netlify, or Cloudflare Pages. The free tier looks generous until a real site uses it. Vercel's Pro plan starts at $20/seat/mo, and bandwidth and build-minute overages on a content-heavy site routinely push a production bill to $50–$150+/mo.
Build minutes — every content publish that triggers a rebuild burns compute. On a few hundred pages this is trivial; on tens of thousands it is a metered cost you watch.

So before a single line of bespoke code, headless roughly doubles the standing infrastructure footprint of the same site. That is the cheapest part of the bill.

The build cost: things WordPress gave you free that you now rebuild

A vanilla WordPress theme hands you a working website. Headless hands you a JSON endpoint and a to-do list. Each of these is a genuine engineering line item, billed in developer-hours:

Editorial preview

Classic WordPress preview renders the draft in the live theme. With no theme, “Preview” shows nothing useful. You have to wire the draft API into the frontend — query draft content, authenticate the preview request, and render it through your framework's preview mode. WP Engine's Faust.js exists specifically to solve this for Next.js and is worth using, but it is still setup, configuration, and a thing that breaks on framework upgrades.

SEO output

Yoast and Rank Math emit your title tags, meta descriptions, canonical URLs, Open Graph data, schema, and XML sitemaps as part of the theme render. Headless skips the render, so it skips all of that. You query the SEO data over the API (both plugins expose it) and re-emit it in your frontend's <head>, page by page, type by type. Get one of those wrong — a missing canonical, a broken sitemap — and you regress rankings on a live, indexed site. This is the highest-stakes re-implementation on the list.

Forms, galleries, and anything that injected HTML

Plugins like Contact Form 7, Gravity Forms, sliders, and social-share widgets work by injecting markup into the theme. No theme, no injection. You either find a headless-friendly alternative or rebuild the behavior in React/Vue. Every “just install a plugin” solution becomes a frontend ticket.

The data layer itself

You also choose how to talk to WordPress: the built-in REST API, or WPGraphQL. WPGraphQL is the better developer experience for component-driven frontends and, as of late 2024, became a canonical WordPress plugin after its creator joined Automattic — so its long-term governance is healthier than it used to be. But adopting it is another plugin to maintain, another schema to learn, and another thing in the request path.

None of these are conceptually hard. All of them are work. A realistic first headless build carries a meaningful premium in developer-hours over shipping the same site on a quality block theme — and that premium is front-loaded, before you have learned anything about whether the architecture suited you.

The maintenance tax: the cost that compounds

This is the bucket the tutorials skip entirely, and it is the one that matters most over a site's life.

WordPress's core value proposition is backward compatibility. Code written for WordPress a decade ago largely still runs. A well-built classic or block theme can sit for years with only routine plugin updates.

A JavaScript frontend lives in the opposite universe. Your node_modules is a moving target:

Framework majors land roughly every 12–18 months. Next.js's shift to the App Router was a multi-week migration for many teams. Each major is a project, not a patch.
Dependency churn — npm audit will surface advisories on a real project continuously, and transitive dependencies break in ways WordPress's curated plugin ecosystem rarely does.
Build-tool drift — the toolchain underneath you (bundlers, Node versions, deployment adapters) keeps evolving, and a frontend left untouched for a year often will not build cleanly without remediation.

The practical effect: a traditional WordPress site can be neglected and survive. A headless site that is neglected rots. Budget for ongoing JavaScript maintenance as a recurring cost, not a one-time launch expense — this is the single most under-priced part of going headless.

The talent cost

WordPress developers are abundant and comparatively affordable. A senior React or Next.js engineer who is also fluent in WordPress's data model is a narrower, pricier hire. Going headless quietly raises the skill floor for everyone who will ever touch the project — including the next agency you hand it to. And it splits the team: editors live in WordPress, developers live in the frontend repo, and any change spanning both (a new content type needing a new template) requires coordinated work across two systems.

Where the math actually flips

Headless pays for all of the above when enough of these are true at the same time:

Traffic is genuinely high — think hundreds of thousands of monthly visitors, where shaving load time and absorbing spikes at the CDN edge has measurable business value. A statically-generated frontend on a CDN can hit an LCP comfortably under the 2.5s Core Web Vitals threshold and a TTFB in the tens of milliseconds, which dynamic PHP struggles to match under load.
Content is multi-channel — the same WordPress content feeds a website and a native app or partner sites. One CMS, many heads. This is headless's strongest single justification.
The team is already JavaScript-native — you are not learning React to go headless; you already build in it and the productivity is real.
Design-system discipline matters — component libraries enforce consistency more strictly than typical theme development.

One of these alone rarely justifies the spend. A low-traffic brochure site with a single web frontend will almost never recover the build premium, the doubled infrastructure, and the maintenance tax.

The middle path most sites actually want

If the appeal is speed, you can get most of the way there without splitting the stack. A well-tuned WordPress site on quality managed hosting, with full-page caching and a CDN in front (Cloudflare or your host's edge), routinely passes Core Web Vitals. The gap between “tuned WordPress” and “headless on a CDN” is real but usually smaller than the pitch implies — and far cheaper to maintain.

If the appeal is modern, component-driven authoring, the block editor with a quality block theme already delivers component-based design that is much closer to React-style composition than the old PHP-and-jQuery era. And if you genuinely need multi-channel, WordPress's REST API can feed an app or partner site while your main website stays on WordPress — capturing the multi-head benefit without the full architectural shift or its bill.

The honest bottom line

Headless WordPress is not a trend to chase; it is a trade to evaluate. The real cost is a doubled infrastructure footprint, a front-loaded build premium, a compounding JavaScript maintenance tax, and a higher talent floor — paid against benefits that only materialize at real scale, real multi-channel need, or with a team already living in JavaScript. If two or more of those conditions are firmly true, the math works and headless is the right call. If you are reaching for it because it sounds modern, you are about to buy a second stack to solve a problem your first one didn't have.

WordPress Headless: The Real Cost of Going JavaScript-First