What Is a Headless CMS? Explained Simply

A headless CMS is a content management system that stores content and provides it over an application programming interface (API), without delivering a website itself. The visible frontend – what visitors see in the browser – is developed separately. The same content can then be delivered across multiple channels with no extra effort: website, app, newsletter.

Search the web for “headless CMS” and you’ll mostly find vendor marketing. Not this article. Here it’s about what’s actually behind the term – no advertising, no hype.

What is a headless CMS?

In a classic CMS like WordPress, content management and website delivery are bundled into one system. You write a post, WordPress turns it into a finished HTML page and serves it. Convenient – but it couples your content to a specific presentation logic and to exactly one delivery channel.

“Headless” literally means “without a head”. The head is the frontend – the visible website. A headless CMS delivers only the body: the content, structured in a format like JSON, provided over an API. The frontend – the page visitors see – is built by a separate system.

This is no cure-all. It’s an architecture decision with clear advantages on one side and real costs on the other.

How does a headless CMS work?

Classic CMS: everything in one system

In a classic setup, both run on the same server. An editor writes in the backend, the CMS turns it into HTML and delivers it. For one delivery channel – the website – this works smoothly and without extra complexity. You need no second system, no defined publishing path, no API connection.

Headless CMS: separated layers

In a headless setup there are two independent layers:

Content management (the CMS): here an editor maintains text, images and metadata. The CMS stores them in a structured way – for example as a JSON object with fields for title, teaser, image URL and publication date.

Frontend: a developer builds a separate website or app that fetches the content over the CMS’s API and turns it into HTML. That can be Astro, Next.js, React Native or any other framework.

The flow in practice: editor creates content in the CMS → CMS stores it → frontend fetches it via API → visitor sees the finished page.

That sounds more involved – and it is. The gain is that the frontend is freely selectable and the same content can be delivered across several channels with no extra effort.

Advantages and limits

Headless is often presented as pure progress. It isn’t – it’s a trade-off. What you gain, and what you pay for it:

What you gain

Channel independence. Content maintained once can be delivered anywhere over the API: website, mobile app, newsletter, digital signage, voice interface.

Free frontend choice. The frontend can be developed in any technology. No CMS dictates how the presentation must look or which templates are available.

Better performance. Since the CMS doesn’t generate pages dynamically, the frontend can be delivered as a static site – which is significantly faster and makes hosting considerably simpler.

Independent development. CMS and frontend can be developed and scaled separately. One team works on the frontend without touching the CMS.

What you take on in return

More system complexity. Two systems instead of one. A publishing path has to be defined. Updates have to be planned for both systems. If the CMS goes down, content editing goes down with it.

Higher development effort. The frontend has to be built entirely. There’s no themes system to fall back on.

No classic WYSIWYG by default. Some systems – Storyblok, for example – now offer a visual editor with live preview. But that isn’t standard everywhere and requires additional configuration.

For an honest comparison of the different headless approaches – dedicated SaaS CMS, WordPress headless, Git-based, self-hosted – the Headless CMS comparison is worth reading.

Who headless is a good fit for

Three scenarios in which headless is the right choice:

Multiple delivery channels. When the same content should appear on a website, in an app and on digital-signage displays without being maintained multiple times. That’s the strongest reason for headless.

Performance as a requirement. When load times are business-critical – for high traffic, for e-commerce sites, or for projects where Core Web Vitals feed directly into conversion.

Frontend independence. When your development team wants to build the frontend in a specific technology and the CMS should only deliver data – without constraints from template systems or CMS-native rendering logic.

If none of these scenarios applies to you – if you run a website with one editor and one delivery channel – headless is usually over-dimensioned. A classic CMS is the more honest and cheaper choice then.

Well-known headless CMS systems

A brief overview without a buying recommendation. For a detailed assessment with costs, GDPR evaluation and concrete recommendations by project type, the Headless CMS comparison is worth reading.

Storyblok – SaaS from Vienna, with a visually editable frontend (Visual Editor). Popular with agencies and marketing teams that want to offer editors a WYSIWYG interface.

Sanity – SaaS from Oslo, with a very flexible, schema-based approach. Good for projects with complex, heavily customised content structures and their own development team.

Strapi – open source, self-hosted or as a managed solution. Gives full control over data structure and hosting – GDPR-compliant EU hosting included.

Directus – open source, self-hosted or SaaS. Directus sits on top of an existing SQL database instead of imposing its own structure. Good for data-driven projects.

WordPress headless – WordPress as a pure backend with a JSON API. No new system to learn, existing editorial processes kept. How that works in combination with Astro as the frontend is described in Headless WordPress with Astro.

If you’re planning a headless project – from system choice through API integration to building the frontend – we’re glad to help: Headless CMS development.