In short, “headless CMS” means you can deliver your content to several different applications simultaneously, as your system does not have just one “head”.
CMS stands for Content Management System, and is a way for you to create, edit, and publish your content. The point of headless is that you do not want a fixed, predefined head—you can choose the head/heads for your CMS yourself.
What is the difference between a traditional CMS and a Headless CMS?
To give a proper explanation of what a headless CMS is, it makes the most sense to compare it with a traditional CMS. If you find it a bit confusing, do not worry—I will use a stick figure as a small metaphor to explain the difference between the two.
The legs are your editor interface, where you can create, edit, and publish your content—and what is needed for everything to work and keep running. Next, you have your content database, which is your body and the heart of your data. Finally, you have your head, which is your representation of your data—in other words, what visitors to the application will see. This could, for example, be your website, webshop, digital product catalogue, or an app.
The point here is that in a traditional CMS, the head is an integrated part of your CMS, and is therefore often referred to as a monolith—one single, unified unit. The data structure and support for communication protocols are therefore typically built around having only one head, which cannot be separated from the other parts.
On the other hand, you have a headless CMS—and we will stick with the stick-figure metaphor. You still have your editor interface and your data backend with your content, such as products, blog posts, news, and so on. This is where your content database lives. In that sense, it resembles a traditional CMS. However, a headless CMS architecture is built around focusing on content, which works to your advantage.
The difference is that your CMS is now headless, which means you simply decouple the head that would normally be integrated with your CMS.
With headless, you choose which application/applications your content data is sent to—your head/heads.
Your heads could, for example, be a website, a product catalogue, and an app. This also means you no longer lock your head to a specific technology or programming language.
You typically cannot do this in the same way with a traditional CMS, because everything is usually built in an architecture focused on keeping it all tightly connected. In addition, a traditional CMS typically includes a lot of other functionality that may have nothing to do with content. To sum up, the point is that you can choose the head/heads yourself when you use a headless CMS.
Benefits of a headless CMS
The benefit of headless is that you can choose which heads (website, product catalogue, webshop, etc.) you send your content data to. Your content is simply delivered as data via a given API. This makes it developer-friendly, as the developer is provided with content data and can decide which technologies and programming languages to use, and how to present the data in their interfaces.
It also makes it easier for editors to publish and edit content across applications from a single CMS. You can replace or add new heads without affecting the other heads. If you use a traditional CMS, you typically have to replace the entire CMS and move all your content to the new application.
In addition, there is another benefit: you have the option to use the same content data across your heads (applications), allowing you to connect multiple websites or apps to the same content. This means you can save internal resources, as editors do not need to log into 10 different systems to edit content.
When we look at the disadvantages, there are of course also things you need to consider. A headless CMS will place greater demands on how you structure your data and architecture from the outset. In most cases, it will also require a developer when you need to build new applications. With a traditional CMS, you can sometimes get further as a general user without developer skills, because you can build your head (UI) yourself in, for example, WordPress, which most people are familiar with.
Initial costs of choosing headless can in some cases be higher, but you will typically gain in the long run in terms of scalability and maintenance. If, on the other hand, you are a large retail chain—or you simply know you will expand the number of applications that need the same content—then in the long term it can be far cheaper for you.
The reason is that you avoid building multiple standalone monoliths, where you need many different developers to maintain each CMS. In that case, headless makes more sense, as all content is gathered in one place. However, you should always seek advice, as the choice typically depends on what needs you want to meet.
Why has headless CMS become a topic of discussion?
Because the number of technologies and ways to build applications is growing rapidly. In other words, there is an increasing need to avoid having an editor for each individual thing, and instead manage all content from one place.
In other words, you use the concept of “separation of concern” by placing responsibility for content in one place, which can make it a more future-proof solution.
That said, it has also become a bit of a buzzword. The concept of decoupling server-side from client-side has existed for a long time, but there is now increased focus on it in relation to content.
To wrap up…
I hope this makes a bit more sense now. If you still find it somewhat complex, I have summarised the key points below:
The point of headless is that you do not want a fixed, predefined head—you can define multiple heads yourself that use your content.
The difference between a traditional CMS and a headless CMS is that the architecture in a traditional CMS is built around your interface being coupled with your backend, whereas in a headless CMS the heads are decoupled.
The benefit of a headless CMS is that you can send your content from one place to multiple applications.
The downside of headless is that you typically need developers and a well-thought-out architecture, which can increase your initial costs.
Now that what a headless CMS is—and its advantages and disadvantages—has been described, it is natural to ask: how is it used? Read more about that here.
