A headless CMS is easy to define and harder to place. The word travels with commerce as much as with content: headless comes up in about a third of interviews with CMS buyers in market, roughly as often as among ecommerce-platform buyers — a measure of how often it is discussed, not of how many companies already use it. And it covers three different setups: a content platform built for APIs, a suite such as Adobe Experience Manager run in headless mode, and the content layer of a custom storefront. What the interviews add is direction. Large enterprises outside retail are moving toward a headless CMS, usually off a suite; small direct-to-consumer brands are moving back to their commerce platform's own storefront.
What is a headless CMS?
A headless CMS stores and manages content and delivers it through an API to whatever front end displays it — a website, an app, another channel — instead of rendering the pages itself. The “head” is the presentation layer, and a headless CMS does not have one.
Buyers describe the point as reuse: one buyer's team is “able to reuse the same content across our website, mobile apps, and text messages without tying to a specific front end.” The cost is that someone has to build and maintain the front end, and the components editors fill.
The second half of the question is the one buyers can answer that a definition cannot:
In these interviews the movement splits by company size and sector. The companies adopting or evaluating a headless CMS are mostly large enterprises outside retail — consumer goods, financial services, healthcare, technology — and mostly coming off a suite such as Sitecore, Adobe Experience Manager or WordPress. The companies that have gone back are mostly small direct-to-consumer brands, far smaller than the typical CMS buyer, returning to their commerce platform's own storefront.
And headless rarely means one kind of product: about two in five companies that name the platform they run headless are running a suite in headless mode.
What is the difference between a headless CMS and a traditional CMS?
A traditional CMS keeps content and presentation together; a headless CMS separates them. In a traditional CMS, editors change the words and the page in one place. In a headless CMS, content is structured for reuse and the layout lives in code. One buyer moving off headless describes the new setup simply: “that's going to be all form-driven where it's not headless. The display and the data are all in the same place.”
A headless CMS is structured content plus an API: “It's a headless content platform, and it's based on structured, reusable content models,” as one payments company puts it. What editors work with are components that developers build first.
The same buyer who moved back describes what that meant day to day: “we had to have developers build all the pages, and then the content folks could populate it, but they couldn't affect the display other than filling the buckets of content on the page.”
The vocabulary shows how buyers think about the choice. Headless is near-universal among the companies discussing it; the opposite term they reach for is all-in-one, and what marketers ask for instead is a page builder or visual editor. The industry's other labels barely appear in their speech.
Headless, composable, DXP, MACH
Headless is one boundary, between content and the front end. Composable is a whole stack assembled from separate services; in CMS interviews buyers say it about a quarter as often as headless, the same ratio as in commerce, while CDP buyers use the two almost equally. DXP is a suite that may offer a headless mode, and buyers rarely use the word even for AEM or Sitecore. MACH does not come up at all.
Who buys a headless CMS?
Two groups dominate: commerce brands that need a content layer for a custom storefront, and large enterprises putting corporate and multi-channel content on a headless platform. The owner is less often marketing than for CMS purchases generally — digital-experience, product and engineering leaders run more of these decisions.
The direction of travel is where the groups separate. The companies adopting a headless CMS are well above the typical CMS buyer in size, and only a few of them are retailers. The companies that have left one sit far below every baseline: almost all small direct-to-consumer brands, a few of them run by a founder who owned the original decision. Being headless today does not by itself mark a company as large — the companies currently running one look much like CMS buyers overall. It is the movement that splits.
That matters for the definition. A headless CMS is not one buyer's tool: for a large enterprise it is usually a step away from a suite, and for a small brand it is usually a consequence of a custom storefront — one some of them later decided they did not need.
How do companies end up with a headless CMS?
Four routes appear in these interviews, in this order of frequency. They describe how buyers arrive at a headless architecture, and their proportions are calculated across every company running, adopting or questioning one whose route we could classify. They are not directly comparable with the platform breakdown further down, which covers only the companies that name the CMS they run headless — including commerce-led setups whose content layer is a suite.
- As the content layer of a headless storefront
- By running an existing suite in headless mode
- By adopting a headless platform for the site and every channel
- By building the content service in-house
The most common route starts with commerce, not content.
The content layer of a headless storefront
A commerce platform — Shopify, BigCommerce, Salesforce Commerce Cloud, commercetools — keeps the catalogue and checkout, and a headless CMS runs the pages. Mostly retail and direct-to-consumer. For these brands the CMS is a consequence of the architecture, not a separate decision. (How headless commerce itself works out is on what is headless commerce.)
A home-goods brand describes its setup in one line: “We use it as a headless CMS on top of Shopify.” A small apparel brand explains the reverse — no headless storefront, so no separate CMS: “we don't run a headless environment in Shopify, which would lead to needing a CMS.”
A suite, run headless
Companies keep Adobe Experience Manager, Sitecore, Optimizely, CoreMedia, Magnolia or Drupal and change how content is delivered. These are the largest companies of the four routes, and sometimes the vendor drives the change.
A hospitality group is “using the headless CMS that Adobe has and using all the asset manager within Adobe Experience Manager, it's very powerful.” A life-sciences company says: “Sitecore's our CMS platform, headless across the enterprise.”
A headless platform for the site and every channel
Not commerce-led: corporate sites, apps and multi-channel publishing, often replacing Sitecore, AEM, WordPress or OpenText. Healthcare, financial services, technology and consumer goods appear here.
A hospital system says that “this centralized content through the headless CMS allows us to more easily publish the same content on multiple channels.” A consumer-goods company is still on its way: “We want to be in a place where we are headless so that we can leverage all the benefits that come along with that.”
Build the content management layer in-house
A few companies develop their own content service instead of adopting a packaged CMS. That is different from building a custom storefront over an existing headless platform, which the first route already covers; custom engineering alone does not make a CMS homegrown.
A building-materials distributor runs its own system, and two larger companies are weighing an in-house build against buying one.
The order is the point. For most companies in these interviews a headless CMS is not chosen on its own merits: it arrives with a storefront, or it is a delivery mode for a suite they already run. Only about a quarter adopt a headless platform as the content system for everything.
Which headless CMS platforms do buyers use?
Contentful is the most-named platform in headless context in these interviews, and Adobe Experience Manager is second. About two in five companies that name the platform they run headless are running a suite in headless mode rather than a headless-native product. That share counts every company naming its platform, whatever route it took, so it is larger than the quarter who reach headless by converting a suite they already ran.
That split is sharper than in neighbouring categories, in the opposite direction. Headless commerce in these interviews runs mostly on Shopify, a mainstream platform; in CMS, headless-native vendors carry the largest share of the conversation of the categories we compared — a rough comparison, but a consistent one — while the suites still hold a large minority. Ratings for these platforms are on what headless-CMS buyers wish they'd known, and why companies choose Contentful in particular is on the Contentful stack.
Headless-native CMS
Contentful · Sanity · Contentstack · Storyblok · Amplience · Builder.io · Prismic · Hygraph · DatoCMS
Suites and CMSs run headless
Adobe Experience Manager · Sitecore · Optimizely CMS · Acquia / Drupal · WordPress · CoreMedia · Magnolia · Kentico · Umbraco
The structural finding sits underneath the list. Headless is a delivery mode as much as a product category: the largest companies in these interviews mostly reach it by changing how their suite publishes, not by replacing it. That is a different decision from buying a headless-native platform, with a different cost.
What does going headless cost?
The cost buyers emphasize most is building and maintaining the presentation layer, rather than the CMS licence alone. Some describe implementations where marketers cannot change page layouts or preview content without a developer. One buyer summarizes that experience: “We want the ability to have WYSIWYG editors, but you can't have headless and WYSIWYG together.” That reflects the buyer's implementation, not an inherent restriction of every headless CMS: visual editing and preview are possible when the platform and the front end support them.
The build is the first cost. Components come before content — one department store's product leader says “I think we did too many components and too many bespoke because we're headless and I wish we had gone with less” — and the skills are new: for one distributor's technology team “headless is just a new paradigm for my team.” Preview is the daily one: a direct-to-consumer brand finds “you have to wait for changes, no proper previews and everything.” How the setup was built matters as much as the product. One marketplace company's marketing team dislikes its headless CMS, and the buyer calls that self-inflicted: “our engineering team kind of built it from scratch, and they built it in a way that made sense to them.” Where the components are built well, a technology company reports “it's managed by the business teams on their own, very light touch from an IT standpoint.” Why headless moves design work back to engineering is covered in depth on the lessons page, and the cost mechanics on what buyers actually pay for a CMS.
For the small brands that went back, those costs were the reason. One explains that “any CMS changes that we want to make have to be done through a dev partner instead of through an e-com manager or myself,” and another that “if we were doing that same project today, we probably would not need to make the same choice to move to a headless architecture” — because the commerce platform's own storefront had caught up.
Want this checked against your own stack?
Start my checkup →Should you use a headless CMS?
A headless CMS is most compelling when a company needs to reuse content across channels, build a custom front end or manage presentation independently of its content platform — and has the technical resources to support that separation. For simpler websites or commerce storefronts, the added development and maintenance may outweigh the benefits; that is the trade-off several smaller brands in these interviews describe when explaining why they moved back.
Buyers who decided against it give the reasons plainly: “I don't envision us moving to a headless system anytime soon because we don't have a great need for it with just a basic website and basic mobile app,” says a telecom brand, and one bank's digital leader advises “I think my first advice is that headless is not always needed or good.” Three things follow, and they are our recommendations rather than practices buyers describe. First, decide which problem you are solving — reuse across channels, a custom storefront, or leaving a suite — since each leads to a different route and a different platform. Second, if you run a suite, price its headless mode before replacing it, since that is how the largest companies here get there. Third, count the front end as part of the purchase: the components, the preview and the developer time are where the cost lands, and where the companies that went back say it landed for them.
For where companies move when they change CMS, see why companies switch CMS platforms; for the complaints buyers raise about the platforms they run, see top complaints about CMS platforms.
Common questions
What is a headless CMS?
A headless CMS stores and manages content and delivers it through an API to whatever front end displays it — a website, an app or another channel — instead of rendering the pages itself. Buyers in these interviews describe the point as reusing the same content across channels without being tied to one front end, and the cost as someone having to build and maintain the front end and the components editors work with.
What is the difference between a headless CMS and a traditional CMS?
A traditional CMS keeps content and presentation together, so editors change both in one place. A headless CMS separates them: content can be reused anywhere, but layout usually lives in front-end code that developers maintain, unless the platform adds visual editing. One buyer moving back to a coupled setup described the difference as the display and the data being in the same place again.
Is a headless CMS the same as a composable CMS or a DXP?
No. Headless describes one boundary, between content and the front end. Composable describes assembling a whole stack from separate services, of which a headless CMS can be one. A DXP is a suite, such as Adobe Experience Manager or Sitecore, that may also offer a headless mode. Buyers in these interviews overwhelmingly say headless; composable comes up about a quarter as often in CMS interviews, and MACH not at all.
Which companies use a headless CMS?
Two groups dominate these interviews. Commerce brands use a headless CMS as the content layer of a custom storefront over Shopify or another commerce engine. Large enterprises in consumer goods, financial services, healthcare and technology are moving corporate and multi-channel content off suites such as Sitecore and Adobe Experience Manager. The companies moving toward headless are mostly large and outside retail; the ones moving back are mostly small direct-to-consumer brands.
What are the disadvantages of a headless CMS?
Buyers name developer dependence for anything that touches layout, components that have to be built before editors can work, weak or missing preview, and large rebuild efforts. One buyer said you cannot have headless and a WYSIWYG editor together — true of that implementation, though visual editing and preview are possible when the platform and front end support them — and some found the architecture more complex than their site needed.
Why are some companies moving away from a headless CMS?
In these interviews the companies going back are mostly small direct-to-consumer brands. They cite the developer time, often an outside partner's, needed for routine content changes, and commerce platforms' own storefronts that have caught up. Most return to their commerce platform's native storefront, and a few move to a visual site builder such as Webflow. Large enterprises are mostly moving the other way.
Do you need a headless CMS with Shopify?
Only if you build a custom storefront. Brands on Shopify's own themes in these interviews manage content inside Shopify with no separate CMS. Brands that go headless on Shopify add one — Contentful, Sanity, Builder.io and others — because the custom front end no longer provides it.
Get a checkup on your tech stack
A physical for your marketing stack, built from hundreds of verified buyer interviews: what matters most to you, a shortlist for your stack, and your next steps.
Start my checkupFree · no password · your answers are anonymized before they inform research like this.