What “headless” actually means
A normal WordPress site does two jobs in one system. It stores your content, and it renders that content into pages. Write a post, WordPress builds the HTML, visitors see it.
A headless CMS only does the first job. Content lives in a database and comes out as raw data through an API. Something else entirely — usually a JavaScript framework like Next.js or Astro — turns that data into a page.
The word “headless” is just the metaphor: the body stores everything, the head that displays it has been removed and replaced with one you build yourself.
The honest case for it
Three situations where headless earns its complexity:
You publish to more than a website
A site, a mobile app, in-store screens, a partner’s platform. In a traditional CMS you either duplicate the content or build fragile integrations. In a headless one it’s the same API call with a different front end. This is the original reason headless exists and still the best one.
Your content model is genuinely complex
Not “posts and pages with a few custom fields” — that’s ACF territory and WordPress handles it fine. This means content that gets recombined in many arrangements across many surfaces, in several languages, with different teams owning different pieces.
Your plugin stack has become the problem
Some sites accumulate a decade of plugins, each solving a real problem, and collectively making the site slow and fragile. At a certain point rebuilding costs less than continuing to patch. That’s a real threshold — it’s just further away than most vendors suggest.
What it costs you that the sales pages skip
Every headless comparison lists the benefits. Fewer are candid about what you give up, so here it is plainly.
- You now maintain two systems. A CMS and a separate front-end application, each with its own hosting, dependencies, and update cycle.
- Preview stops being free. In WordPress, “view draft” just works. In headless, someone has to build preview, and it breaks when the front end changes.
- Your editors lose context. The visual editing gap has narrowed considerably — most major platforms now ship visual editors — but a marketer editing structured fields is further from the finished page than one editing in WordPress.
- Small changes need a developer again. Moving a section, changing a layout, adding a field: all code, all deploys.
- The security work moves, it doesn’t vanish. You drop public theme and plugin exposure and pick up API tokens, build hooks, and webhook authentication.
None of these are dealbreakers. They’re the bill, and you should see it before you order.
Four questions that settle it
Skip the feature comparisons. These four decide it faster.
- Do you publish the same content to more than one place? If no, you’re buying an omnichannel tool to run one channel.
- Do you have a developer on retainer? Headless is not a set-and-forget architecture. Without ongoing development capacity it degrades faster than WordPress does.
- Who edits the site day to day? If the answer is a non-technical person who currently edits in WordPress comfortably, you’re about to make their job harder.
- Is your current site actually slow, or does it just feel dated? These get confused constantly, and they have completely different fixes. Run your own site through PageSpeed Insights and read the mobile score. Most sites we audit don’t have an architecture problem, they have an unoptimised images and too many scripts problem.
The pattern we see: most businesses asking about headless are describing a speed problem or an editing frustration. Both are usually fixable on the site they already have, for a fraction of a rebuild.
The middle option most people miss
Headless WordPress keeps WordPress as the content store and puts a modern front end in front of it. You keep the editor your team knows, your existing content, your URLs, and WooCommerce if you sell.
The trade-off is that you inherit WordPress’s operational overhead as well — you’re running WordPress and a front-end app. For a brand new project a purpose-built headless CMS is usually cleaner. For an existing site with years of content, headless WordPress is often the cheaper path to the same performance.
Where the platforms stand now
| Platform | Best for | Watch out for |
|---|---|---|
| Sanity | Complex content models, real-time collaboration, teams that want structured content done properly | Content modelling takes real thought up front |
| Storyblok | Marketing teams who need visual editing without losing structure | Component-driven approach needs discipline to stay tidy |
| Strapi | Self-hosting, full control, teams comfortable with Node.js | You own the hosting and the upgrades |
| Contentful | Enterprise, mature API, extensive documentation | Pricing climbs quickly with seats and content types |
| Headless WordPress | Existing WordPress sites, WooCommerce, editors already trained | Two systems to maintain instead of one |
What we tell clients who ask
WordPress still runs a little over 40% of the web, and roughly 60% of sites that use a CMS at all. That isn’t inertia — for a business site with a blog, a services section, and a contact form, it is genuinely the right tool, and going headless would make it slower to run and more expensive to change.
Headless solves a distribution problem. If you don’t have a distribution problem, it just adds a build step.
The businesses that should look seriously at headless are the ones publishing to several surfaces at once, running content teams rather than a content person, or sitting on a plugin stack that has genuinely stopped being fixable.
Everyone else is better served by fixing what they have. That is a less exciting answer than the one most agencies give, and it is right far more often.
