"Headless" has spent the last few years quietly becoming a buzzword. Vendors sell it. Agencies push it. Conference talks praise it. The honest version, especially for a business website, is more boring and more useful.
This piece is the plain explanation: what headless WordPress actually means, when it earns the complexity it brings, and when it is just a complicated way to build something simpler tools handle better.
What "headless" actually 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: a real architectural choice with real trade-offs, useful for specific projects, oversold for typical business websites.
What headless is actually 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. Possible. Annoying. Often 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 — analytics, forms, search, related posts, 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 is honestly the wrong call
For a typical business website — service company, agency, professional practice, e-commerce store of modest scale, content site without unusual interactivity needs — 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. See Core Web Vitals in the AI era for what "fast enough" actually means.
"It will be more modern." Modern is not a feature. The block editor in modern WordPress, paired with a custom block theme, gives you a genuinely modern editorial experience without splitting the stack.
"It will scale better." For most businesses, scale is not the bottleneck. Performance, conversion, and content velocity are. Splitting the stack tends to slow those down, not speed them up.
"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 actually want
What most businesses describe when they say "we want headless" is actually 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 coexist. The complexity is contained.
When we recommend full headless
When the project genuinely meets the criteria above. Multi-channel publishing as a core requirement. Highly interactive front end. Strong in-house JavaScript team. Real expected scale that justifies the operational cost. And budget for the longer build, the more complex maintenance, and the additional integration work.
Those projects exist. They are a small minority of the business WordPress sites we work on.
If you have been told you need headless and you are not sure whether the recommendation is for you or for the agency pitching it, tell us about the project. We will 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 is the truthful answer.
