Headless content management feature overview
The Headless CMS offering is huge and to differentiate they all have their own strengths and weaknesses. This article aims to give you a common overview of the available Headless CMS features and hopefully helps if you are in the market for a Headless CMS.
What is a Headless CMS?
Unlike a traditional CMS, a Headless CMS is a content management system without a front-end. There is a back-end User Interface (UI) to manage the content, but the content is only exposed through an Application Programming Interface (API). Developers build a separate front-end and use this API to consume and present the data to the end-user.
Detaching the presentation from the CMS makes it easier to consume the content from multiple channels such as mobile apps and smartwatches. It also allows the developers to pick any front-end technology, greatly reducing the dependency on the CMS platform.
Unlike a traditional CMS, a Headless CMS is a content management system without a front-end.
This articles describes the available features, which are categorized in four groups: Content editing features, Content modeling features, Technical features and Ecosystem.
Haven't got the time to read the full article? Download the checklist below.
Content editing features
Features that assist the content editors in their daily activities.
What You See Is What You Get (WYSIWYG)
It doesn't seem to get more contradicting than the terms WYSIWYG and Headless. Ironically, this also seems to be the greatest differentiating factor between the available Headless CMSs. Having a WYSIWYG editor means that editors can edit the content in-page, without having to switch to a preview mode.
In its purest form, a Headless CMS doesn't have WYSIWYG functionality. The content editor edits the content in a basic view, without any site-specific markup. To make sure you don't run into surprises when publishing the content, there usually is a way to preview the content on the site, but more about that later.
Consider adding a news item to the news page of your site. The news item has a title and a rich text field. For this type of pure content, a preview function is more than enough, and you don't need to be able to edit these fields in a WYSIWYG editor. However, often we see the need to be able to control the visual aspects of other types of content.
For example, think of the homepage of an e-commerce site that contains multiple sections with hero images and promotion blocks. One option would be to always involve a front-end developer when changes to the homepage are required. The benefit of this is that you know for sure that changes won't break the layout or the web vitals (such as performance) of the page, but it might be too inflexible for the content editors and marketeers on your team.
The other option is to model this in the Headless CMS. A way to do this is to have a template for the homepage, a template for a hero and a template for the promotion block and allow content editors to add these heros and promotion blocks to a sections field on the homepage item.
This at least allows the content editors to control a part of the page, but it might not be the most user-friendly experience for them. This is where some of the Headless CMSs add features to facilitate this. For example, Kentico Kontent has a feature called Web Spotlight, which allows content editors to visually add these components in the preview mode. Then there are Headless CMSs like builder.io that take it even further by adding a partnering front-end component framework. This re-introduces fully fledged WYSIWYG functionality, and although it keeps some of the benefits of a Headless CMS, one could argue if this should still be considered a Headless CMS.
Most Headless CMSs offer some sort of preview functionality. You edit a content item in a draft status and to see it on the production site you must publish the item. The preview mode allows content editors to view the draft version on the production site, without having to publish it.
Usually this requires some development work: the code accessing the content needs to request the draft version when in the preview mode and the preview URLS need to be configured in the CMS. This usually must be done for every content item: we recommend making the configuration and testing of the preview mode an explicit requirement during development.
We recommend making the configuration and testing of the preview mode an explicit requirement during development.
Most systems have a basic workflow with at least the states Draft and Published. Other systems allow you to fully customize the workflow and align this with your own business processes. For example, do content changes need to be reviewed by another content editor? Is everyone allowed to publish the content or does this need to be approved by someone with a specific role? These are the kind of steps that you would typically model with the workflow.
Scheduling allows you to automatically publish certain changes on a certain date. This can be useful when planning a marketing campaign that requires a lot of content, which needs to be visible on a specific date and time. Most Headless CMS's offer a version of scheduling, some only allow you to schedule individual items, others allow you to group items in a release that can be scheduled. Grouping items into a manageable release can certainly be a useful feature if you are dealing with campaigns that need to be live at a specific date.
Grouping items into a manageable release can certainly be a useful feature if you are dealing with campaigns that need to be live at a specific date.
Versioning allows you to see when an item was changed. In some cases, this is just a list containing the date and author of the change. In other cases, it even allows you to see exactly what was changed in what version. Rollback can also be a super useful feature when you need to go back to an older version of the content item.
Basic support for localization means being able to edit content items in different languages. Some CMSs go further and add functionality to integrate with translation services. Interestingly enough, most Headless CMSs only seem to support English as the general User Interface language. You might have stakeholders using the CMS that don't master English, making a multi-language UI an important requirement.
Interestingly enough, most Headless CMSs only seem to support english as the general User Interface language
Roles and permissions
What options are there to limit access to certain content? For example, can a certain user only manage content for certain content types? Or only add content in a certain language? What about being able to see content, but not being able to edit the content. You would typically manage these options using permissions. Some CMSs have no options for this and any user that has access to the project will also be able to modify everything. Others allow specifying permissions on content types, while some even allow you to do this on individual content items.
Covid-19 forced companies to re-evaluate their business processes and tooling when suddenly employees were forced to work from home. How does this impact Headless CMSs and what online collaboration features do they offer? Before you might have had a physical editorial calendar in the office, but now you will have to resort to online alternatives. What about having an integrated editorial calendar in your CMS? These are some of the forms of collaboration that we have spotted in different CMSs:
- Task management - Being able to create and assign tasks to your team members and to view your assigned tasks
- Comments - Having discussions around content items by adding comments (Can also be used to do reviews)
- Editorial calendar - Planning your content
Do you need to deploy multiple sites? Do these sites need to share content? Different CMSs have different options for a Multisite strategy. When the sites have no shared content and there are different teams responsible for the content, it is usually easiest to create separate projects. Some CMSs even let you share content between separate projects / environments. Others require content to be in the same project to be shared. Often this also means that you need to share the same workflow configuration. And what options are there to restrict the one team from seeing / editing the other team's content? Depending on the CMS and the multisite strategy they support, having separate projects / environments can also have a big impact on costs.
If you require a multisite strategy, this one of the most impacting requirements when choosing a Headless CMS. So, make sure you give this one the proper attention.
If you require a multisite strategy, this one of the most impacting requirements when choosing a Headless CMS
Digital Asset Management
All Headless CMSs offer some basic mechanism to upload digital assets and link to them from content. Differentiating areas are around adding metadata and the ability to edit the assets, such as cropping and resizing of images. Some Headless CMSs also offer a Content Delivery Network (CDN) that hosts the assets. Depending on the CMS there will be extra costs involved for using the CDN, so you might want to investigate if using an external CDN or custom hosting is cheaper.
The User Interfaces of most Headless CMSs we have seen excel in simplicity. The content is usually shown in a big list, which can be filtered on text, content type, author, etc. Some CMSs allow you to create tags or taxonomies to group content. Others allow you to group items in collections or groups, which could be comforting to content editors who are used to the folder-based navigation of the more traditional CMSs. In general, the differences between Headless CMSs in this area are quite small.
Some Headless CMSs offer integrations with other services or apps that are often available through a marketplace. Think of an integration with Google Analytics for tracking content performance. Or integration with a commerce platform for selecting and linking content to products and categories. If you need to integrate with another service, it could save a lot of development effort if the CMS already offers this integration.
If you need to integrate with another service, it could save a lot of development effort if the CMS already offers this integration.
Content modeling features
In order to edit content, you need a content model. Here are some of the features that help with content modeling.
When creating a new content model, what field types can you choose from? At the minimum you need the following field types:
- Rich text
- Boolean (Yes / No)
What might be more important is the option to add validations and help texts. This is a great way to prevent errors on the website because of invalid content. Another important feature is the ability to add a help text to the fields. These help texts can contain instructions for the content editors, for example where the field is used. Adding validations and help texts greatly improves the usability for content editors.
Adding validations and help texts greatly improves the usability for content editors.
Sections allow you to group fields together, which gives content editors a more structured overview of the content item.
Reusable content types
It can be useful to have a mechanism to reuse a set of fields. A common use of this is SEO. For SEO purpose you often need to associate SEO keywords and SEO description with content. Instead of having to redefine these fields for every content type that needs it, some CMSs offer a mechanism to define a content type with those fields, which you can add to every content type that needs it.
Maybe not as visible, but just as important. These are some of the non-functional features being offered.
API stands for Application Programming Interface, which is used by the developers to access the content, so it can be presented on the website.
Most Headless CMSs offer a REST based interface, which is the standard way of exposing an online API. Others offer a GraphQL interface, which is the new kid on the block. GraphQL is developed by Facebook and is built to make an API more discoverable and more efficient in the amount of data it sends over the wire. One of the biggest benefits we see in GraphQL is the ability to explore the API using an online tool, which makes it a lot easier for developers to work with the API.
Webhooks allow you to listen to events in the systems and automate publishing processes. As an example, this can be used to index a content item using a third-party search server when the item gets published.
Content migration tools
Some CMSs have tooling for migrating content from an existing CMS. These can be ready to use tools that migrate data from a CMS like WordPress, but these can also be libraries that make it easier to migrate content that require some custom coding.
Extensibility allows you to extend the UI of the CMS. Often this is also used to build integrations. For example, the commerce platform integrations usually add a new field type that can be used to select a product or category from the commerce platform. If you expect that you will need to extend the UI it is sensible to investigate if the CMS will offer the necessary extensibility. Some only allow you to add custom field types and validations. Others allow you to add entire custom screens. One thing to keep in mind is that if you need a lot of customization, it is probably better to find a Headless CMS that focuses on the data only. For example, sanity.io does not offer a hosted back-end UI, but offers a back-end UI that can be totally modified, which you need to host yourself.
A Headless CMS can be perfectly consumed as Software as a Service (SaaS) and most Headless CMSs have a SaaS offering. This has a ton of advantages: you don't need to maintain infrastructure, the software gets automatically updated, and many others. However, the CMS that best fit your requirements might not have a SaaS offering, or maybe you cannot use SaaS because of legal regulations or company policy. If you need an on-premise CMS, make this the first requirement to filter your list of potential CMSs with.
Content Delivery Network (CDN)
Some CMSs offer a CDN, which can be used to directly serve media to visitors of your website. Additionally, some even offer resizing and optimization, which is a must if you want to have a good performance. If the CMS doesn't offer this, you will need to use another CDN and synchronize the images. Getting a ready to use CDN simplifies your solution and reduces development time. Usually, there are extra costs involved or there are limitations on the usage, so make sure this matches your budget.
Not features, but also important aspects to consider when choosing a Headless CMS.
An active community can be a huge selling point of a Headless CMS. Active discussion fora where people are discussing common issues and challenges can be a life safer for developers and content editors. Sometimes these discussion fora can be a dedicated site, but it can also take place on Discord, Slack or Stackoverflow.
What does the support look like? How fast are they when responding to support tickets? Is there a onboarding process for new customers and partners? Differences here can be huge. Do you prefer a more personal level of contact or are you fine with online documentation and a ticketing system? Some Headless CMSs only offer access to online documentation and tools, but we've also seen Headless CMSs where they will even help the customer with the initial content modeling.
How accessible and complete is the documentation? Is there guidance on common user tasks? How up to date is the documentation? These are some of the questions that you should ask yourself with regards to documentation.
Picking the right CMS
Hopefully this overview of features helps you with your choice of CMS. At Unplatform we are constantly (re-)evaluating Headless CMSs, so please feel free to contact us if you would like to pick our brains. Use our contact form or drop us a mail: email@example.com.
Not sure if Headless is right for you? It takes just a few minutes with our free DXP/Headless wizard to gain insight into the best choice for your organization.