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.
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:
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.
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.
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.
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!
You can also find a Dutch version of this article on LinkedIn.
Special thanks to my colleague Kasper Mol for creating the infographic