Ebook
Everything you need to know about headless CMS
Table of Contents
Introduction
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.
What is 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.
A history of headlessness
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:
- The client was most commonly a website, retrieving and listing articles.
- Both the client and the CMS were located behind the same firewall.
- For some solutions, the “API” was simply the database. Solutions with an API were rarely exposed on the open web.
- Data was exchanged through XML or binary formats rather than JSON.
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.
Choosing the right CMS for your needs
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:
Traditional
Basic website? Keep it traditional
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.
Advantages of a traditional CMS
- Easy to use for web editors
- Keeps you in control of URLs
- Allows for instant previewing of content
- Lots of flexibility to build content, landing pages, etc.
Headless 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.
Advantages of a headless CMS
- Omnichannel readiness
- Low operating costs (depending on your choices)
- Reduced time to market (for content)
- Ease of use (fewer options for the content creator)
- Cloud scalability
- System security
Hybrid CMS
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.
Advantages of a hybrid CMS
- Control which URLs will be managed by editors, and which URLs will be predetermined by developers
- Preview headless content in standard previews
- Faster and easier search functionality (all content is in one system)
- Leverages all of the speed and scalability of the cloud for multi-channel scenarios
Typical features of a headless CMS
Headless CMS come in all shapes and sizes, but some of the most common—and desirable—features include:
User roles and permissions
A headless CMS should make it easy to allocate roles and permissions, and control how and what people can access on your site.
Taxonomy
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.
Image handling
A headless CMS with a good image handling tool makes it easy to insert, edit, and share images across every platform and device.
Rich API
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.
Content types
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.
Content revision
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.
Workflow
Set up and define workflows and approvals for content management and publishing that reflect the way your team works.
Front-end framework freedom
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.
Use cases for headless CMS
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
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.
Managing labels and text in custom web apps
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.
Wearables & IoT
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.
What are not the best use cases?
Landing page management
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.
More complex websites
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.
Why hybrid CMS is increasingly popular
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.
The advantages of a hybrid CMS
- Headless & traditional website in one solution
A headless CMS is basically a database with an API, which makes it tough to build complete websites. The result is two separate systems for maintaining a website and delivering content to different channels. A hybrid CMS streamlines this by delivering websites and APIs from one system.
- URL handling
A hybrid CMS gives you full control over your URLs, making your daily operations more flexible. This is also important when it comes to SEO.
- Landing page editing
Editing a landing page through a headless CMS requires a hard-coded form system. With hybrid, you enjoy visual landing page editing.
- Content preview
A hybrid CMS doesn’t completely cut the ties between content and presentation, meaning your editors get to preview content before publishing.
How to choose the right headless CMS
Start with a gap analysis
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:
- Do you want to extend your content to multiple channels?
- Does your CMS architecture support your long-term technology vision?
- Are you using the most up-to-date version of the CMS, or is it time to invest in a major upgrade?
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.
List your requirements and make a shortlist
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:
- Does the CMS fit the way the developers and editors work?
- Is there the development capacity to support a headless solution?
- Is it intuitive, or will it require investment in training?
- Will users easily be able to collaborate on content?
Proof of concept
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.
Want this eBook on the go?
Simply download the PDF. No registration required.