The Ultimate Guide to Headless CMS

Before we delve into the nitty-gritty details of the headless world, it would be wise to know whether we are speaking of the same thing. Let us start with a tentative definition, to ensure common ground:

A headless CMS separates content from presentation, letting the content be reused in any channel.

Now let us expand this definition:

A headless CMS separates the content layer from the presentation layer, allowing editors to create content to be sent to multiple channels via APIs, and allowing developers to build front-ends and clients using their preferred framework, instead of learning CMS specific frameworks.

What do we mean when we talk about layers? Imagine that you are editing a web page in a traditional CMS. You change the text, images, layouts, and more advanced components at will—the content itself and how it appears are thus closely tied together in one layer.

Even though modern websites built with a traditional CMS have responsive design and can change its appearance—or presentation—in accordance with different screen sizes, they still have one layer. Try to show a given page on your smartwatch or automatically reuse a textbox from inside a layout on another website. No dice.

This is where the separation of content and presentation comes into fruition. Keeping content in its separate layer and presentation in its own respective layer allows for the following:

• Content can be structured, categorized in types, and treated logically and predictably
• The structured content can be reused in different channels through an API
• Front-end developers can use the tools and frameworks of their liking to present the content on different clients, or channels
• Content thus has one source, where you can create, edit and maintain it, while the presentation has a potentially limitless number of channels: ranging from wearables and IoT to web and digital signage

Another elaboration might help clarify the concept even further: When the presentation layer, or head, is cut from the content layer, or body, you get a headless body ready to be distributed to several different “heads”—i.e. channels like websites, mobile apps, smart watches, TV screens, digital signage systems, voice assistants, or your coffee machine. A “headless” CMS is in reality a “headful” CMS, like the mythical creature hydra.

Yet another explanation of headless amounts to this short one: A headless CMS is essentially a database with an API (an API is a toolbox for making different platforms speak to each other).

Traditional CMS

What is the essential difference between a traditional CMS and a headless CMS? To put it bluntly: a traditional CMS keeps a close link between content and presentation, while headless cuts this tie.

The editors have access to full preview, landing page editing, URL handling, detailed access control, and media repository, while the developers can code, test, and deploy both editorial and end user functionality bundled together. This is made possible by a tight coupling between the delivery layer and the CMS.

A disadvantage of tight coupling in traditional content management systems is a troublesome multichannel presence. A standard desktop web browser, a mobile app, a wearable, digital signage, and an Internet of Things (IoT) device cannot equally read and present the content when the presentation layer is made exclusively for the web. That's where headless CMS enters the scene.

Headless CMS

The rise of mobile apps, social media, smart watches, digital signage, self-service machines, robots, and countless IoT devices is changing the way we consume digital content. All these platforms have unique properties and different methods of presenting and handling content. The problem of multichannel delivery, as well as the rise of rich front-end frameworks that delight the developer, are what a headless CMS addresses.

With a headless CMS the structured content stays the same, while each client—an app, a device, or a browser—is responsible for how the content is presented. Developers usually do not code in the headless CMS itself, but use the API and code in another framework of their or the organization's choice.

The Ping Pong Development of CMS

Content management system history being torn between traditional and headless manifestations can be compared to a table tennis match, where the ball is hit from one playing field and over to the other. Where one field pleases one set of employees in your organization, it displeases another set of colleagues. And vice versa.

The pattern is as follows:

• Traditional CMS: The editor is happy, but the developer is unhappy
• Headless CMS: The developer is happy, but the editor is unhappy

In a traditional CMS, including marketing suites and digital experience platforms, the editor can happily work in a user-friendly editorial environment, with visual page editing, tree structures, and contextual preview. The developer, however, is forced to work within a set system, where the CMS and the front-end are tightly linked.

With the rise of the first-gen headless CMS, the tables have turned. Here the front-end is separated from the CMS, allowing the developer to work with his preferred tools and frameworks. The editor, however, must now toil with form-based content, with limited possibilities for visual page editing, previews, and URL management.

Not All Headless CMSs Are Alike!

Headless CMS is not a strictly homogenous category. Some are “first-gen” or “cloud native,” meaning they are only available as cloud services and not software. The “Headless as a Service” approach simplifies scaling, monitoring, backups, and more—but sacrifices flexibility and control.

Other headless content management systems can be dubbed as “next-gen” or “hybrid,” but what are these?

Next Generation Headless CMS—Composable CMS

As mentioned, a “pure” headless CMS is more or less a database with an API and an authoring interface. With the API you can deliver your content or snippets to different clients—like digital signage, wristbands, smart watches, AR glasses, or as a part of third-party websites. A first generation headless CMS will most likely offer you minimal help to build complete websites, as the tie between content and presentation is cut completely.

However, most organizations primarily need websites, but first-gen headless is not focused on content driven websites. This means that your organization may need multiple systems running to handle things like structured content, page composition, URLs, and everything else that is required.

To combat the multi-system approach, the next-gen headless CMS enters the fray. A next-gen headless CMS can structure content and compose websites—in one system.

All the lightweight headless features are there, but with the added (and optional!) functionality of visual page editing, previewing, hierarchical tree structuring, URL and SEO management, page templates, detailed permissions, back-end integrations, and API customization.

Such a CMS is also called a composable CMS, as it allows you to orchestrate or direct your APIs and digital experiences from the CMS itself. Here the developers are happy with the separated front-end, and the editors are happy with a user-friendly and visually oriented editorial environment, which can also handle integrations and APIs.

 

Side-by-Side Comparison

One side of the headless coin is content. Content is a fundamental building block of headless CMS, without which it would be nothing. Aside from being described as a “database + API,” what is special about the content with which headless systems deal with?

First of all, a headless CMS manages structured content. This is information organized in a predictable way and most often classified with metadata.

Content Types

Being “structured” means that each content item of the same type has the same structure (duh!)—they all have the same fields and the same logic. Thus, all content items of the same type can be treated in a uniform and predictable way in different scenarios.

Examples of content types can be article, page, person, case study, recipe, car, book, course, video, office, product, event, and audio.

Structured Example

Let us illustrate the principle of structured content with an easy example: a blog post. This content type commonly includes fields for title, image, intro text, author, date, body text, category, and tags.

As each content item includes the same fields, the CMS can now treat them as one. Let us say you want to show a list of your recent blog posts. The CMS can then extract the data from the fields title, image, and intro text, as well as utilize the date field for chronological listing.

In this simple example, the editors have created blog content once, which are then reused in a blog list elsewhere on the website. This is the basic principle behind the scaling, reuse, and repeatability of content in a headless CMS.

A true headless CMS not only supports the presence of content types—it is a requirement for its existence.

Image and Media Handling

As mentioned above, images and other media files are also to be regarded as content types in a headless CMS with true structured content capabilities. Why? Because the principle of reuse applies just as well to images, videos, and audio files as any other content type.

These files can have several fields for metadata, which can be used for extracting e.g. geodata for an app showcasing media for various locations in the world.

Whereas metadata and use cases are one thing, another important matter in regard to image and media handling are the built-in tools in a given headless CMS. Like in many other instances, no headless CMS is alike in this matter.

Editing images with actions like cropping and setting focal points is a feature content editors and marketers covet, as it makes it easier for them to deliver exactly what they want to express without involving third-party tools.

Developers have APIs for images that enables them to create URLs to different image sizes, apply filters, etc. 

Make sure to investigate whether such editing features are present in any headless CMS you are considering.

Block Editor

While it is fairly easy to understand the role of fields and content types when it comes to structured content, things get a little more complicated with block editors. Many organizations seek the ability to create complex content that is still highly structured, and this is where the block editor comes into play.

A headless CMS that supports block editors makes it possible to add or remove fields from within a so-called “set” in a given content type. This can for instance be an article that allows the editors to insert blocks for rich text, image, video embedding, contact point, table, or any other requirement one must have.

The idea is to recreate the possibility of having rich content and page editor-esque controls, while at the same time making the content highly structured for reusable purposes—which corresponds well with the world of headless.

Now that we have covered the first part of the “headless equation”—[database + API]—it is time to turn our focus to the second part: API. An application programming interface is a computing interface that lets different systems communicate with each other.

In layman’s terms, an API is the chain between your content—the database—and any device or platform displaying it—the client. Information about the API tends to be what developers covet the most in any headless CMS, and needless to say: the API has to be very good and flexible to impress.

Let us take a look at some of the popular API technologies.

GraphQL

GraphQL is an API query language developed by Facebook. Being strongly typed and self-documented, it enables client developers to request exactly the information required in as few requests as possible—a perfect fit for headless CMS.

In other words, a great headless API based on GraphQL lets you instantly access your data from any device or client. It should give you exactly what you need and nothing more with a single query. Such an API can even be customized and extended to meet your specific requirements if your headless CMS support this.

REST

REST has been employed throughout the software industry and is a widely accepted set of guidelines for creating stateless, reliable web APIs. A web API that obeys the REST constraints is informally described as RESTful. RESTful web APIs are typically loosely based on HTTP methods to access resources via URL-encoded parameters and the use of JSON or XML to transmit data.

Do any of these keywords—such as scalability, independent deployment, web APIs, JSON, and XML—sound familiar? That is because RESTful APIs are another helpful technology empowering great headless content management systems.

The drawback with REST compared to GraphQL is that the front-end and back-end developers need to cooperate to implement the exact API needed by the front-end. The GraphQL approach just exposes everything, letting the front-end developer fetch whatever is needed.

Choosing the right headless CMS for you, your team, and your organization can be a daunting task. But it does not need to be impossible. Here are some key factors you should consider in your procurement process.

Infrastructure and Technology

A future-proof headless CMS uses modern technology and is open to integrate with best-of-breed tools—which means providing flexible APIs, being agnostic to front-end frameworks, utilizing cloud services for smart scaling, and generally being compatible with tools for authoring, marketing, and analytics.

This modular infrastructure ensures that the headless solution not only solves current-day challenges, but that it also is flexible and agile enough to adapt to future issues.

Carefully consider the needs of your organization. Most may be happy with a solution delivered as a service—meaning a cloud solution—but your organization might have requirements for hosting in your own environments. If this latter alternative applies, be sure to research headless vendors thoroughly, as not all of them can offer software to be self-hosted.

The must for any headless CMS is a comprehensive and flexible API to gather, create, and maintain content. If you must customize or build APIs tailored to the requirements of your organization, ensure that the CMS supports it.

Developer Ecosystem

Developers are the primary target group for a headless CMS. They want to know how the CMS fits into the organization’s existing digital portfolio and frameworks—as well as all the fine details of the solution itself.

Developers also like to engage in communities, where they can receive and deliver aid, as well as showcase their solutions built with the headless CMS. An active community—together with a professional vendor-based support system—will make your developers happier.

Additionally, you have to educate the staff that are going to use and run the CMS for years to come. Letting developers and editors go through training on the headless solution will save your organization time and money in the long run.

Finally, the headless CMS of your choice should have an ecosystem with ready-made integrations and extensions. This might include libraries for developers, integrations with other systems, and extensions to the CMS.

Easy Content Production

It is tempting to listen to the standing ovations from developers when it comes to the excellence of headless CMS, but don’t forget the other group that is supposed to work within the solution on a day to day basis—the content editors.

Ask yourself how long it is going to take for the content team to get to understand the headless CMS in order to maximize productivity. The authoring interface of a headless CMS should first and foremost make your content editors productive and effective.

Many first generation, cloud-native, and “pure” headless CMS solutions offer the dreaded database and form-based editing—and not much else out of the box. Indeed, the content itself should be at the center, but editors like to see and feel how their content will be presented.

In other words, you should make sure the selected solution can compose content within an in-context preview (together with both visuals and services), while at the same time being responsive, offering a logical overview like a tree structure, and supporting workflow and permissions. Also, reusing content—the staple of headless—saves both time and resources.

Ensuring that the editors understand this crucial principle will benefit them, the developers, and finally the organization tremendously.

Security and Reliance

A headless CMS provides improved security by reducing the number of exposed components available to end-users. Entry points for malignant visitors are limited when just a few parts of the solution are visible. This intrinsic security is boosted even further if the vendor uses a static site on a CDN (content delivery network).

The only accessible element for end-users is several layers removed from critical components. The process of creating content to deploying it involves a lot of moving parts, and in traditional content management systems this often created a vulnerable back-end.

With a headless CMS, the creation and delivery of content are always separate processes, thus making it exceedingly difficult for end-users to access the back-end of your solution. Indeed, the flexibility of a headless CMS allows for even tighter security through a cloud-based update regime. With a modular architecture, you can schedule updates and maintenance with little to no downtime.

Keeping your content and customer data safe should of course be one of your highest priorities. Consider the requirements of your organization to where data should be stored, who has access, and the security certifications of the vendor. You should also make sure that the vendor regularly tests for security issues, and deploys updates and security fixes in a fast manner.

The reliability of a headless solution rests on multiple factors, including what happens to your digital experiences during and after maintenance. Also, as part of a reliability assessment you should verify the vendor track record through documentation, community feedback, and analyst reports.

As a last note in this section, make sure that your chosen headless CMS supports your development process and provides several environments—for e.g. testing, staging and production.

As with most things in life, headless CMS comes with both pros and cons. We have discussed a lot of the benefits of a headless CMS, but what lies on the flipside? Are there any real challenges?

A pure, first-gen headless CMS usually cannot:

• Use a visual landing page editor
• Organize the website structure
• Manage URLs
• Preview the content
• Manage user rights and permissions
• Manage SEO
• Handle complex image editing

Also, for each new client, the developer must handle several issues, including:

• URL handling (again)
• Formatting issues and templating
• Caching and lazy loading
• Permissions
• Error handling
• Synchronization between CMS and clients
• “Forced” updates from the cloud vendor

Depending on the vendor and the choices you make in the digital project, more custom development might also be required if you use the headless approach for traditional websites. And because many headless solutions are cloud-based, hosting software yourself may not be an option.

Let us go more in-depth on some of the challenges. Note: These vary from vendor to vendor, and whether or not they offer the possibility of a next-gen CMS, i.e. combining the lightweight benefits of headless with an optional, but powerful addition of editorial tools.

Preview

As editors work in a database and not on an actual website, they don’t really know where the content will go or what it will look like before publishing.

However, developers can in fact create a standard preview for a quick reference, easing the business users’ state of mind. Just remember that the preview might not look exactly like its final presentation on every channel.

Tree structure

Many headless vendors do not offer a hierarchical tree structure overview of the content. This type of navigation is familiar from operating systems, and allows the user to browse through content by opening and collapsing child content items under a parent content item.

As mentioned before, a headless CMS is more or less a database. Organizing content or achieving a tidy overview may become difficult in larger projects based on such a standard database viewing.

Developer-driven

One grand challenge with headless CMS is this following fact: The content editors simply didn’t ask for it. What content editor dreams of creating and maintaining content in a form-based database only?

Headless CMS is primarily developer driven. The decoupling between the content layer and the presentation layer makes for more fun and agility for developers, but poses a real challenge for content editors. This is due to especially first-gen headless limits on what such users can do and customize within the platform. 

Hosting and security

Most pure headless vendors offer their solutions as a SaaS, meaning you log into a cloud service to edit content. With this comes the advantages of cloud hosting in the guise of blazing speeds and cloud scalability for traffic peaks.

But not all headless vendors are alike. Hybrid vendors, for instance, offer a variety of hosting solutions. Some are SaaS, while others may be PaaS or even on premise. The general trend is however that more and more vendors are moving to the cloud for increased user experience and speed. Because most headless solutions are cloud based, hosting software yourself may be off limits.

If your project involves rich web content, URL handling, extensive editorial requirements, special hosting needs, and reuse across different channels, a next generation headless CMS might be the solution you're looking for.

More code to maintain

The developer-first approach of headless CMS may actually involve more hard-coding from the developers, and content editors are more dependent than ever on what the developers have taken into account. There are possibilities for hard-coded custom switches and complex configuration, but this makes the platform more advanced than necessary.

In some headless cases the developer has to do all the heavy lifting—including building and maintaining a larger code base. As a pure headless CMS is only an API, creating a full website can pose a real challenge.

Furthermore, much practicality must be managed—like URL handling, deep linking, and error handling. Depending on your choices, a first-gen headless CMS might actually lead to higher complexity, by moving from one system to multiple to handle various tasks. Add to this that all the different systems must be integrated, synchronized, and managed, and you have a head scratcher.

***

Many of these challenges with headless CMS can easily be overcome by researching and choosing the right solution for you. Some vendors have taken these factors into account, and offer a next-gen alternative—taking in the best of both worlds by unchaining the developer and enriching the editor.

Headless CMS makes sense in a world where you don’t necessarily know where your information will be available tomorrow. The combination of a database + an API for distributing to any channel is unbeatable.

As we have seen, headless CMS is not without its challenges. However, we believe these can be overcome with smart strategies like the involvement of next generation capabilities.

Content is essentially data. Having a method for treating data easily and predictably will not grow old or stale—it’s in the very foundation of communication. The question is to what degree headless CMS will come closer to what it initially distanced itself from: the traditional CMS.

We believe that flexibility will be the key ingredient for successful vendors in years to come. The flexibility to choose the components you need to please both developers and content editors at any time, in a constantly shifting environment.