This article will tell you everything there is worth knowing on the topic of headless CMSs, also sometimes called decoupled CMSs. You'll learn what headless exactly means, how it is different from the CMSs which you know, why you should care, and who and when should use them. Some etymology and history come as a bonus. Shall we?
A headless CMS has its front-end component (the head) stripped and removed from its backend, and what remains is a backend delivering content via an API. It thus does not care how and where the content is displayed, and focuses on storing and delivering the content and provides tools to create and organize it – nothing more.
Its counterpart is a standard multi-purpose CMS – coupled CMS – like WordPress or Drupal, which is built in such a way that it is also responsible for giving shape to the content, transforming it into HTML pages and even complete websites.
The most prominent use cases for a headless CMS are:
Let's take WordPress as a well-established example. A traditional CMS of this type consists of several components: 0) a database where the content is stored, 1) a web app in which editors work with the content (also known as the admin interface), 2) a web app in which publishers create and design templates which comprise the website, 3) a front-end which takes the content from the database and generates HTML web pages.
Imagine that we remove (2) and (3) from this setup. The head of the CMS – the website itself – is no longer there. You still have a backend which stores and delivers the content and you still have a web app for editors, and that's it. That's the entire CMS.
Such setup is called headless.
The website visitors will not see a Drupal (or any other CMS) theme at the top, and this is where the word headless comes from: the traditional Drupal head is missing.
In contrast to WordPress, you would not create a website exclusively with a headless CMS. Typically there are no instruments to do so: a headless CMS has no page templates, no themes, none of all these somewhat aged concepts. Instead, you would build the website separately – with the skills of a talented engineer on your team – while the CMS will be readily pouring content into its pages, serving it from an API.
"How is that better", you might be wondering, "and why should I care?" It's only natural to assume that having no front end is actually worse than a full-fledged CMS of old. It also might be natural to think that working with a single software is better and simpler than with two or several. But bear with us.
The motivation for different CMSs (and for this article) is because there is no single better for any given project. There are different use cases and different circumstances is which going headless makes way more sense. We're exploring them in the next paragraphs.
It's not only for websites, though. A headless CMS usually delivers content through an API (oftentimes RESTful JSON API), which means that it can deliver content anywhere, on any device. This might immediately ring a bell in the mind of mobile app developers. Yes, headless enables delivering the same content to an iOS app and Android app from one backend – the same backend that would deliver content to the website or any other medium.
So, headless proves hugely beneficial for cross-platform publishing and custom user experiences. It makes publishers, designers and developers happy and, eventually, helps building better products for the public.
If your use case is just a simple old six-page company website, a headless CMS often times is an overkill. Your good old WordPress, Drupal and similar traditional CMSs will perfectly cover that use case and dozens of similar ones.
There is no single right approach and CMS for every use case. However, our intuition and experience suggest that any app-focused project, be it rich web apps or mobile apps, would greatly benefit from using a headless CMS.