Headless CMS Fact / Fiction


Tim Griffiths | 17th January 2022 | 5 min read

Headless CMS vendors make a lot of claims about the benefits of building with a headless CMS over traditional monolithic architecture, but how many of them are actually true, and more importantly what is it about going headless that actually results in these improvements? In this article, I am going to unpack the biggest claims and elaborate on what is true, what is a myth, and what you need to do to ensure you realise the benefit by going headless.

If you’re not sure what the difference between a headless and traditional CMS is, let me sum that up quickly.

In a traditional CMS, the platform’s functionality includes an admin for managing content, a templating system to render the front end of the site (the head) and a variety of extra features that could include forms, A/B testing, caching, scheduling, and analytics.

A Headless CMS, however, is only concerned with the content management and publishes the content to an API. Whereas with a traditional CMS, visitors to the website would see a page generated by the CMS, as a headless CMS has no head, that responsibility is delegated to another platform. Most features outside of content management are kept lightweight, instead focusing on making integrations easier so that a complete solution can be built from best of breed 3rd parties that all specialise in their own area.

On with the claims…

A Headless CMS will give you better page speed

Fiction – This is the most common claim I see that is completely untrue. A Headless CMS by definition has no head and therefore can’t give you any sort of page speed. Where the claim comes from is Headless CMS’s can work with static site generation tools like NextJs, Nuxt, and Gatsby which as they can pre-render web pages at the time content is published can result in the fastest page speeds. However, you don’t necessarily need to swap CMS to take advantage of these platforms as most traditional platforms provide a content API to use them too.

A Headless CMS can work with any language

Fact – As a Headless CMS publishes content to an API there is no restriction on the language used to create the website, whereas in a traditional CMS the website would run as part of the CMS and therefore need to be written in the same language.

While this claim is true, not all Headless CMSs support all languages equally. Generally, most examples are provided for JavaScript solutions and where modules for head functionality are provided for things like API wrappers and rendering rich text fields the support for JavaScript is usually much higher.

A Headless CMS requires less maintenance

Mostly Fact – The separation of front end code and the CMS, means that the CMS admin can be upgraded, patched etc without affecting the actual website. As long as API schemas stay the same it also won’t break anything in the website once upgraded. However, the real benefit is when the Headless CMS is provided as software as a service (SAAS) requiring no install. With this setup the maintenance is done for you.

If you opt for a Headless CMS that you host yourself, then you will obviously need to install the patches yourself.

It’s easy to swap a Headless CMS for another

Possible – The two factors which affect moving CMS are how easy it is to export and import your content, and how the front end has been written. As Headless CMS’s have a focus on providing everything via an API, moving your content becomes much easier.

However once you’ve moved your content, the ability to swap one CMS for another will depend on how well the new CMS links up to the existing front end. If the front end was developed with its own component models and an abstraction layer to map API results from the CMS to the models, then the bulk of the work would be updating these mappings. However, just like with a monolithic solution the components could have been written to directly call API’s and as the responses from two CMS’s won’t be the same a major rewrite could be needed. It will all depend on how the front end has been architected.

Content modelling is better in a headless CMS

Possible – This really depends on what traditional CMS you compare to. Platforms such as Sitecore and Umbraco offer a modeling experience that is the same or potentially better in some scenarios. Other platforms that evolved from blogging platforms can have a much worse experience.

Integrations are better / easier

Fact (sort of) – At its core, a Headless CMS focuses on its APIs and as a result, they are better. They also offer tools like web hooks, and app frameworks to improve the usability across applications.

However, when designing a composable architecture you should look at what support one platform has for another. Not every E-Commerce platform has a plugin for every CMS platform, so you should check which combinations work well together. Maintenance of plugins is also crucial and what happens when one platform deprecates it’s plugin for another, such as having the open sourced it for someone else to take over.

Integrations in your front end are largely unaffected as this is outside of the CMS’s functionality.

Building a site with a Headless CMS is quicker

Fact – There’s multiple factors that come into this, but the biggest centre on not needing to install the CMS in a local dev environment which for some when there are multiple devs can become highly time-consuming installing DBs and keeping them in sync.


As you can see most claims are generally truthful or are at least based in an element of truth, but care needs to be taken to understand how to actually get the benefit.

The main takeaways are:

  1. Unless you have a good reason not to, choose a SAAS-based Headless CMS. Hosting yourself will remove most benefits.
  2. Remember a Headless CMS is one building block in the solution, it needs to be paired with other things.
  3. Check how well the CMS integrates with the rest of the stack. There’s a difference between working and working well.

Get our latest insights straight to your inbox

You may also like...