Whether it is for use on your own site or application or for the needs of a client, the headless CMS can be very practical for setting up a content management solution.
When setting up a headless CMS, it is important to ask yourself a certain number of questions in order to make the best choice, because it is not easy to migrate from one CMS to another. On which criteria should you choose your headless CMS and which points should you check? Follow our checklist.
The ease of setup is a determining factor in the choice of a headless CMS. You should therefore consider the quality of the documentation, the presence of tutorials (especially videos), the presence of starters or theme templates to speed up the setup.
For some hybrid headless CMS, the implementation can also be accelerated by the availability of pre-designed blocks (UI components library) : adaptable and reusable blocks for content editors when they work on content.
For some CMS, the implementation may require much more work than others on the following points:
installation of the sitemap and robots file
links management (with implementation of mini-routers to manage internal links)
management of languages (locales)
SEO management : existing SEO module vs create the whole meta from scratch
creation of pages: more or less work depending on the CMS to retrieve the data of components and display blocks of edition depending on these components.
The presence of a CLI (Command Line Interface) often allows to accelerate the implementation on the configuration you want and with themes or pre-existing starters.
Headless CMS are usually implemented by developers but used by content editors or marketers who are not "technical" (and do not code). The headless CMS must therefore be user-friendly enough for them and offer :
A live preview, a preview (outside of the content editor) and the ability to see the result on multiple screen sizes.
A simple interface, without necessarily having to manage the responsive blocks (this one having been worked on beforehand by the front-end developer). The interface must allow the content editor to know how the page will be structured and not have to worry about the layout (from a technical point of view: padding, margin, responsive, dark mode, ...).
Organized content: folder system to organize content and assets, separation of pages into different languages for multilingual sites, possibility to search pages and assets (images, files).
Roles and permissions: not all content editors have the same rights. Some can create pages and content in draft, others can publish pages in production. Some headless CMS may also offer content review flows (passing an action from one user to another).
In many cases, the administration space for editing content is located on the headless CMS site. Some others (like Suncel) allow you to have the content editing space directly connected to your site. This allows content editors to stay on your site and avoid multiplying content management spaces.
The administration space should therefore go to the essentials and focus on publishing content: creating and updating content, adding new assets or modifying existing ones.
Even if the cost of the license is to be taken into account, it is not the central determinant in the overall consideration of the budget of your headless CMS. Here are the different elements to take into account:
Setup cost: the setup may require more or less work for the dev team, whether the front-end has to be done "from scratch" or whether templates exist. Some hybrid CMS are more integrated with a front-end technology (React.js / Next.js, Vue.js / Nuxt, ...) , this can speed up the implementation and reduce the budget.
Migration cost: if you migrate a site with a different technology and with a lot of content, the migration cost must be evaluated.
License: beyond its monthly cost, check the potential savings on annual plans, often allowing a reduction of up to 30%. Also pay attention to the cost that follows the evolution of your own business. If you expect a lot of traffic, an increase in the number of uses (e.g. content editors) may result in an increase in the license.
Hosting: Is it a CMS where you have to manage the hosting or is hosting included in the license? In general, hosting is paying for open-source headless CMS (since it is often their revenue model).
Some headless CMS offer more or less complete SEO modules. If nothing exists, the developer in charge of the implementation will have to define himself all the META and structured data that the content editor will have to fill in for each published page.
For hybrid CMS that take care of a part of the front-end, it is interesting to take into consideration the benefits of technologies like Next.js on the image optimization (size optimization according to the device and weight compression), fonts optimization (loading, cumulative layout shift problems, ...), on the Core Web Vitals improvements, and server side rendering. All these optimizations allow to have better performing content pages and therefore better SEO.
Most headless CMS offer to manage your assets, i.e. the images and files that constitute part of the content of your site or application. Take into consideration the authorized weight of the assets, its download limitations but also the possibility to manage your assets in folders. This seems obvious, but many headless CMS do not offer it and it can quickly become complicated to find your way around when the images or files become numerous.
If your site or application is in several languages, it is important to consider how the languages are managed at the editing level. This is usually referred to as "locale" which includes language and region information. For example fr_FR and fr_BE represents French in France and Belgium.
If you plan to have several languages on your site, you should pay attention to the following elements
The extra cost: some plans are limited to one locale. Adding other locales can therefore change the price scale.
The ease of content management : mapping between the same page in several languages, possibility to sort the content by page, ...
The management of the sitemap : some headless CMS allow to manage automatically a multi-languages sitemap with the addition of the pages in the sitemap when they are published or the modification of the dates during updates for example.
Whether it is for traditional headless CMS or more hybrid CMS, the construction of templates, content types or layouts allows to save time when creating content.
Headless CMS working with a logic of stackable blocks to build a page have become more and more popular. The idea behind the blocks logic is to build a library of pre-designed blocks built one time by the developer and used endlessy by the content editor. These blocks can contain repeatable elements, other nested blocks or simple editable elements like text, rich text, images, links, ...
In addition to pre-designed blocks, headless CMS can also offer page templates that can contain a series of blocks with pre-set and editable data. We can also find pages with particular layout models. For example, on the same site or on the same application, we will find a standard page template (vertically stacked blocks) and a page template for a blog for example with a part on the right or on the left of the page that will display preview of related articles or the latest articles published.
In your choice of headless CMS and on the plan you choose, check the possibility of accessing the history of changes made on your content. If you publish content by mistake and overwrite content, this will give you the ability to look back at previous versions and find back the lost content. Version history also gives you the ability to audit changes to content: who changed, what was changed and when.
Finally, check out the ability to make backups of your content. Enterprise plans (i.e., customized), often offered to larger companies, allow you to get backups on demand.
It is also important to find out how the headless CMS performs its own backups (frequency and duration) and to know with which provider the data is stored.
Some Headless CMS allows you to store your website's content on your own Git provider. During the setup of the CMS, you will be asked to connect your Headless CMS to your favorite Git provider. Later on, each change to your content is committed back to your Git repository.
The content stored in Git is generally in an MDX (markdown) format, and therefore, it is easy to modify even without the CMS. A Git-Based CMS gives you better control over your content and prevents you from being locked to one specific CMS as you can migrate out from it more quickly than with other CMS.
There are many examples of open-source CMS: Wordpress, Drupal, Strapi, ... The principle is simple: the code is completely open as its name indicates and the business model is based on third-party services (marketplace, widgets, hosting, ...). However, even in self-hosted, open-source headless CMS can still have a pay per user component.
In case of bankruptcy of the CMS, the fact of being open-source allows to have the code even if the company that created it is no longer there.
For security, open-source software is reviewed by a community, which makes it easier to identify possible security flaws (still requires a large community). it may also be easier to identify flaws in newer CMS...
However, limiting yourself to open-source headless CMS may limit your choice and deprive you of headless CMS that may be better from an ease of use point of view for content editors, maintenance or ease of installation.
Headless CMS can be more or less "tech agnostic" on the front-end. Some CMS are pure headless: the data is pure content and that it aims to be displayed on several interfaces (or devices) for example via a GraphQL API or a RESTful API.
Other CMS (hybrid CMS) contain content but also layout elements that can refer to internal elements of the project (blocks for example).
Hybrid CMS are generally simpler to set up because part of the front-end integration can already be done (at least partially). However, it is common for headless CMS to offer SDKs to speed up the implementation on your front-end technology. The SDK contains a list of tools linking the API of the headless CMS and the front-end technology you will use.
Hybrid CMS can also offer more flexibility in their components (also called blocks, slices or bricks):
integrate repeatable elements
offer several variations of components (so as not to multiply same components that are visually close)
contain dynamic data (retrieved by API or via a database)
It can be useful to integrate the CMS with other tools, for example for task automation or information distribution.
It is therefore important to check what the API of the headless CMS allows to do and also the presence of webhooks, which can for example inform a team of the publication of new pages or the arrival of new users who edit content.
It is also common for a headless CMS to offer integration with e-commerce solutions such as Shopify.
Headless CMS are much less vulnerable than a CMS like Wordpress (see our page on headless Wordpress), which can be affected by insecure or vulnerable plugins.
Wordpress is the most popular CMS and is therefore a prime target. Plugins can be designed by any developer and include security holes (intentional or not).
The implementation may require support, especially when you encounter errors and the documentation does not sufficiently answer your questions. Pay attention to the presence of a Slack or a Discord, which are signs of the responsiveness of the headless CMS support team.
Support can also be useful during updates if problems are encountered with the headless CMS update.