What is Headless CMS?

The content is just content

A headless CMS only takes care of content - it is completely separate from design, features and templates. The content thus becomes platform-independent and via an API it can be presented through any interface.

Common CMS tools like Umbraco, Optimizely and WordPress consist of both parts; i.e. content as well as appearance, features and templates.

We often get questions from our clients about headless like “What is a headless CMS?” and “Do we need a headless CMS in our upcoming project?” We love good questions and we know a lot about both headless and traditional CMSs and will try to answer the seven most common questions here.

1. Why is it called headless?

The word headless refers to the CMS delivering information to another system that presents the information to the visitor. The analogy is therefore that the head is what communicates the information to the user and in a headless CMS you have removed the head.

Imagine that the technical system you use to publish content on the web is a person:

• In the legs we have the actual administration part, i.e. the place where you as an editor log in, create pages, write texts and upload images
• In the body all content is stored, in a database or as files
• The head is what communicates, i.e. the website where your content is shown to visitors

If we remove the head from our CMS-person we still have the legs for administration and the body for data storage. We still need a head to be able to communicate, it's just that it isn't built into the CMS.

Instead, a headless CMS exposes data via an API that another application (another head) can use to communicate.

Since the content is just data, you can communicate this data in any way you want - as a website, a chatbot, a store screen or a mobile app. You are not limited to one head - the body can therefore have several heads at the same time.

So it’s called headless because you have removed the part of the CMS that generates pages (the head).

2. Is a headless CMS better than a traditional CMS?

No. It can’t be compared that way.

Headless is an answer to a need that has arisen in recent years - to be able to separate the administration of information from how it is presented. There are several reasons:

• It gives great flexibility when developing new services. With a headless CMS you are not tied to the CMS’s technical base but can build new services on any technical platform you want, as long as it can communicate with an API. Services can be changed and expanded without needing to modify the CMS because they are separated.
• The ability to quickly administer and communicate the same information across multiple parallel channels. Visitors receive the same message whether it’s on a website, an app, a chatbot or a smartwatch. Change it in one place and it goes out to all channels at once.
• Modern service-oriented websites are often interactive and application-like. Interactivity can be created with JavaScript - the more interactivity, the more JavaScript. When the threshold is reached where the amount of JavaScript exceeds ordinary HTML, it is more efficient to build everything in JavaScript and then a traditional CMS can feel more like an obstacle.

3. What does headless mean for an editor?

While there are clear advantages, the headless architecture also creates new problems. Editors who are used to working with both the information and how it is presented directly in the CMS may feel somewhat constrained by the headless architecture. The editor can still specify what is the headline, lead and body text on a page even with a headless CMS. However, it can become problematic if the editor wants to build custom page layouts based on modules or control column divisions, positioning, etc.

From a principled perspective it is problematic to tie information to instructions for how it should be presented because you then begin to "pollute" the data model that should consist of presentation-neutral information with information that dictates how the information should be presented in a specific context. Once you start down that path you begin to create obstacles to being able to reuse the same information in completely new contexts.

From a practical perspective it is problematic because you have probably chosen the wrong CMS. If, as an editor, you want to have extensive dynamic control not only over the information but also over presentation and layout directly in the CMS, you should choose a CMS that enables this from the start. The likelihood is then that you want a traditional CMS rather than a headless CMS.

Puffs, blocks, columns and layouts are not at all as self-evident concepts in a headless CMS as they are in a traditional CMS because they primarily concern how information is presented. A website built with a headless CMS can definitely have all of this, but it is not in the CMS that appearance and layout are controlled. That is done in the technical solution that fetches data from the headless CMS. If you want to make design changes there you need to involve developers.

4. Do you have to use a headless CMS to be technically cutting-edge?

No.

Both traditional and headless CMSs keep up with technological development. One solution is not more technically advanced than the other, and it’s not the case that all new development and technical brilliance automatically flows into headless CMSs. However, the market for traditional CMSs is mature and well established while the headless phenomenon and the technical ecosystem that has arisen around it should be considered relatively new. That is why there is more talk about headless, which can give the impression that it is there (and only there) that new exciting possibilities are created.

So you are not choosing old technology just because you choose a traditional CMS. You should choose a CMS based on current and future needs.

5. Will headless CMSs replace traditional CMSs in the long run?

No. We think the question is wrongly posed.

Technical solutions tend to shape themselves around needs. We know there is a strong need to be able to administer digital information both now and in the future. Both headless CMSs and traditional CMSs are solutions developed in response to that need. The similarities between headless CMSs and traditional CMSs are therefore greater than the differences precisely because they start from the same need. To then pit them against each other and try to crown a future winner becomes too categorical.

If we were to venture a guess, the most likely scenario is that the different variants of CMS will merge over time so that in the same CMS you can choose whether you want to build your solution with a pure data API or generate pages from page templates, or have a hybrid solution. We believe this kind of flexibility will be demanded by both customers and developers. For a company that develops a CMS, it should be attractive to have a broad market where a customer can choose their CMS whether they want an API or generated pages.

6. Is it more expensive to build a website with a headless CMS compared with a traditional CMS?

The short answer is yes because in practice you are building two separate solutions: an administrative system in the form of a headless CMS and the actual web solution that presents the information and provides interactivity, e.g. a JavaScript-driven web application. Separating the administration of data from how it is presented therefore comes with a cost in the form of longer development time. Features that usually come included in ordinary CMS tools are missing, e.g. preview of unpublished pages.

At the same time you get advantages. If you later discover that you want to present the information in a completely different way or need to add more channels, you can do so without having to make changes in the CMS and thus save a lot of time.

In summary, you should think of building two "things": an administration part and a presentation part. They will be two completely separate products and meet only via the API.

7. Which headless options are there?

There are many different headless CMSs

• Contentful
• Headless WordPress
• Headless Drupal
• Kontent by Kentico
• Magnolia
• Agility CMS
• Butter CMS
• Contentstack
• Bloomreach
• Netlify

Most pure headless CMSs are built on JavaScript and Node (JavaScript on the server side), but there are also alternatives developed in other environments, e.g. Microsoft .NET

In summary

A Headless CMS manages the content and is completely separated from design, functionality and presentation. The choice of CMS should be made based on the needs that exist - both current and future.

If you want help mapping your needs and which type of CMS might be suitable – get in touch with us and we will help you!

Also read