Author: Rowin Peet
Content manager at Crossphase
Published on 2 September 2019

I’ve been working as content manager for a while now, and I gradually see my trade and the systems and tools that I use evolving along the way (and rightfully so!). As a content manager, my aim is to get all the content in the right place, at the right time and in the right way. There are several content management systems which a content manager can use to get this done.

The where, and the how

Each system has their own pros and cons, but before you start with the selection process of your CMS, the most important thing is to thoroughly define your use case. Once that is done, you can define the requirements of your new CMS. Nowadays, in terms of content, one of the more relevant questions companies have to ask themselves is: on which channels do I want my content to be served, and how?

The how, is exactly the reason why I jumped on the headless CMS train. To clarify, we have to define what a headless CMS exactly is. As Wikipedia puts it: “A headless content management system, or headless CMS, is a back-end only content management system (CMS) built from the ground up as a content repository that makes content accessible via a RESTful API for display on any device."

To put it a bit more plain: the ‘head’ has been seperated from the ‘body’. The front-end has been seperated from the back-end. The ‘content’ part has been seperated from the ‘appearance’ part.

And why exactly do I think this is awesome? I have several reasons:

It requires a new way of approaching content

You don’t think in simple pages and appearance, and what content a specific page needs. You think content first. The pages (and appearance) will come after that. You are forced to think about your strategy, and your brand or project as a whole.

Your content can be served anywhere. Just leave that up to the API’s.

Remember the times when we were so focused on just the website as a channel? And the desktop as a device? Oh, how times have changed. Get ready for your content to be displayed on apps, wearables, websites, mobile, heck, even chatbots should be able to receive your content and word it out.

The front-end developers can work their magic with the tools they prefer

In the more traditional, or coupled CMS, the front-end developer is limited to the tools that the CMS has to offer (the front-end and back-end are coupled, remember). With a headless CMS, the front-end developers are not committed to one specific tool. So if they want to use, let’s say, React, for instance, this is completely fine. Now, I’m not a front-end developer, but I do want the channels to look, and perform, as good as possible (don’t we all?).


What if you’re rebranding? Think about it. No changes required within the CMS. And what about new technologies? No need to migrate anymore. It’s not like you’re dependent on the exisiting tools your CMS has to offer. Your content is seperated anyways.

Not suitable for every use case

There are also reasons to prefer a coupled CMS over a headless CMS. If you just want to serve one channel, a coupled CMS is the more easy way to go.

Also, it’s not just the question if your use case fits the system: your team of content managers also has to be ready for it.

9 out of 10 content managers are used to a certain way of working: creating a site tree, and building pages along the way. These pages can be built with the help of a WYSIWYG editor (What You See Is What You Get). They can literally preview their work. With a headless CMS, you can still preview your work throughout an API, but you’re not working in a site tree. A headless CMS works with content models and taxonomies. And, to be honest, that requires a completely different way of working/thinking.

There’s so much more I can tell you about the new ways of working, websites, taxonomies and digital platforms, but let’s save that for later. What about JAMstack, for instance? And creating a blazing fast website with a headless CMS with just one simple tool? There’s more to come!

Meanwhile, you can read an article my colleague Tim wrote about the consequences of going headless (in Dutch), which is very relevant and interesting.

You can also find a Dutch version of this article on LinkedIn.


Icons made by Pixel Perfect and Smashicons from

Special thanks to my colleague Kasper Mol for creating the infographic

Discover what we can do for your organisation

We use cookies
We use cookies to offer you the best experience on our website. Learn more about which cookies we use and adjust them under settings.
Privacy overview
This website uses cookies so that we can offer you the best experience. Cookie information is stored in your browser. For example, we can see which parts of the site you find most interesting and useful and whether we reach people with our advertisements.
Essential Cookies
We place essential cookies and analytical cookies to ensure that basic functions of our website work properly, to be able to record your cookie settings and to be able to analyze anonymous data about the use of our website.
Enabled Disabled
Marketing cookies
This website uses the following cookies: LinkedIn Insights Tag, Facebook Pixel
Enabled Disabled