What is headless WordPress, and is it worth it?

How is it different from a normal WordPress site?

In a classic build, one system does everything: WordPress stores the content and renders the HTML a visitor receives, through a theme. In a headless build, WordPress keeps the first job and gives up the second. Content goes out over an API — REST or GraphQL — and a separate application builds the pages, so the "head" that used to sit on top of the CMS is now a codebase of its own.

For the people writing, almost nothing changes: same admin, same editor, same media library, same roles. For everything downstream, nearly everything changes — templates become components, deploys become code deploys, and plugins that worked by injecting markup into a theme stop having a theme to inject into.

What does going headless actually buy you?

Control over what reaches the browser, which is the thing that decides performance. A theme ships whatever WordPress and its plugins decide to enqueue; a front end you own ships exactly what you wrote. That is the difference between fighting a page weight problem every release and not having one, and it is why the biggest wins show up in the metrics that JavaScript and stylesheet bloat wreck first.

On a recent B2B rebuild — a manufacturer whose site was the front door for every sales inquiry — the same content moved onto a Next.js front end with WordPress kept as the CMS. Measured on mobile and throttled, Total Blocking Time fell from roughly 1,050ms to 100ms and the SEO category went from 61 to 100, because markup and schema were now written deliberately instead of assembled by plugins. The editors kept the admin they had been using for years.

The second thing it buys is composition. Once the front end is an application, the site can render content from more than one source — the CMS for pages, a product database, a CRM, an internal tool — as one coherent site. That is difficult to retrofit onto a theme and natural once you have a front end of your own.

What it costs you

You are now maintaining two systems and building things a theme gave you for free. Preview, form handling, redirects, sitemaps, and the long tail of "the plugin used to do that" all become work items. Anything a marketing team installs expecting it to change the public site — a popup builder, a tracking tag, an A/B testing widget — has to be planned into the front end instead, or it silently does nothing.

Cost follows: a headless build is closer to an application project than a website project, and the timeline reflects that. It also concentrates change in the hands of whoever can deploy code, which is a feature for stability and a constraint for teams used to editing a template themselves.

When a classic theme is the better call

If a well-built classic theme already clears your performance targets, headless is a cost with no matching benefit. That covers most content-led sites: publications, service sites, anything where the job is publishing pages rather than running an interface. A lean theme, a short plugin list, and images that don't reflow will pass Core Web Vitals comfortably, and the whole team keeps the tooling it has.

It is also the better call when nobody on your side ships code. A headless site without a developer relationship is a site that cannot be changed — which is the worst version of the trade, because you paid the build cost and lost the flexibility it was supposed to buy. Before going headless, decide honestly whether the site's job needs an application, or whether it needs a well-chosen editor and a performance budget somebody enforces.

How to decide

Three questions settle it. Does the site have to behave like an application — real interactivity, data from several systems, a performance bar a theme keeps missing? Do the people publishing need to stay in WordPress? Is there someone who can deploy code after launch? Three yeses make headless the obvious answer. A no on the last one usually means it is the wrong tool no matter how good the first two look.

That is the same evaluation behind every platform choice on my WordPress and Next.js builds: pick the lightest thing that does the job, then hold it to a budget.

Questions