What Is a Headless CMS? How It Works and When to Use One

A headless CMS is a content management system that stores and edits content but doesn't build the pages people see. Editors write in the CMS, the content is sent through an API, and a separate front end, written by developers, turns it into web pages. The "head" that's missing is the presentation layer that a traditional CMS includes. This explainer is part of our website design best practices guide.

Below, we cover how the split works, how it compares with a traditional CMS, when it's worth it and what it changes for previews, speed and accessibility.

How a headless CMS works

A content management system is software that lets people publish, organize, change and remove content: text, images, video and more. A traditional CMS does all of that and also produces the pages, using themes or templates stored inside it.

A headless CMS stops at the content. Developers first set up a content model: the types of content the site needs, such as service pages, case studies and blog posts, and the fields each one has. Editors fill in those fields. The CMS then makes the content available through an API, usually as structured data such as JSON.

The front end is a separate codebase, often built with a framework such as Next.js. It requests content from the API and renders it into HTML, either ahead of time or on each request. Because the content isn't tied to one set of pages, the same entries can also feed an app, an email or a screen in a showroom.

Headless vs traditional CMS

The main differences come down to who controls what. A traditional CMS bundles content and presentation; a headless one splits them:

Neither is better in general. They suit different teams and different sites.

When headless is worth it

A headless CMS earns its extra setup when at least one of these is true:

• The design is fully custom. Developers have complete control over the HTML, so nothing from a theme gets in the way of speed, accessibility or the brand.
• Content appears in more than one place. One set of entries can feed the website and an app, so nobody copies text between systems.
• Performance matters a lot. The front end can build pages statically and serve them from a CDN, which suits the approaches compared in server-side rendering vs static site generation.
• Content needs structure. Fields for things like team members, case studies or FAQs keep content consistent and reusable across pages.

When a traditional or visual CMS fits better

The split has costs. Every new layout or page type needs a developer, because templates live in the front-end code. There are two systems to host and maintain instead of one. And editors lose the instant, on-page editing that visual builders offer, unless a preview is set up.

So a small marketing site that a non-technical team updates often, and that rarely needs new layouts, is usually better served by a visual platform with a built-in CMS. We build custom Next.js sites as well as sites on visual platforms, and we compare them in our post Next.js vs Webflow vs Framer.

Previews, publishing and speed

Two practical questions decide whether editors are happy with a headless setup.

Can they preview before publishing? Since the CMS doesn't render pages, the front end has to. Frameworks support this: Next.js, for example, has a Draft Mode that lets editors see how draft content will look on the real site, and its documentation notes that most headless CMSs support configurable preview URLs.

How fast do changes go live? If pages are built statically, publishing has to trigger an update. A common pattern is for the CMS to notify the front end when content changes, so it rebuilds only the affected pages. In Next.js, that's on-demand revalidation. Without it, editors may publish and wonder why nothing changed.

Agree both before launch, and test them with the people who'll use them.

Accessibility starts in the editor

Most accessibility problems on content-managed sites are introduced when content is added, not when the site is built. A missing alt text, a heading picked for its size or a "click here" link all come from the editor. A headless CMS, with its structured fields, is a good chance to prevent them.

The W3C's Authoring Tool Accessibility Guidelines (ATAG) cover this. ATAG treats a CMS as an authoring tool, and its Part B is about the tool helping authors produce accessible content. Published in 2015 alongside WCAG 2.0, it still applies, and the W3C recommends pairing it with the latest version of WCAG.

In practice, set up the content model so the accessible choice is the easy one:

• Make alt text a field next to every image, with a way to mark an image as decorative. WCAG's Non-text Content criterion asks for text alternatives for meaningful images.
• Use heading fields, not font sizes. Editors choose a section heading, and the front end renders the right level, so the outline stays in order.
• Keep text as text. Fields for headlines and buttons avoid images of text, which WCAG's Images of Text criterion asks you to avoid.
• Ask for link text that makes sense. A short help note on link fields steers editors away from "read more" without context.

ATAG's Part A also matters: the editing interface itself should be usable by editors with disabilities. Check this before choosing a CMS.

If you'd rather have the content side planned for you, our in-house web team designs and develops sites with SEO foundations built in. If you're moving an existing site, follow how to migrate a website without losing SEO.