What is a Headless CMS? A Practical Definition

A headless CMS is a content management system that stores and organizes content, then delivers it to any frontend through an API — usually JSON over HTTP. The word “headless” comes from the fact that the CMS has no presentation layer of its own; the “head” (the frontend) is a separate app that the CMS doesn’t know or care about.

Compare that with a traditional CMS like WordPress or Drupal 7: the CMS stores content and renders the HTML pages that visitors see. The editor, database, and templating layer are all bundled together.

In a headless CMS, those concerns get separated:

Editors log in to the CMS and manage content (content types, media, taxonomies, workflows).
Developers build a frontend app — React, Next.js, Astro, Vue, Svelte, whatever — that fetches content from the CMS API.
Visitors never touch the CMS directly. They see only the frontend.

Why would you want that?

The short answer: separation of concerns gives you flexibility you don’t have with a monolith CMS. The longer answer has three parts.

1. Frontend freedom. Traditional CMSs force you into their templating layer. WordPress means PHP templates. Drupal means Twig. Sitecore means Razor. When a new frontend framework comes along (and one always does), you either rebuild your CMS or you’re stuck. A headless setup means the frontend is just an app that hits an API — you can rebuild the frontend without touching the CMS.

2. Multi-channel delivery. If your content has to go to a website and a mobile app and a smart TV app and digital signage, a headless CMS is the obvious architecture. One backend, many frontends, one source of truth.

3. Performance and scalability. Traditional CMSs render HTML on every request (or cache aggressively, which introduces its own problems). Headless frontends can be pre-rendered at build time, served from a CDN, or streamed with server components — giving you static-site performance without the static-site editing experience.

What you give up

Headless isn’t free. The tradeoffs are real:

Preview is harder. In a traditional CMS, “preview” means “render the draft with the same templates as production.” In headless, preview requires plumbing — draft-aware API endpoints, preview tunnels, and frontend code that knows how to request unpublished content. Most headless CMS projects underestimate this.
Two apps to deploy. You now have a CMS backend and a frontend app. More moving parts, more deploys, more potential for version skew.
Editors lose “what you see is what you get.” Most headless setups give editors a form to fill in, not a visual builder. Some editorial teams hate this.
Engineering cost. A traditional CMS gives you “working website” for free. Headless gives you “API and an empty frontend to build.” You’re trading convenience for flexibility.

Headless CMS options

The market has fragmented into a few categories:

API-first SaaS: Contentful, Sanity, Storyblok, Strapi Cloud, Hygraph. You get a hosted CMS, pay per seat or per API call, and build your frontend separately.
Open-source headless-native: Strapi (self-hosted), Directus, Payload, Keystone. You run the CMS yourself and own the data.
Traditional CMS in headless mode: Drupal, WordPress, and Sitecore can all be run headless. Drupal’s JSON:API module is mature and production-tested; WordPress has WP REST API and WPGraphQL. You keep the editorial depth of a mature CMS but serve the content over an API.
Enterprise DXPs: Adobe Experience Manager, Acquia, Sitecore XM Cloud. Big, expensive, enterprise-grade.

When headless is right — and when it isn’t

Headless is a good fit when:

You have a complex content model (taxonomies, relationships, multi-site, multilingual) that needs a mature CMS.
You want a modern frontend (React, Next.js, Astro) for performance and DX reasons.
You ship content to multiple channels, not just one website.
Your editorial team is comfortable with form-based editing and preview-via-tunnel.

Headless is usually the wrong fit when:

You’re building a marketing brochure site with 10 pages. A Hugo or Astro content collection is simpler.
Your editors expect a visual builder and will hate you for taking it away.
You don’t have frontend engineering capacity. You’ll end up with half a migration and an unhappy team.

Where decoupled Drupal fits

Drupal is particularly interesting as a headless CMS because it’s one of the few mature, open-source CMSs with genuinely strong editorial features (content moderation, revisions, media management, Paragraphs, Layout Builder) and a first-class JSON:API layer. You don’t have to give up workflow sophistication to get modern frontend flexibility.

We call this decoupled Drupal — Drupal stays the CMS, but the frontend is whatever modern framework your team wants to use. Read more about how decoupled Drupal works →

TL;DR

A headless CMS separates content management from content presentation. Content lives in the CMS, gets delivered via API, and is rendered by a separate frontend app. The upside is flexibility, performance, and multi-channel delivery. The downside is complexity, preview plumbing, and a steeper engineering cost. Whether it’s right for you depends mostly on how complex your content model is and how mature your frontend team is.

If you’re thinking about going headless but aren’t sure whether it’s the right move — tell us about your project. We’ll give you a straight answer, even if the answer is “stay traditional.”