In short
A headless CMS is a content management system that only manages content and delivers it via an interface (API), but does not generate finished web pages itself. The "head", meaning the presentation layer, is missing.
Which website, app or screen displays the content is decided by a separate front end that retrieves the data via a REST or GraphQL API.
How a headless CMS works
In a classic ("coupled") CMS such as WordPress, or TYPO3 in standard operation, editing, data storage and template rendering sit in one system. A headless CMS separates them: the back end stores structured content such as pages, articles, products or team members and provides it as JSON. The front end, often built with Next.js, Nuxt or as a native app, fetches the data and renders it. So that search engines and AI crawlers can see the content, the front end should render on the server; more on this under server-side rendering.
When the editorial team updates a piece of content, the CMS usually notifies the front end via webhook so that the cache is renewed in a targeted way.
Types of headless CMS
- API-first systems such as Contentful, Strapi, Storyblok or Sanity were built from the start without a front end of their own.
- Classic CMSs in headless mode such as TYPO3 with EXT:headless, or WordPress via its REST API, keep their back end and additionally deliver JSON.
- Commerce systems such as Shopware with its Store API follow the same principle for shops, see headless commerce.
| Criterion | Traditional CMS | Headless CMS |
|---|---|---|
| Front end | built in (templates, themes) | separate, freely selectable |
| Channels | mainly one website | website, app, displays, shop |
| Preview for editors | built in directly | has to be built in the front end |
| Development effort | lower | higher, but with more freedom |
| Operation | one system | two systems, each with its own deployment |
When a headless CMS pays off
A headless CMS plays to its strengths when the same content appears in several channels, when a development team wants to work with React or Vue, or when the website is part of a larger platform with a portal or shop. For a simple company website, a traditional CMS is usually cheaper because preview, templates and operation are already in place there.
A practical example
A mid-sized company maintains product information, job advertisements and news in TYPO3. With EXT:headless, TYPO3 delivers this content as JSON to a Next.js website and at the same time to the employee app. The editorial team maintains everything in one place, and both channels stay up to date automatically. How this works technically is shown in our article Headless TYPO3 with Next.js; more on TYPO3 itself in the entry TYPO3.
Frequently asked questions about headless CMS
What is the difference between a headless CMS and headless commerce?
A headless CMS manages editorial content, while headless commerce separates the front end of a shop system from its commerce logic. Both follow the same principle and are often combined.
Is a headless CMS faster?
Not automatically. Speed depends on the front end and on caching. A well-cached traditional CMS can be just as fast.
Do I need developers for a headless CMS?
Yes. Someone has to build and run the front end. After that, the editorial team works in the back end as usual.