…and just call it a CMS? 

Sorry for this grumpy-old-man-rant, but isn’t it time to retire the term “headless” when we are talking about CMSs? It’s not needed, and it doesn’t really mean anything.

If you search for a definition of the term “headless CMS” you might find something like: a CMS where the content is decoupled from design and user experience.
I haven’t seen a CMS that forces a specific presentation in many years. You can build a solution where the CMS dictates the presentation. Like the solution for this blog, based on WordPress. But (thankfully) every WordPress site doesn’t look or behave like this blog. So, I think we can ignore that definition.

I think the most common definition is that the content is fetched using an API, and can be presented in any channel, using any technology. I’ve been building web/mobile apps that fetch content from a CMS via an API for almost 20 years. Back then it was often a Flash based web site that got it’s content from an API (there was even a plugin to Flash that made it possible to transfer the content in a highly compressed binary format :-)). I would be really surprised if there exists a CMS today where you can’t fetch content using an API (REST or GraphQL), either out of the box, or with an add-on, or with minimal coding effort. 

Having data in some type of storage and exposing that data via an API, that’s the easy part when it comes to a CMS! It’s a tiny fraction of the functionality that a CMS has, and it’s a tiny fraction of the code base for that CMS. I know how simple it is, because I’ve been involved in multiple projects where we’ve created such APIs for several CMSs (for example Sitecore, Umbraco and Episerver). Is there a single CMS where it is not possible to get the data as e.g. json? If you can render HTML, you can render Json, or XML, or whatever you prefer.

So, if “headless” means being able to fetch content via an API, all CMSs are headless. Meaning that “headless” is not needed.

I’ve also seen that some include the following when defining a “headless” CMS: the delivery application is separate from the CMS application.
Well, since all CMSs can deliver content using an API, you can have a delivery application (e.g. web site or mobile app) that is separate from the CMS application. I was recently involved in a project where we used Umbraco for managing the content for a website on a completely different platform, and at the same time managing the content for a chatbot built on Microsoft’s Bot framework.
Nobody calls Umbraco “headless”… 

I also saw a CMS vendor having a list of benefits of using a SaaS when defining why their headless CMS is so great. I agree that there are many benefits with using a SaaS, but “headless” is not a synonym to SaaS.  

Some bend over backwards and state that a truly headless CMS is built from the ground up with an API-first mindset.
Ok, so it’s the intent the creators had when envisioning the CMS that dictates if a CMS is headless or not? What does that mean for the editors using the CMS? What does it mean for the content designers, the web site or mobile app developers, or the end-users? Not much, if you ask me.

So, now that we (or at least I) have stated that all CMS:es have the possibility to act as “headless”, can’t we just skip the “headless” part and just call it a CMS? 

Saying “headless” is useless and mindless.
…well, I’m not really sure about that, but it sounded catchy. I’m not really sure why I feel so strongly about this. After all this is not very important. I hope you didn’t read all the way here, I’ve wasted so much of your time… sorry 😀