Ask Anne Boleyn, Marie Antoinette, or Oliver Cromwell about the advantages of going headless, and you’ll be met with stony silence.
But grill a development team, and you’ll probably hear all about the benefits of chopping the head off a traditional CMS. But it’s not always a bed of roses for them either. Headless CMS solves several complex problems when it comes to delivering content to different channels, but it’s not the right option for everybody. Let’s get you up to speed on everything you need to know about headless CMS.
In a headless approach to content management, the front-end of your digital experience and the back-end are decoupled. Or in other words, the head (your presentation layer) has been chopped off from the body (your content layer). Not a particularly cheerful picture, but a useful one in the context of an ever-more complicated content management environment.
This decoupling means that it’s easier for your developers to deliver your content to different channels. Think of it as a book. Imagine if the words in a novel were inseparable from the first hardcover prints. There’d be no way of printing as a paperback, creating a Kindle edition, or making one-off collector’s editions. With a headless CMS the text (the content) is completely separate from the physical book (the presentation), making it easier to expand across different channels, all while keeping control of the content and presentation.
To say it another way: A headless CMS is an online database, with a user-friendly user interface and an API to distribute content to whatever client (i.e. channel/platform) you wish.
The method behind a headless CMS is actually nothing new. Back in 1979 the Norwegian computer scientist Trygve Reenskaug introduced the idea of the “model–view–controller.” Here an application is divided into three interconnected parts: the controller, the model, and the view. The model represents the data, independent of the other parts. The view shows the model data and sends user actions—like button clicks—to the controller.
Similarly, a headless CMS acts like a specialised database, where the interface enables editors to manage content (the model). At the same time, developers can build clients with their preferred tools. The client then connects to the headless database, fetches the content and handles the presentation locally (the view and the controller).
This approach has been done since the early days of CMS, but the difference today are more use cases, and more commodities—with vendors specialising in delivering only headless solutions. Other differences between headless CMS then and now include:
In the mid 2000s the concept of “portals” was introduced by major players such as IBM, SUN Microsystems and Oracle. Portals were commonly used as clients for CMS and other systems, causing a great deal of complexity and frustration for both editors and developers.
The 2000s also saw a new type of CMS emerging—the Web Content Management (WCM) system. WCM’s offered a richer set of features to please editors: full preview, landing page editors, URL handling, and detailed access control.
In this approach, developers were provided with a simplified development process. Vendors made this possible through a tighter coupling between the delivery layer and the CMS—with developers being able to code, test, and deploy both editorial and end-user functionality in a bundled fashion. This is what we may label “traditional” CMS.
As the time has passed, the WCM vendors have extended their offerings with a larger feature set—sometimes being labelled as comprehensive marketing suites. Recently, the term digital experience platform (DXP) was coined to define this new class of systems—which in many ways is more representative than the term CMS. A DXP typically controls both the delivery and authoring of content.
When the first traditional CMS was created in the 2000s, users browsed the internet using desktop browsers. But as the popularity of the internet exploded, so did the content we were consuming. As technology moved away from page-centric browsing to mobile, the traditional CMS and DXP struggled to keep up.
The headless CMS was a response to this problem. Without a presentation layer, the developer could use API-calls to pull content from the CMS into any application. With the popularity of headless CMS continuing to rise, digital experience vendors are adding web-based content APIs to their platforms to meet the demand for a headless option, meaning the presentation layer of the CMS is optional.
Yet, while the headless CMS solved a lot of problems, it wasn’t the answer to all of them. Enter hybrid CMS. With the growing popularity of headless CMS, several WCM/DX vendors have added web-based content APIs to meet the competition from the pure headless vendors. And thereby the term “hybrid CMS” was born. Presumably giving you the best of both worlds.
Hybrid indicates that your CMS comes with a presentation layer, but using it is optional. Whereas headless requires marketers to work with front-end developers and new content delivery layers to simply author content, a hybrid CMS offers the same omnichannel flexibility with the user interface of a traditional CMS.
When it comes to CMS, there’s no one-size-fits-all solution. Headless CMS might be an appropriate solution for some use cases, but too complex for others. To help you figure it out, here’s the lowdown on each option:
A headless or hybrid CMS isn’t the right answer for everybody—if your organisation only requires a basic website, a traditional CMS might be all you need. With a traditional CMS the content and the presentation are closely interlinked. Users create and edit their content through tools like a WYSIWYG editor or an HTML editor, and save it to the database. The CMS then displays the content according to the front-end delivery layer built into the CMS.
Grappling with a native mobile app or single-page web apps? A headless CMS could be the answer.
A headless CMS gives you the tools to create and edit content, but “publishing” the content simply means making it available to clients via an API. It requires a front-end development team to manage the rest with the frameworks and tools they prefer for either web or native mobile app development.
Complex digital experiences with a mix of services and content? Get the best of both worlds with a hybrid CMS.
A hybrid, or decoupled, CMS is a platform that combines a traditional CMS with a headless one. This means you can “go headless” when you have to, all while letting your web editors run digital experiences with visual tools and editors as usual. All your content can be reused in any channel and you can create exclusively headless content to enhance your applications and services.
Headless CMS come in all shapes and sizes, but some of the most common—and desirable—features include:
A headless CMS should make it easy to allocate roles and permissions, and control how and what people can access on your site.
Control over taxonomy is important for a CMS. Look out for a taxonomy module that lets you classify site content and label different words or phrases.
A headless CMS with a good image handling tool makes it easy to insert, edit, and share images across every platform and device.
A headless CMS needs to interact with your front-end frameworks. With a rich API, you can easily fetch, update, and modify content. The API could be based on popular technology like GraphQL. GraphQL lets you ask for exactly what you need and nothing more, makes it easier to evolve APIs over time, and enables powerful developer tools.
Model your information architecture using content types. The content types consists of form elements like textline, dropdown, textarea, radiobutton, image, etc. Content type examples are article, product, and person.
Never lose a change thanks to revision history: content revision functionality lets you keep track of all drafts and publications of your content, displayed together with the change date and author.
Set up and define workflows and approvals for content management and publishing that reflect the way your team works.
One of the biggest advantages of a headless CMS is the fact that it can work with multiple frameworks, including React, Angular, and Ember. This means that the CMS can support whichever touchpoint you decide to launch next, all while attracting the most ambitious developers looking to experiment with the latest frameworks.
A headless CMS can deliver your content to any channel, whether that’s an iOS app, single-page web app, or digital signage.
Native apps are where the headless CMS was born. Whereas a traditional CMS is unfit to deliver raw content for your new app, the headless CMS lets you maintain control. It’s ideal for when your iOS or Android app has text or digital assets that you want to update frequently. In this case, the headless CMS allows for content management capabilities like image handling, workflow approvals, publishing dates, and taxonomy.
Imagine you’re building an online loan app. It is not content driven and requires so much custom code and back-end integrations that your developers would never dream of building it with a traditional CMS. But the app still needs some kind of content management system—just think about all those images, labels, and pieces of help texts and localised content. With a headless CMS, your team can create and maintain content in a controlled manner.
So your business has decided to venture into the world of wearables and IoT? It’s a future-proof idea, but one that a traditional CMS would never be able to cope with. With a headless CMS, however, developers are free to build creative interfaces that were once restricted by CMS coupling limitations.
A headless CMS requires your developers to do a lot of the work, making it more difficult for editors to get hands-on with the actual web experience. Functionality for managing landing pages are not a part of a typical headless CMS, but you can make a content type that lets you give input to the developer about how to structure your content.
A headless CMS might not be a magic bullet for all of your complex development woes. It’s important to remember that a headless CMS is “only” a database with structured content—things like help texts, FAQs, and articles. While it will help you manage and deliver content for new channels, it won’t necessarily help you organise and manage more complex websites.
It’s easy to see why hybrid CMS is stealing the headless headlines: after all, why choose between a traditional or a headless CMS when you can have both?
Hybrid gives web editors the freedom to work in a familiar environment, all while letting your developers build custom-built solutions.
The hybrid option is a no-brainer when you have a complex website mixed with services built using the latest front-end frameworks.
The simple formula for a hybrid CMS is this: Content and services delivered to any channel.
Chances are that you already have some form of CMS in place. You might know straight away that your current CMS is falling behind, but it’s probably not immediately obvious which direction it should go. So the first step is to figure out where you want to be and where your existing CMS is holding you back. Try answering these questions:
If you find that you’re left with a wide gap in what you can currently achieve and the direction your organisation wants to go, it might be time to embrace a new headless CMS solution.
Your tech requirements aren’t the only thing that will shape your decision. One of the most common reasons that CMS implementation fail is that they don’t fit into your team’s way of working.
As well as figuring out how a CMS will fit into the programming languages and frameworks your developers use, think about the skill sets and work habits in your organisation. Ask these questions:
Once you’ve chosen a top contender from your shortlist, it’s time to do a proof of concept. Remember to share your requirements and expectations with the vendor before starting your test drive, as they can use these to configure the system to meet your needs.
There should be a team of stakeholders involved, including key individuals from development, design and content production. This team can ensure the headless CMS runs smoothly for everyone—not just the developers. To really put the solution through its paces, test our real-life scenarios and develop an evaluation sheet to log the results.
Simply download the PDF. No registration required.