Quick answer: A headless CMS is a content management system without a built in front end. Editors still write and organise content in an admin area, but instead of the CMS producing web pages, it makes the content available through an API. Your website, mobile app, in store screen or any other channel then fetches the content and displays it however it likes. It suits businesses that publish the same content in several places or want full freedom over the front end. It adds cost and complexity compared with a traditional CMS, so it is not the right default for a simple marketing site.
A traditional CMS such as WordPress or Drupal does two jobs: it stores content and it turns that content into web pages using themes and templates. The “head” in headless refers to that second job, the presentation layer. Take it away and you are left with a content store with an editing interface and an API.
How a headless CMS works
The setup has three parts:
- The content repository and editing interface. Editors log in, create entries, upload images and publish, much as they would in any CMS.
- The API. Published content is available over HTTP, usually as JSON, through a REST API. A front end asks for “the latest five blog posts” or “the product page with this ID” and gets structured data back.
- The front ends. One or more separate applications fetch content from the API and render it. This could be a website built in any language, a native iPhone or Android app, a single page JavaScript application or a digital display.
If you are not sure how APIs fit together, our explainer on what an API is covers the basics.
Traditional, decoupled and headless
These terms are often mixed up:
- Traditional (coupled) CMS: content and presentation live in the same system. WordPress with a theme is the classic example.
- Decoupled CMS: the CMS still has its own front end, but it also exposes content through an API so other channels can use it.
- Headless CMS: there is no front end at all. The API is the only way content leaves the system.
In practice the lines blur. A traditional CMS with a good API can be used in a decoupled or headless way.
Why businesses choose headless
Publish once, show everywhere
If your content appears on a website, an iOS app, an Android app and perhaps a partner’s site, keeping it in sync across separate systems is painful. A headless CMS gives you one source of truth. Update a product description once and every channel shows the new version.
Front end freedom
Developers can build the front end with whatever tools suit the job, whether that is a JavaScript framework such as React or Angular, a static site generator or a server side language. They are not tied to the CMS’s templating system or its release schedule.
Structured content
Headless systems push you to model content as structured fields (title, summary, price, author, related items) rather than one big block of formatted text. Structured content is easier to reuse, reformat and filter. It is good practice even if you stay with a traditional CMS.
Security and performance
The editing system can sit behind a firewall or on a separate domain, away from public traffic. The public front end only reads data, which reduces what attackers can target. Combined with caching or a static build, this can be very fast.
The main options
Hosted headless CMS services
- Contentful is a hosted service with a flexible content model, a REST API and a content delivery network in front of it. Pricing is by usage and features.
- Prismic is another hosted option, with a focus on editor friendly content types and slices of page content.
Hosted services remove the need to run servers for the CMS. You pay a monthly fee and depend on the provider.
Open source CMS used headless
- WordPress has a REST API under active development. The underlying infrastructure was merged into core in version 4.4, but the content endpoints are still a separate feature plugin (version 2, in beta). Many teams are already building on it, while accepting that some details may change before it joins core.
- Drupal 8, released late last year, includes a REST API in core and is a common choice for decoupled builds.
Using an open source CMS this way gives you full control and no licence fee, but you host and maintain it yourself.
Static site generators fed by a CMS
Some teams pull content from a headless CMS at build time and pass it to a static site generator. The result is a plain HTML site, rebuilt whenever content changes. See our guide to static site generators for how that side works.
The trade-offs
Headless is not free. Be clear about what you give up.
You build the front end yourself
There are no themes to install. Every page template, menu and layout is custom development. That is more upfront work, and ongoing development whenever you want to change how something looks.
Editors lose some conveniences
With a traditional CMS, editors can preview a page exactly as it will look before publishing. With headless, preview needs to be built specially, because the CMS does not know how the front end will display content. The same goes for drag and drop layouts and inline editing.
Plugins do not carry over
In WordPress, an SEO plugin adds meta tags to your theme automatically. In a headless build, the front end has to output those tags itself, using data from the API. The same applies to forms, sitemaps, redirects and analytics.
SEO needs attention
If the front end is a JavaScript application that renders in the browser, search engines may struggle to see content. Server side rendering, or pre rendering pages, avoids this. Analytics tracking also needs care in single page apps.
Two systems to run
You now maintain the CMS and at least one separate front end. Hosting, monitoring and deployment cover both.
When headless makes sense
Headless is worth considering when:
- Content is published to more than one channel, such as a website and native apps.
- The front end needs to do things a theme system makes awkward, such as a highly interactive application.
- You have developers on hand to build and maintain the front end.
- Content is highly structured and reused in many places.
A traditional CMS is likely the better choice when:
- You have one website and no plans for other channels.
- Marketing staff need to build and rearrange pages without a developer.
- Budget is limited and a theme plus a few plugins would do the job.
Planning a headless build
If you decide to go ahead:
- Model your content first. List every content type and its fields before choosing a CMS.
- Check the API. Look at filtering, pagination, image handling and rate limits. Good REST API design makes the front end far easier to build.
- Plan preview and workflow. Decide how editors will check content before it goes live.
- Cover SEO basics in the front end. Titles, descriptions, canonical tags, sitemaps and redirects.
- Cache API responses. Avoid hitting the API on every page view.
FAQ
Is a headless CMS faster?
It can be, especially with caching or static builds, but speed depends on how the front end is built. A badly built front end will be slow regardless of the CMS.
Can WordPress be used as a headless CMS?
Yes. With the REST API plugin, WordPress can serve content to any front end. Expect some changes as the API moves towards core.
Is headless more secure?
It can reduce exposure, because the editing system is separated from public traffic. You still need to secure the API, the CMS and the front end.
Building beyond a single website
Headless architecture is a tool for specific problems, not a trend to follow for its own sake. We help businesses decide whether it fits, then design the content model, API and front end together. See our approach to custom development.
