"Headless" has spent the last few years turning into a buzzword, pushed by vendors, agencies and conference talks. The honest version, especially for a business website, is more boring and more useful.
This is the plain explanation: what headless WordPress means, when it earns the complexity it brings, and when it's just a complicated way to build something simpler tools handle better.
What "headless" means
A traditional WordPress site uses WordPress for both the back end (the admin interface, the database, the content model) and the front end (the theme that renders pages for visitors). When a request comes in for /about, WordPress runs the theme, generates the HTML, and ships it to the browser.
A headless WordPress site uses WordPress only for the back end. The front end is built with a separate framework (usually a JavaScript framework like Next.js, Astro, SvelteKit or Nuxt) that fetches content from WordPress via its REST API or GraphQL endpoint and renders it however the front-end developer chose. WordPress no longer renders the visitor-facing pages directly. It is the "head-less" content management system.
The pitch: front-end flexibility, modern developer tooling, potentially better performance, easier integration with other systems.
The reality: an architectural choice with real trade-offs, useful for specific projects and oversold for typical business websites.
What headless is good at
Multi-channel publishing. When the same content needs to render in a website, a mobile app, a kiosk display, and a partner's embedded widget, headless makes a lot of sense. WordPress becomes the single content store; each surface pulls from the API.
Highly custom interactive front ends. A site that is essentially a JavaScript application with a content layer behind it (heavy interactivity, complex state, real-time data) can be cleaner to build as a separate front end against a headless WordPress back end than as a custom WordPress theme.
Front-end teams that prefer a specific framework. An organization with strong in-house JavaScript skill, where the front-end team has standardized on React or Vue, can be more productive working in their native tools than in PHP templates. Headless lets each team work in its preferred stack.
Performance at very high scale. A statically generated front end pulling from headless WordPress can serve millions of requests from a CDN with almost no origin load. For sites in that traffic tier, the benefits are real and measurable.
What it brings that the pitch undersells
Two systems to operate instead of one. The WordPress back end still needs to be hosted, patched, updated, backed up. The front-end build needs its own deploy pipeline, its own hosting, its own monitoring. Failures can happen in either, and diagnosing them takes more skill than diagnosing a monolithic WordPress site.
Preview is broken by default. When a content editor saves a draft in WordPress, they expect to click "preview" and see what the page will look like. In headless, that requires building a custom preview pipeline that fetches the draft, renders it through the front-end framework, and serves it back. It's possible, but it's fiddly enough that it often gets skipped, which makes editors miserable.
Block-based content gets harder. WordPress's block editor is built to render its output through WordPress's own theme system. Headless front ends have to re-implement that rendering, block by block. The first time the marketing team uses a block the front end does not know how to render, you discover this the hard way.
Plugins that change the front end stop working. A WordPress site benefits from a huge ecosystem of plugins that hook into the front end, like analytics, forms, search and SEO output. Headless means each of those needs its own integration on the front-end side. Some plugins simply do not work headless without a meaningful rebuild.
Cost. Two stacks cost more to build and more to maintain than one. The performance argument needs to be strong enough to justify the cost premium for the life of the project.
When it's the wrong call
For a typical business website (a service company, an agency, a professional practice, a modest online store), headless is usually wrong.
The arguments for it tend to be: "It will be faster." A well-built traditional WordPress site is fast enough for almost any business use case. The work to make it fast (caching, image optimization, sensible plugin choices) is also work that headless does not eliminate. Our post on Core Web Vitals covers what "fast enough" means.
"It will be more modern." Modern is not a feature. The block editor in current WordPress, paired with a custom block theme, gives you a modern editorial experience without splitting the stack.
"It will scale better." For most businesses, the bottleneck is performance, conversion or content velocity rather than scale, and splitting the stack tends to slow those down.
"Our developer wants it." Sometimes this is the right reason, if the developer is going to stay and the team is set up to operate the result. Often it is a developer-resume reason, and the business will pay for it for years.
The middle path most businesses want
What most businesses describe when they say "we want headless" is usually one of these:
A modern, performant WordPress site. Custom block theme, ACF Pro, careful plugin selection, real performance work. Same tools as headless under the hood (block editor, structured content), but rendered through WordPress so preview works, plugins integrate, and operations stay simple. This is the default we recommend, covered in why we still build WordPress sites by hand.
A static-export WordPress site. Sometimes called "static WordPress." WordPress runs in the back end, generates static HTML for each page, and serves that HTML from a CDN. Most of the performance benefits of headless without splitting the editorial experience. Right for sites where content does not change minute-to-minute.
Selectively headless. WordPress for the main site; a separate front-end app for one specific surface (a search experience, a configurator, a calculator) that needs more interactivity than templates can comfortably provide. The two sit side by side and the extra complexity stays in that one piece.
When we recommend full headless
When the project meets the criteria above: multi-channel publishing as a core requirement, a highly interactive front end, a strong in-house JavaScript team, and enough expected scale to justify the operational cost. It also needs the budget for a longer build, more complex maintenance and the extra integration work.
Those projects exist, but they're a small minority of the business WordPress sites we work on.
If you've been told you need headless and you're not sure whether the recommendation is for you or for the agency pitching it, tell us about the project. We'll give you an honest read, including "yes, headless is right for you" if it is, or "the simpler version will get you 95% of the benefit at 30% of the cost" if that's the truthful answer.
