Headless CMS are here to stay. Even if there are still some reservations about implementation, more and more companies are coming around to the idea of using a headless CMS for their next relaunch. Popular representatives for headless CMS are Sulu, Sanity or Hygraph. Even the classic CMS, WordPress, now has a headless variant. Reason enough, therefore, to take a closer look at what you need to consider in search engine optimisation for a headless CMS.

What is a headless CMS?

A headless CMS is a content management system that only provides the back-end functionality, but not the front-end user interface. This means that the CMS separates the actual content from the subsequent presentation. While classical CMS provide the three components database, backend and frontend, headless CMS are based on only two of these components, database and backend.

This type of CMS is particularly useful when content is to be displayed on different platforms and devices, e.g. on a website, in a mobile app or via a digital assistant. So especially in times of mobile first, the Internet of Things and countless output devices, headless makes perfect sense. It’s fair to say that the closer we get to the IoT era, cross-platform experiences, AI, voice assistants and omnichannel experiences, the more traditional CMSs reach their limits. But how do we optimise for search engines when we can only influence the content, but not the presentation?

SEO for Headless: an introduction

Headless SEO means one thing above all: planning. Before we launch a website, we have to carry out steps that have to take place before the first line of code is written:

1. the data structure: our content consists of contentpieces or so-called entities that have to follow a certain structure. An example: if we want to build a product content database, we have to define in advance which elements we want to maintain for each content piece, in this case the product. Thus: price, dimensions, weight, colour, etc. It is important to note: this data is maintained independently of a desktop or mobile display, we do not limit ourselves by display options in the description of the entity, but define, detached from layout restrictions, with which attributes we provide our product in the best possible way.

2. Templates: in the headless CMS, templates have to be created by the developer via XML. Accordingly, I should consider in advance for each relevant output device exactly how the UX should look best, which fields and content areas are necessary and how the template should look in the end. This procedure is generally recommended when planning a website, but the Headless CMS forces this preliminary concept on us. From a UX point of view (and therefore from an SEO point of view) this is a clear advantage!

We have to think SEO from the beginning! One challenge with the headless CMS is the fact that we lack the corresponding helpers. Whereas with classic WordPress, for example, I can fall back on Yoast* or other SEO plugins that generate fields for the necessary meta information, with the headless CMS I have to plan and create the SEO-friendly source code myself from the scratch. However, this is less complex than one might think.

Necessary fields for SEO that you have to provide in the Headless CMS are:

  • Meta Robots: we need clean control over what content should be indexed and what should not.
  • Canonical Tag: ditto. We define in advance which URL is the main URL of a page and canonicalise pages that are only derivatives of this page.
  • Title Tag: also with the Headless CMS we need an individual and appealing title tag, which should not be longer than 59 characters and which encourages the visitor to click. This information is entered in the backend area of the CMS and can then be retrieved and displayed via the API.
  • Descriptions: like the title tag, this information is generated in the backend. Here too, the following applies: character length between 120 and 155 characters, appealing, unique wording and click incentive.
  • The correct markup according to schema.org for e.g. product descriptions or FAQs.
  • H tags, i.e. the clean hierarchical structure of the content according to headings and sub-headings.

*For the sake of completeness, it should be mentioned that the headless version of WordPress can communicate with Yoast via an API.

Headless CMS & Editors

If the backend is set up accordingly, editors will hardly notice any differences to classic CMSs. With the headless CMS Sulu, for example, which is based on the PHP framework Symfony, all these fields are already stored in the “SEO” tab. The editor also has an editor with live preview at his disposal, which is reminiscent of classic CMS.

It is important that the templates, which are written in XML, implement SEO recommendations correctly. For example, if the editor provides a “headline” for the article, then this should of course be marked as H1 in the corresponding XML template. But let’s be honest: such basics are still not correctly taken into account by many WordPress developers who use H tags as design elements in sidebars during template design in order to use the pretty pre-formatting.

You can even, if you link headless and SEO correctly, build a more elaborate editor than the one usually found in classic CMS. This advantage is excellently explained by Lidia Infante, Senior SEO Manager at Sanity.io in an interview with Loren Baker on searchenginejournal.com. Lidia gives as an example that one can make as a default that H1 and Title Tag must be different, the hierarchy of H-Tags must be respected or the Description must not be over 155 characters long. The editor cannot publish the article if this rule is not met. This is particularly advantageous if the CMS is used by many different editors and stakeholders or if user-generated content is created.

These rules must be clearly defined in advance by the SEO in the company and can then be integrated into the CMS. So we have a green field of content creation, so to speak, which must be used in the best possible way. It is important that we define forward-looking and sensible rules, because later changes always have to be realised directly via IT.

It’s also nice to be able to connect other content sources via API. For example, I can define that my product descriptions are all delivered by an artificial intelligence via Api or that the AI automatically delivers meaningful alt texts for my images. Since the first tests with openai.com at the latest, it has become clear that text creation will change fundamentally in the future. With a headless CMS, you can profit optimally from this further development.

So you see: the biggest challenge with headless CMS is to carry out clean and clear planning before launching a site. From an editorial point of view, the biggest visible difference between a conventional CMS and a headless CMS is the lack of possibility to edit metadata on the fly. However, if the necessary planning has been done in advance, it can be assumed that SEO on the fly is even easier for headless CMS than SEO for a traditional CMS, especially if such an intelligent editor has been created in advance that directly takes SEO into account.

Does the future belong to headless CMS?

In order to answer this question, it is always worthwhile, especially with regard to SEO, to look in the direction of Google and see what employees of the search giant itself have to say about this topic. Back in 2017, Sujoy Gupta (Solutions Architect, Google Cloud Platform) published a declaration of love for Headless CMS. For him, the Headless CMS is particularly advantageous in one use case: when, on the one hand, you have to maintain a corporate website whose content is relatively static and, on the other hand, you have an editorial team that regularly publishes news in the corporate blog, for example. In most cases, this is handled via two independent systems, which means double the support effort. In addition, editors can access entities globally via a headless CMS, which minimises redundancies in the workflow. Let’s imagine: the slogan for a certain product changes and editors no longer have to revise 4 different URLs, but can make this change globally on the product entity – what a convenient idea of content management.

In addition, the headless approach of treating content elements as entities that can be edited independently of the URL on which they appear is very similar to the way Google works in terms of identifying entities. Here, once again, the clear advantage of Headless CMS with regard to SEO becomes clear: I treat content pieces as entities that I can display differently for different output devices via different templates. My content database, however, remains unaffected by the way it is displayed and so templates can be changed with regard to corresponding search queries, for example, if it is recognised that users have further questions about the product, for example, that the mobile template has not answered so far. And with regard to the future, one can only say: which output devices will still come that we can currently only dream of?

Conclusion

Let’s summarise: Headless CMS offer freedom, flexibility, scalability and speed. At the same time, however, they require a lot of planning, initiative and development effort before you can go live with a site. With regard to SEO and headless, one can say: great power brings great responsibility. If SEO is considered from the beginning, a freely designable headless CMS offers enormous advantages over a classic CMS. At the same time, however, if the development does not take SEO sufficiently into account from the beginning, one can have a significantly worse starting point for search engine optimisation than with classic WordPress & Co. In particular, sufficient Java Script SEO know-how should be available in the developer team in order not to create hurdles for smooth communication with search engine bots on the technical side right from the start.

So is Headless the best CMS for your organisation? Let’s answer the way SEOs answer: it depends.

Pic: Wilhelm Gunkel