I sat across from a client last year, mid-discovery session, explaining our recommended architecture. I was three minutes into a confident walkthrough of how their new CMS would deliver content via APIs to a modern frontend framework, the "head" in this case being a Next.js application that would render their website.
He held up his hand.
"So... the head is the website?"
"Well, technically the head is the presentation layer, the frontend, the—"
"The website."
"Yes. The website."
"So we're using a system without a head... to build a website. Which is the head."
I opened my mouth. Closed it. Opened it again.
"Why don't we just call it a website?"
He wasn't wrong. And the more I've thought about it since, the more I think he was ahead of the entire industry.
The Term That Outlived Its Usefulness
Here’s the irony that keeps me up at night: “headless” is a marketing term that marketing never understood. Developers coined it to describe an architecture pattern. Then vendors turned it into a category label. And then the actual marketing teams who were supposed to benefit from these platforms spent five years in discovery meetings asking, “Wait, so where do I build my pages?” The term was born in engineering, adopted by product marketing, and never once resonated with the people buying the product. That alone should have been a sign.
"Headless" made sense when it described something genuinely new. When Contentful launched in 2013 and told the CMS world that content management didn't have to be welded to a rendering engine, that was a meaningful architectural distinction. The whole point was liberation: your content could go anywhere, to any device, through any framework. The absence of a built-in presentation layer was the feature.
But here's what happened next. Almost every "headless" CMS is now racing to bolt a head back on.
Storyblok built its entire brand around a visual editor that gives marketers drag-and-drop page building. Contentful launched Contentful Studio in 2025, a low-code visual workspace so marketers can build experiences without developer bottlenecks. Prismic calls itself a "headless page builder" now, and that phrase alone should tell you something is shifting. Contentstack invested heavily in its Visual Editor, combining content modeling with a no-code page building experience. Even Sanity, long the purist's choice for structured content as data, has added visual editing capabilities and click-to-edit previews through its Presentation tool.
The headless platforms spent a decade removing the head. Now they're putting it back. Let's at least admit that's funny.
Meanwhile, From the Other Direction
While the headless crowd races toward visual page building, the traditional DXP platforms are sprinting the opposite way.
Sitecore literally coined "Hybrid Headless" as a product category, bolting API endpoints and Experience Edge onto its monolithic platform so content could be delivered to JavaScript frontends. Adobe Experience Manager added Content Fragment Delivery APIs, Management APIs, and headless endpoints so teams could pull structured content from AEM into whatever frontend framework they preferred. Optimizely embraced SaaS CMS delivery with Optimizely Graph, powered by GraphQL, to serve content to decoupled frontends.
We used to call this "hybrid headless" at HT Blue. It was our polite way of saying: this platform was never designed to be headless, but they're retrofitting API delivery onto a system that was built around page rendering.
Now look at both sides of the market and tell me what's actually different anymore.
The headless platforms added page builders. The page builder platforms added APIs. Everyone arrived at roughly the same destination. The distinction that made "headless" meaningful has dissolved.
What We Should Be Saying Instead: API-First
At HT Blue, we've started using "API-first" instead of "headless," and it's a much more honest description of what actually matters in modern content architecture.
API-first means the content delivery infrastructure is designed around structured, queryable endpoints. It means content isn't trapped inside a rendering pipeline. It means your content model exists independently of how any single frontend consumes it.
This is a meaningful architectural principle. "Headless" is a marketing term that describes what something lacks. API-first describes what something does.
And here's the practical difference: when I say "API-first" to that same client, he gets it immediately. The system stores your content and makes it available through programmatic endpoints. Your website, your app, your digital signage, your AI assistant, whatever consumes it through those endpoints. No metaphor about decapitation required.
The Uncomfortable Math of One Head
Let's be honest about something else. The vast majority of organizations using a "headless" CMS are delivering content to exactly one channel: a website. One head.
The headless CMS market is projected to grow from roughly $2.4 billion in 2025 to over $7.5 billion by 2030, growing at a CAGR above 25%. That's real money and real momentum. But the promise was multi-channel. The pitch was always about delivering to websites, mobile apps, kiosks, smartwatches, IoT devices, voice assistants.
In practice? Most organizations are using sophisticated API-first content infrastructure to render HTML pages in a browser. The same thing a traditional CMS does, just with a different architecture underneath.
I'm not saying that architecture doesn't have real benefits. Decoupled frontends are faster to develop. Modern JavaScript frameworks deliver better performance. Teams can iterate on the frontend without touching the CMS. API-first content models are cleaner, more reusable, and better suited for AI consumption down the road.
But calling it "headless" when you're serving a single head is like calling your sedan "convertible" because the sunroof opens.
Where Multi-Head Actually Gets Interesting
Now, if platforms genuinely embraced multi-head delivery as a first-class feature, that would be something worth talking about. Imagine a CMS that doesn't just expose APIs for a frontend developer to consume, but actively helps you build and manage rendering for multiple surfaces simultaneously.
Your website, sure. But also a native mobile app experience with its own layout rules. A digital signage template for in-store displays. An email rendering pipeline. A voice interface content model. Each "head" with its own rendering logic, preview capabilities, and publishing workflow, all managed from a unified content platform.
That's the actual promise of multi-channel content, and almost nobody delivers it as a product experience today. Platforms expose APIs and say "you can deliver anywhere!" Which is technically true, but it puts all the multi-channel complexity on the implementation team.
The platform that figures out how to make multi-head rendering a built-in, manageable capability, not just an API possibility, will have earned a new category name. Until then, calling a CMS "headless" because it has APIs is like calling every restaurant "international" because they accept foreign currency.
The Convergence Is Real
Look at the data on DXP Scorecard, which evaluates 26+ platforms across hundreds of criteria, and the pattern is undeniable. The top-performing platforms, regardless of whether they started as headless or traditional, share the same core capabilities: structured content modeling, API delivery, visual editing, workflow management, localization support, and increasingly, AI-assisted content operations.
Storyblok, a visual-first headless CMS, scores competitively against Sitecore on editorial experience. SitecoreAI (the rebranded evolution of XM Cloud, now with agentic AI baked into every workflow), a traditional DXP gone SaaS, competes with Contentful on API flexibility. Sanity's structured content approach is being adopted by enterprise teams who used to insist on page-centric monoliths.
The market isn't splitting into headless and traditional anymore. It's converging around a shared set of capabilities that every serious platform needs. The question isn't "headless or not?" The question is: "How well does this platform serve your content to the channels you actually use, and how much control does it give your team?"
What to Ask Instead of "Is It Headless?"
If you're evaluating CMS platforms right now, here are better questions than "is it headless?"
Is the content model API-first? Can content be created, queried, and delivered through well-designed APIs without depending on a specific rendering framework? This is the architectural principle that matters, not whether the vendor calls it headless.
How much editorial control do non-developers have? Can your marketing team build and modify pages without filing a ticket? Does the platform offer visual editing, preview, and publishing workflows that empower content creators?
How flexible is the rendering layer? Can you use the frontend framework your team already knows? Can you swap it out later without migrating your content? Does the platform impose rendering opinions you'll regret?
What does multi-channel look like in practice? If you need to serve content beyond a website, does the platform make that genuinely easier, or just technically possible?
What's the total cost of ownership? Factor in developer time, editorial team productivity, integration complexity, and the ongoing effort to maintain the frontend. A "free" open-source headless CMS with a $400K annual frontend maintenance bill isn't actually cheaper than a SaaS platform with built-in rendering.
Let's Just Say Website
My client was right. He wanted a website. A fast, modern, well-managed website with great content tooling and a clean architecture underneath. The terminology we use shouldn't require a whiteboard and 20 minutes of metaphor.
"Headless" served its purpose. It drew a line between old architecture and new architecture at a time when that line needed drawing. But the industry has moved past the binary. Every serious CMS has APIs. Most of them have visual editing. The ones that don't have both are adding whichever piece they're missing.
It's time to retire the term and talk about what actually matters: Is your content structured? Is it accessible through APIs? Can your team build the experiences they need without fighting the platform?
API-first. That's the architecture. The rest is just a website.
