Headless CMS - An Introduction for Non-Technical People

So-called headless content management systems, such as those from Contentful or StoryBlok, are increasingly becoming the focus of the digital marketing and e-commerce communities in the DACH region. Buzzwords such as "Decoupled" or "Composable" are being used. But all these terms are rather familiar to technicians who deal with the underlying technology of websites and online stores. To help non-technical people understand what it's all about, we'll explain what a headless CMS is and how it differs from conventional content management systems.

What Is a Headless CMS and How Does It Differ From a Conventional CMS?

From the point of view of the CMS user or editor, a headless CMS is no different from a conventional CMS. The basic mechanisms are always the same, whether headless or conventional CMS. A CMS has the task of editing, processing and presenting content. "Editing" means that the editorial process takes place in the CMS, i.e. content is created, edited and deleted. In connection with these tasks, a CMS also often provides functions related to roles, rights, workflows, release mechanisms, translations and media assets, i.e. images and videos. These tasks are the same for a traditional CMS and a headless CMS.
In terms of processing, it's about aggregating information. For example, when looking at press releases on a website, you want to see the last five articles sorted by date. That kind of aggregation - content processing - has to happen somewhere. The display makes it all look visually the way you'd expect.

How Do the Processes Differ Between a Conventional CMS and a Headless CMS?

There is always a presentation layer that ensures that content is visually displayed correctly on websites or other channels. A CMS not only has the task of storing and providing data, but should also process it visually so that it is processed in the layout on the page.

Conventional CMS = Coupled

During the editing process in conventional content management systems, you may be tied to page-based models, which means you are always working with a single web page in the CMS. In a conventional CMS, the content is always linked to its presentation: Thus, in the editorial menu of a single web page, text and media are created and modified, and how that text and media should be presented on that web page is determined. It is a self-contained service, so to speak. We call this a coupled system.

Headless CMS = Decoupled

In a decoupled system, the editorial platform and the presentation layer are separated from each other. They are two separate services that are synchronized by a process between them. The headless CMS has on one side all editorial functionalities, i.e. everything for creating and processing content, and on the other side an interface to the outside world that provides the information in a standardized technical format, i.e. not visually prepared, but already aggregated. The headless CMS always gives a technical output, so it does not create HTML code itself, which is needed for the presentation of the content. Because the latter is the task of the Presentation Layer.

Examples for Illustration

A simple example is the output of data on a website:

A traditional CMS uses the data stored in the CMS and processes it into custom HTML to describe the layout of the page and display the content. This is then combined with stylesheets for the design and Javascript for the behavior of the page.
With the headless CMS, things are different. The data stored in the CMS is provided quasi raw - possibly aggregated and filtered - via a standard interface. However, it does not create HTML code, but simply gives a standardized technical response to the Presentation Layer, which is separated from the CMS. Thus, the headless CMS itself does not take care of the layout and design of a web page.

Another example is the use of mobile applications:

A headless CMS allows developers to pull content from a CMS and integrate it into any application. Unlike traditional CMSs, where the presentation and backend are tightly coupled, headless CMSs allow content to be created and managed independently of the presentation and front-end technologies. This increases the flexibility and scalability of the applications.

When Does It Make Sense to Switch to a Headless CMS?

Deciding whether it makes sense to switch to a headless CMS depends on a number of factors. If you are tasked with managing a digital customer experience that runs across many channels and at a certain scale - lots of content or products - and complexity, then headless should definitely be on your agenda. Having a platform that can't do that slows down the work processes.

A concrete use case would be, for example, a product catalog that is already published on the website but is also to be made available in a mobile application such as an iPad app for sales staff. This app could contain additional information such as current prices and it is important that all channels are filled with the same data. Furthermore, there may be point-of-sale devices that need to be fueled with product information and the like. In this case, it makes sense to manage all channels uniformly and to have a standardized interface to the outside world. Partners who look after a special category of devices can also access the headless API without having direct access to the CMS. This also saves time and effort.

The Speed and Number of Changes Has Increased

In the past, you ran a launch-and-leave model, putting down a big new web presence and adjusting it in small pieces where necessary. But today, you react quickly to the success or failure of certain parts of a digital customer experience and execute changes at a moment's notice. The number of changes you used to make in half a year, you now make in less than a month. In this sense, a headless CMS makes sense because you have a complete separation between data collection and data use. Standard interfaces also allow you to serve multiple channels faster than before.

Headless CMS From the Developer’s Point of View

Developers have a different perspective on the issue and prefer a headless CMS for several reasons. If they have to work with 10 different systems, each with its own presentation layer, they have to adapt their tools and methods to each system. From the developers' point of view, this leads to complexity, uncertainty and risk. With a headless CMS, more standardization can be achieved, making the developers' work easier.

In Which Cases Is a Headless CMS Less Suitable?

Many headless content management systems offer fewer visual editing options compared to traditional CMSs. This means that projects that are very marketing and design oriented and require a high level of visual customization to be performed on individual cases are not ideal for a headless CMS approach. For example, if a campaign is to be created and the text needs to be wrapped in certain places, visual editing is required. In such cases, it makes little sense to go completely headless. A good indicator of whether or how much a CMS should adopt the headless approach is the amount of structured content and the complexity of the data model. If the data model is very granular and small-scale, even a headless CMS won't be able to solve much because it has to handle many individual cases. The cleaner the data model is, the more sense it makes to use a headless CMS.

Conclusion

A headless CMS enables structured data management by providing content through an interface without the usual representation as HTML output. This allows for simplified and standardized delivery of information across multiple channels, resulting in higher speed and lower overhead compared to traditional CMSs.

So, if you have a business that needs a flexible and scalable solution for content creation and management, consider implementing a headless CMS. However, don't forget that you may need technical support to get the most out of your system. Bright IT has this expertise and is happy to support you.