Headless WordPress in 2026: when to pick it, and what it costs

Search headless WordPress and every result on page one is sold by someone who profits from you going decoupled. Gatsby wants the frontend. WP Engine and Cloudways want the hosting. Automattic and WordPress VIP want the enterprise contract. Elementor wants you to know they have a headless story too. All of them list “complexity” as a drawback and then decline to put a single number next to it.

We maintain both kinds of site and we get the call when one of them stops working at an inconvenient hour. So here is the number nobody prints, plus the four questions we ask before agreeing that headless is the right shape for a project.

What headless WordPress actually costs to run

A conventional WordPress site is one server, one deploy path, one thing to monitor. Going headless does not replace that server. It adds a second system in front of it.

You are now paying for the WordPress backend, which still needs a real host because your API lives there. You are also paying for wherever the frontend renders, whether that is Vercel or Netlify on a paid tier or a Node process you run yourself. Then build minutes, because every content change that triggers a rebuild costs compute. A monolith that ran happily on a $30 VPS typically lands somewhere between $60 and $150 a month once both halves are running properly, and the frontend bill is the one that scales with your publishing frequency rather than your traffic.

Money is the smaller half. The bigger half is that you now have two deploy pipelines, two sets of environment variables, two places a certificate can expire and two systems that have to be up simultaneously for a visitor to see anything. When a page 500s at 2am, the first twenty minutes go into working out which layer did it. We have sat in that twenty minutes more than once and it is not a fun place to be at any hourly rate.

The plugins you are actually replacing

Every guide says “some plugins won’t work” and then moves on without naming one. These are the ones that break, and what the replacement costs to build.

Add it up and reaching feature parity with the site you already had costs somewhere around 50 to 110 developer hours before anyone builds a single new thing. That number is the honest answer to “is headless WordPress worth it,” and it is why the hosting savings people quote almost never materialise. You do not save money. You spend it somewhere less visible.

The work itself is fine work. It just needs to appear on the quote, where the client can see it, rather than surfacing in month four as a change request.

What your editors lose on day one

Everyone else files this under drawbacks and gives it one line. For a marketing team it is usually the whole decision.

Your editors lose live preview unless somebody builds it. The View Page button either disappears or points at a URL that renders a bare API response. They lose the visual builder completely, so if the site was built in Elementor or with the block editor doing layout work, those blocks now need a matching React component for every single one, and the day someone inserts a block nobody wrote a component for, the page renders a gap.

What they keep is the part that matters most: the editing screen, the media library, the revision history, the roles and permissions. WordPress is still an excellent place to write. The gap is between writing and seeing.

We ask clients to have the person who publishes three times a week sit in the scoping call. That conversation has killed more headless projects than any cost estimate, and the ones that survive it tend to go well, because somebody budgeted the preview work up front.

The handover problem

A company builds a headless site with a contractor or a small agency. Two years later that developer moves on. The company calls a WordPress agency, because the site is “a WordPress site.” The WordPress agency opens the repository, finds a Next.js application and a GraphQL schema, and says this is not what we do. The company then calls a React shop, who look at the WordPress side, the custom post types, the ACF field groups and the plugin set, and say the same thing in the other direction.

What arrives on our desk is a site that works fine and cannot be changed. Nobody wants to touch it, hosting renewals come and go, and eventually a dependency goes end of life and the thing has to be rebuilt from scratch. The rebuild costs more than the original build did.

A monolithic WordPress site does not have this problem. Any of several thousand agencies can pick it up on a Monday. That liquidity has a real value and it never appears in the comparison tables, because the people writing them are selling the illiquid option.

If you go headless anyway, the mitigation is boring and it works. Keep the frontend on a mainstream framework rather than a clever one. Document the GraphQL or REST contract in the repository. Make sure at least two people who are not the original developer have deployed it successfully. We do this as part of ongoing WordPress support for the decoupled sites on our books, and it costs almost nothing compared to what it prevents.

The security claim, examined

Every vendor page lists security as a headless benefit, on the grounds that your WordPress admin is no longer sitting on the public internet waiting to be brute forced. That part is true and it is worth having. No public login form is a real reduction in noise.

What follows from it is less comfortable. The WordPress install still exists, still runs PHP, still holds your entire content database, and it is now the system nobody looks at because it stopped being “the website.” The decoupled backends we audit are consistently further behind on patches than the public monoliths we audit, for exactly that reason. An unpatched WordPress is unpatched whether or not a visitor can see it, and if someone reaches it through the hosting account rather than the front door, they have everything.

You have also added a public API where there wasn’t one. A default WordPress REST install will happily enumerate your usernames at /wp-json/wp/v2/users, and a GraphQL schema exposed without depth limiting or introspection control gives an attacker a map of your entire content model plus a cheap way to exhaust the server with one nested query.

Headless can be the more secure option. It gets there when the backend is on a private network or behind an identity layer, patched on the same schedule as anything else, and the API is scoped deliberately rather than left at defaults. That is roughly what our WordPress security work covers, and on decoupled sites it takes longer, because there are two attack surfaces to walk instead of one.

A 60-second test for headless WordPress

Count how many of these are true today, not aspirationally true in phase two.

1. You are publishing the same content to more than one surface: a website plus a native app, a kiosk, an in-store display, a partner feed.
2. You already employ frontend developers who work in React or Vue every day, and they are not leaving.
3. The interface needs framework-level interactivity that a theme genuinely cannot do, meaning a real application rather than pages with some JavaScript on them.
4. Your content team is small and technical, or you have budget for the preview and editing work in the initial build.

Two or more, headless is a reasonable call and the costs above are worth paying. One, think harder. Zero, and the honest answer is that you want a fast website, which is a much cheaper problem.

“We want the site to be faster” is the reason we hear most often, and on its own it is the worst reason to go headless. A well built decoupled frontend is fast. So is a well built monolith with a proper cache in front of it, and one of those two options does not require you to rebuild your forms.

When it is obviously the right call

Plenty of headless builds are correct. A publisher pushing the same articles to a website, an app and a syndication partner is exactly the case the architecture was designed for, and WordPress makes a good editorial backend for it. A product company whose marketing site and application share a design system saves real duplication by rendering both from one frontend codebase. Teams with in-house React developers get faster at shipping, not slower, because they are working in the stack they know.

The same reasoning applies on other platforms too. We went through the equivalent decision for running Drupal decoupled, and the conclusion has the same shape: the architecture is sound and the question is whether your organisation is the one it was designed for.

If you are building toward that, the API layer is the thing to get right early. Custom endpoints, authentication, rate limiting and a schema you can version are all WordPress integration work that we price from $290, and doing it properly at the start is far cheaper than retrofitting it around a frontend that already shipped.

The boring alternative that usually wins

For most of the sites that ask us about headless, the actual problem is a 1.8 second time to first byte, and the actual fix is unglamorous. Object caching in Redis so the database stops being asked the same question forty times a page. A page cache at the edge. Images served as WebP or AVIF instead of 2MB JPEGs, which we measured properly in our WebP and AVIF comparison. PHP on a current version with OPcache tuned. A host that is not overselling the box by a factor of thirty.

That work takes days rather than months, it costs a fraction of a rebuild, and your editors keep their preview button. We package it as the WordPress Performance Pack and it turns around in five business days. The broader approach is written up in our notes on WordPress speed optimisation.

Go headless when the architecture solves a problem you actually have. If you already have a decoupled build that nobody wants to maintain, that is a situation we see often and can usually stabilise: send us the repository and the hosting details, and we will tell you whether it needs adopting or replacing. Our WordPress support work covers both shapes.