What even is a headless CMS anyway?

Traditionally Content Management Systems (CMSs) have had two major roles: managing content and delivering content. Managing content is the obvious bit – it’s in the name. That’s the functionality that allows you to add and edit content, probably including written text, images, videos, and other content types. Almost every CMS will have some closely related functionality to support the content management process - such as approval workflows, taxonomy management, and version management – but adding, editing (and occasionally deleting) content is the crux of it.

Delivering content is the function of taking all that managed content and packaging it up for your audience to read. This involves applying styling, design, building navigation, adding related bits of content, assembling metadata, pulling in media players, and everything else that turns your bit of content into the polished publication that you’re creating.

In the traditional CMS world, those are just two sides of the same coin; the CMS takes care of both sides of it. But in the headless CMS world, the CMS only looks after managing content; it leaves delivering the content to something else. Simple, really.

But why wouldn’t I want my CMS to manage both content management and content delivery? Why would I want less functionality?

There’s a few reasons, actually. And there’s a few reasons why you might not. We’ll get to that, but going into a bit of history might help. Not a lot of history, don’t worry.

The concept of a CMS grew up with the web. Early on, most websites were built page by page, by hand. Webmasters ran websites as their own personal kingdoms; pages were laid out using nested data tables like a labyrinth of Russian dolls, content marketing meant applying to be added to listings directories and reading content online meant dialling up from PC tethered to the wall by a telephone cord. Popular websites got dozens of users, sometimes even on the same day. It was a wild time. It was a simple time.

It didn’t scale. As the Web took off, content publication needed to get quicker, to reach more people, to include more content, to support more people working on it. Enter the CMS.

Most traditional CMSs popular today first launched sometime around 1995-2005. They were founded on the concept that content was going to be published to a specific webpage on a particular website, and the main problem they were trying to solve was how you made it easy for a content writer to add just the specific content that was unique to a page, and automatically add on all the code and design that turned that content into a webpage.

So they combined content management and content delivery, using webpages as the structure that orchestrated the content into a publication. It was the obvious thing them to do. And it’s continued to be what they’ve done (with vastly increased sophistication and power) for the last couple of decades. 

So what do headless CMSs do differently?

Simply put, they leave out the content delivery. To use a headless CMS, you need a separate content delivery application. That might be a website front-end, but it could be a mobile or desktop application, a point-of-sale device, a knowledge hub, a digital store, a smart device, a digital print facility, or crucially, a combination of any of these and many other applications.

The core premise and promise of the headless CMS is that you need to create content for many different channels, all presenting the content differently, but you should only need to manage that content in one location. Each location can then display that content according to presentation that’s right for its own application. It’s a concept sometimes called COPE – Create Once Publish Everywhere.

Is it faster for websites? I’ve heard it’s faster.

If you engineer it correctly, it can be. Headless CMSs enable approaches such as Static Site Generation of Single Page Applications (SSG and SPAs), which is an acronym-heavy way of saying that the website can pre-generate its pages, and then once the user has downloaded their first page they only need to download the content for subsequent pages that they visit, rather than the whole code for the page. A traditional CMS will combine the content and layout dynamically on the fly when requested, which takes time (although the impact is managed through techniques such as page caching).

Not only is that a quicker experience for the user, but it doesn’t need as much computing power to run, which means that your infrastructure should be cheaper and easier to set up and manage (particularly using a Software as a Service as your approach, which most headless CMSs are geared towards). So it can help you to get your website up and running more quickly too, even for quite complex applications.

How future-proof is it?

Let’s just start off by saying that nothing is future proof – instead, let’s talk about future facilitation. You’re always going to have to update your services to stay ahead of your competitors, and to keep up with technical change. But another key promise of headless architectures is what’s become known as composability, which means designing your technical architecture from multiple focused components each of which can be swapped out without significantly affecting the others. This is sometimes known as “decomposing the monolith”, but there’s a value judgement embedded in that phrase so we try to avoid it.

So, by splitting out our content management (CMS) and content delivery (website front-end) applications, we can in theory upgrade or change each separately without the massive upheaval of a total replatform. If we want to change our user experience design, we can do that without touching our CMS. If we want to change our CMS, we just point our content endpoints to the new CMS.

In practice, it’s rarely that simple. User experience redesigns normal require significant content redesign and restructuring that will need significant changes in your CMS. And your website is going to be powered by more platforms than just your CMS, and if you implement a new CMS it’s likely that some of your other platforms will also need swapping out or will need integration work.

Wait, what? Other platforms? Currently I just use one CMS and it does everything I need.

Yes, other platforms. As well as bundling content management and content delivery together, modern traditional CMSs (and isn’t “modern traditional” a fun concept) have collected a bunch of other capabilities which aren’t strictly speaking content management, such as asset management, site search, and form processing. Digital eXperience Platforms (DXPs) in the enterprise segment go further and will typically provide integrated capabilities such as personalisation, experimentation, and customer data management.

The likelihood is that even the simplest website will need some tools in addition to the core CMS and frontend application, and complex websites will need many. For digitally mature organisations this can be an opportunity to assemble a suite of experience tools, each the best (or most suitable in class), rather than settling for average tools that build up an integrated CMS or DXP (especially as some of them aren’t necessarily that well integrated).

It’s not always that simple though. Using more tools adds management complexity. Platforms don’t work universally with each other, and your choices are going to be limited by the platforms that do work well together. Your teams will spend more time moving their attention, processes, and data between platforms. You’ll spend time and effort orchestrating your systems and processes.

It’s a lot of effort, and it doesn’t normally meet the easy component switching standard that the concept of composability promises. But with careful platform selection and stack design, you can architect a bespoke solution that is uniquely suitable to your needs.

So the technical solutions approach is different. What about managing content though? Surely that’s the same?

Not really.

We mentioned before that traditional CMSs generally orchestrate content through web pages organised in a hierarchical tree. Sure, they split pages up into sub-page elements, some elements are shared across multiple pages and edited apart from the main page, it’s a dynamic rather than a static concept. But even in transactional websites, user journeys flow across pages managed within a tree structure.

If you approach a headless CMS thinking about pages as the atom of content, you’ll end up fighting the system. The sub-page element is the hero; where pages exist, it’s as a modular assembly of elements. While content might be organised into projects, or collections, or other groups, there typically won’t be a tree structure. Instead, the content model is key and the taxonomy is the primary way to manage relationships between content.

If you think about those multi-channel, endpoint agnostic use cases for headless CMSs it all makes sense. Content may never appear in a page structure, and it’s up to the different front-end applications to display content in the way that best uses their presentation format. It’s a very powerful way to structure and manage content, but it’s going to seem very alien if you think about content primarily through the lens of web pages.

There are some other implications of this that your development team will need to consider – for example, in web projects making sure that metadata is modelled and pulled into pages as part of a static render to ensure that search engine crawling is properly supported and that your SEO strategy works.

Okay, but how does that work with managing the layout of my pages?

So this is another difference to get used to. One of the core concepts in headless CMS is to separate content from presentation so that the different endpoints can determine the correct display. This is dependent on the content model being well-structured so that the presentation application can chop up the content in the right way.

Early headless CMSs were incredibly strict about this; never mind WYSIWYG editors, even basic rich text editors were frowned upon. However, this approach proved too inflexible for most content editors, and almost every headless CMS will allow WYSIWYG editing of long-form content (whilst still promoting use of structured content with limited editor formatting for most cases).

But that’s formatting within content elements. Whilst it’s pretty standard in traditional CMSs these days, page level layout controls for editors are much rarer in the headless CMS world, and you’ll need to specifically look for that as a capability if it’s a requirement for you. Don’t automatically assume that it should be – for a lot of projects, that level of editor flexibility isn’t required as those decisions should be designed and embodied in the content model and presentation code.

It sounds like headless CMSs are becoming more like traditional CMSs, and aren’t all the traditional CMSs adding headless now too? They’re all just going to end up hybrid eventually anyway, aren’t they?

There’s some convergence in capabilities, for sure. Hybrid isn’t really the right word though, as it implies a defined consensus on a third way which everyone will move towards which isn’t really the case. Instead, the capabilities that different CMSs build and experience delivery approaches that they enable are getting more diverse, and the lines that divided different segments are becoming more blurred.

That’s a good thing. Your digital capabilities are not just your technology platforms, but also business processes, skills, data and understanding, and the orchestration of all these different elements into cohesive, compelling user (and colleague) experiences. In today’s technology marketplace, you have a lot of options to combine integrated and integratable platforms (whether based around a headless or traditional CMS) to curate a set of capabilities that work for your user needs and your business needs regardless of your organisation’s current level of digital maturity.

Also, and we’re just saying, “eventually” won’t help you pick the CMS that’s right for you today.

I was hoping for a simple answer to the question “headless or not”. Which should I choose?

We weren’t planning to sway you in one direction or another. We don’t know enough about you (not even if you consented to the tracking cookies). There isn’t a single right answer, and anyone who tells you otherwise is trying to sell you something. Probably a CMS.

That’s not to say we wouldn’t like to sell you a CMS. We would! We would just like to get to know your needs and existing capabilities so we can recommend the right approach for you.

Our CMS solutions place experience-first, rather than platform first. We use our bespoke Experience Stack framework to understand the core digital capabilities you have, those you need to enhance, and those you need to introduce, to meet the needs of your users. These capabilities include skills, processes, messages and understanding as well as technical delivery platforms and endpoints.

By developing this understanding, we can design your technical stack as a component of a coherent, comprehensive digital delivery function that is attuned to your people, processes, and users. This could use a traditional CMS architecture, a headless CMS pushing content to multiple endpoints, or increasingly a mesh architecture combining multiple systems (CMS, ecommerce management, personalisation, and so on) and endpoints.

That sounds like hard work. Can’t you just tell me what CMS to buy?

One of our CMS or DXP partners would be a great choice for many organisations (and we’ll be honest in telling you if they’re not). We’ve worked with several headless and traditional CMS/DXP platforms, and our preferred partners are Optimizely, Kontent.ai, Umbraco and Strapi, each of whom we’ve carefully selected for the different kinds of solution approach that they enable:

Enterprise systems:

• Optimizely - longstanding Gartner leader in DXPs, providing both a broad suite of integrated capabilities but also external integration interfaces and a solid set of technical partnerships. Historically it was developed as a traditional CMS and this is still its key strength, but it has recently massively stepped up its headless capabilities by the addition of GraphQL interfaces. Great for complex digital architectures with a need for strong orchestration with multiple endpoint types and experience platforms as well as dedicated digital delivery.
• Kontent.ai - built from the ground up as a headless CMS, and recently joined the MACH Alliance (an industry body advocating composable architectures and practices). Kontent.ai has long been our preferred dedicated headless solution for digital marketing due to its support for layout management and flexible editing, allowing simultaneously for application of best practices in content modelling without impeding marketers and content editors in creating the right user experiences for primary channels. Content operations are a key focus and the core CMS includes content calendar management as well as workflow. A superb choice for mesh architectures as the CMS for an organisation dedicated to a composable approach. 

Open source systems:

• Umbraco - a great traditional CMS with good facilities for integrating 3^rd party applications to add to its core capabilities. Umbraco had taken the approach of splitting its headless offering from its main CMS (and making it SaaS only), but with its latest version has reintegrated the headless interface into its main platform. A great choice for organisations needing to push content beyond its core website and add functionality over time.
• Strapi – a good dedicated headless CMS that provides both SaaS and on premise options. Good support for most popular SPA/SSG toolsets, and a particularly good choice for pushing content to targeted delivery applications and endpoints that might otherwise be left to developers to update with changes.

There are lots of other choices – this isn’t a full survey of the marketplace, just our favourite options.

So what should I do next?

Platform decisions should always start with an examination of the capabilities you need for the digital experiences you’re going to deliver – why not take a look at our replatforming guide to get you started.

As you’re thinking about headless approaches, here are some of the key factors you should look for in your new CMS, in addition to the standard criteria you’d think about on any CMS platform selection (price, performance, security, and so on):

• A good programmatic interface – REST APIs are relatively limited in power, so look for a GraphQL interface for content delivery
• A range of supporting applications and technical partners (either for integrations with platforms you already use, or with good applications you can bring in) for capabilities such as DevOps support, content search and form processing
• High quality developer documentation, tutorials and support – a good headless CMS won’t need you to commit a lot of time to training, but quick start and quick reference materials are crucial
• Single Sign On support for your organisation’s security management (if needed)
• A content operations model that will support your content team’s processes and tools
• A good user interface for your content editors
• A good fit for your core content channels, allowing you to focus attention and adapt content for your most important user experiences

For friendly advice on these considerations and approaches that might work for you, why not get in touch?