Headless and decoupled CMS: the essential guide

What is headless, who is the audience, what are the use cases

This article will teach you the concept of the Headless CMS. You will also learn how the headless approach is different from working with a traditional CMS like WordPress or Drupal.

Table of contents

What is a headless CMS

A headless CMS has its front-end component (the head) removed, and what remains is a backend delivering content via an RESTful API. Because of its backend-only nature, it does not care about how the content is displayed: its focus is just on storing and delivering the content, and nothing more.

Its counterpart is a standard multi-purpose CMS – often referred to as monolithic or coupled – like WordPress or Drupal. Let's take WordPress as an example, which consists of several components:

  1. A database where the content is stored
  2. A web app in which editors work with the content (also known as the admin interface)
  3. A part of the web app for managing the website's design;
  4. A front-end which takes the content from the database and generates HTML pages.

Imagine that we remove (3) and (4) from this setup. The head of the CMS, the website itself, is no longer there: what remains is a backend for handling content storage and distribution, and a web app for editors. That's it, that's the entire CMS.

Unlike with a monolithic CMS setup, a headless CMS is not the only thing you need to create a website. By design, it lacks the features to do so, as there is simply no concept of theme or template. A developer would need to build the website, and use API of the headless CMS to access the content.

At first, this may seem counterproductive, and there could be objections to this different paradigm: "working with a single software is simpler than working with two", or "building a front-end is hard and time-consuming". These are fair points, and they do apply to a variety of cases. This is why there is no definitive answer to the question "is a monolithic CMS better than a headless CMS?" It just depends on your needs, there are use cases where one is better than the other, and vice versa.

Audience and use cases of monolithic vs headless CMS

The most prominent use cases for headless content management are:

  • Websites and web apps that use JavaScript frameworks such as React, AngularJS, and VueJS.
  • Mobile apps.
  • Websites built using static site generator.
  • Ecosystems of apps and websites where the same content needs to be published on multiple channels.

A headless CMS is the best choice for all those who feel limited by the front-end restrictions of a standard CMS. Rich web apps, custom layouts, and JavaScript frameworks don't quite fit into the architecture of a CMS which closely controls how content looks. To keep development simple, it's just better to have a clean setup from the beginning.

It's not only for websites, though. A headless CMS usually delivers content through an API, which means that it can deliver content anywhere, on any device. This is great news for mobile app developers, because with this approach the same backend can deliver content to an iOS app, an Android app, or any other medium.

So, headless proves to be hugely beneficial for cross-platform publishing and custom user experiences. It makes publishers, designers, and developers happy, who in turn will provide great products for their users. But if your use case is just a simple company website with only a handful of pages, a headless CMS may be an overkill. Your good old WordPress will perfectly cover that use case, and dozens of similar ones.

Traditionally monolithic CMSs have been trying to fix their mistakes and promote themselves as headless. The most popular PHP options for going down that path are:

  • Headless Wordpress, with JSON API plugin. It's possible to install the JSON API or JSON REST API plugins on top of WordPress, and use it exclusively as a headless CMS. This setup offers a simple API, and it has the advantage of keeping the same software and editorial workflows as ever. However, they're still third-party plugins, which means that there is no official support, they offer limited capabilities, and as with many WordPress plugins, they could cause conflicts with newer versions of the software, or even security problems.
  • Headless Drupal: RESTful module or Drupal 7 with RESTful Web Services module; Drupal 8 actually includes a RESTful Web Services module in its core. Thanks to the huge Drupal community and core support, this may seem like a good choice. However, Drupal is fundamentally a tool for building websites the Drupal way, which can cause problems when deviating from that path (especially in the case of app development). Furthermore, Drupal's architecture hardly plays well with the lean and fast approach which is often required when adopting a headless CMS, therefore performance is often a issue.

Overall, we can see that these two options try to make the CMS work in way that they were not designed to. In fact, both WordPress and Drupal don't scale well when using them as headless, because their monolithic nature doesn't allow them to be as flexible and performant as needed.

Contentful, the API-first content management backend

Unlike Headless Wordpress or Headless Drupal, Contentful was built from the ground up to be a headless CMS. This means that you won't find many of the unsatisfying things that you would see in a monolithic CMS that was repurposed to be headless, such as insufficient performance, limited capabilities, bad documentation, and inconsistent support.

A short side-by-side comparison of Contentful vs. Drupal vs. Wordpress can be found here.

Of course, this requires you to adopt a different mindset and introduce concepts such as content modeling and search-based management (instead of tree-based). However, we are sure that the advantages that this new paradigm can provide are real and substantial, which is why the change is worth the effort.


While we can say that there is no single right approach and CMS for every use case, we strongly believe that the separation of concerns typical of a headless CMS will help make building most of real-world projects easier, and this is why we built Contentful.

So give Contentful a try, it's quick and easy — and free for small plans!

Discover more Contentful.

If you enjoyed this article, you might like our product as well.

What our product does

Take a look at the API capabilities, delivery infrastructure and friendly editing environment.
See features

What our clients built

From apps and sites to digital signage and iBeacon campaigns — we deliver content everywhere.
See real-life examples