The ultimate guide to headless CMS

I’ve realised that the term headless has a tendency to be misused or applied. So I thought I’d take a moment to clear up what headless means, why it might be useful to you, when you should definitely be considering a “headless” solution and when you might want to avoid one.

What does headless mean?

When someone uses the term headless CMS, they are usually referring to a content management system that delivers content over a public API in a format that is agnostic to what will parse and display it:

Alternative CMSs will return their content as formatted markup, this is usually referred to as a traditional, coupled or a non-headless CMS.

So what makes these two so special? Well, the second example or the non-headless solution gives us something that includes our front end code. It’s coupled with our styles and formatting.

If we came up with a new website or wrote a mobile application that used a different design, we would need to either create a new content management system to supply the content for our new target application OR we would need to spend time changing the way the content is supplied from the content management system itself to make it reusable.

From my own experience, people often take a cut of the content and copy it to a new CMS.

A headless solution, however, is agnostic to our front end, which means that although we need to make sure that the front end is able to parse and style everything as we like (on each unique system) we don’t have to make any modifications to a content management system to supply the content at all.

In fact, the front of a system can use as much/little of the content as it desires without putting any dependencies or demands on the CMS itself.

That’s all there is to it.

When a CMS provider says they have a headless offering, they are saying that the content managed in their system can be made available through a public API.

What are the drawbacks of using a headless solution?

The first and perhaps most important drawback is that your developers will need to address ALL formatting in the front end.

If a content editor, for example, decided to put some text inside italics, the client rendering the content would need to be considerate of this kind of formatting and have implemented a solution for it.

Though this is a drawback, it can also be beneficial on mobile devices, where if unknown formatting is encountered, it has a tendency to crash. If a developer opts not to support a particular kind of formatting, the system can fall over gracefully instead, most often just rendering the copy that was supplied with no whistles and bells.

Another thing to keep in mind is that you will likely lose the ability to preview unpublished changes. Since your CMS is no longer aware of the formating it will be given, it won’t know how to offer you a preview state. Some solutions are out there that find a way around this, but they require a decent amount of configuration to get going.

There is also no standard format used for content supplied headlessly. One platform is unlikely to offer their content in the same way as another.

What are the advantages of headless?

Headless CMSs offer a ton of ways that content can be used that is different from a traditional solution.

When using a headless solution, your content becomes portable. If you decide to set up a new website or app, or you’d like to make some copy available for members of the public to use, you won’t need to make any changes to the content. You will hopefully be able to go longer than you ever have before without hearing the term “content migration”.

Your content can live outside the lifecycle of any of your digital products. You’ll be able to use/re-use this whenever you want.

Making it available like this can also give your developers more options when they are building.

Solutions like Gatsby and Next.js offer an easy workflow to collect and render content from your CMS during their build step. Meaning when your content is live, your users won’t be waiting for requests to go through your CMS, instead, they will be ready to serve quickly as static content.

Is it one or the other?

Before deciding to switch to a provider of a headless solution, make sure that you check with your current content provider to see if they can serve your content in a headless manner. Many traditional CMS solutions have upgraded to offer a headless feature. These might just require some configuration and could save you from migrating all of your content.

In summary

While a headless CMS can be very powerful in many situations, it is not better in all cases.

Looking towards the future, the way that content is transmitted and consumed is changing rapidly. The Headless market was worth $328.5 million in 2020 and is projected to reach $1.6 billion by 2026.

If you’re setting up something for the first time, there are fewer and fewer good reasons to use a non-headless solution, so think carefully before going down an alternate road if you are creating something new.