What is headless CMS?
Headless CMS is a highly flexible approach that involves decoupling the upload of content from its presentation. The idea behind it is that editors always design certain content for a specific medium. For example, for a website, social media or newsletter. This is super inefficient as the same content may have to be adapted or edited again or even several times for other platforms. And this is exactly where the headless CMS comes in and creates efficiency.
How is headless CMS used?
With headless CMS, content is entered by the editors without front-end viewing. The design of the content for the respective platform (website, social media, etc.) is left to specialized systems, which integrate the entered content at the pre-defined locations. The use of headless CMS therefore always makes sense if more than one platform is to be used with similar content.
Should you use a headless CMS?
As always, the answer is: it depends! Headless CMS is a format-neutral content management system that can greatly simplify content creation for authors, so that the focus is really purely on high-quality content. Since today’s CMS with various plugin extensions is often also used for sending newsletters or similar topics, the use of headless CMS is virtually the pure form of the original CMS idea – specifically content management. Here is a comparison of the advantages and disadvantages of headless CMS:
Advantages of headless CMS
Plannability
Headless CMS does not mean simply working into the blue.
Preview mode
Headless CMS usually offer a preview mode where you can view all content in an organized way.
Collaborative working
Headless CMS does not mean that you alone can work on it. There is an author administration so that you can maintain and update content with several editors.
Cloud
Headless CMS are usually cloud-based, so they can be used directly without having to set up your own infrastructure. This keeps operating costs extremely low.
Individuality
Headless CMS are freely configurable and can be linked to a variety of interfaces (API).
Disadvantages of headless CMS
Standardization & structure
Headless CMS thrive on standardization and structure. If individual pages need to be restructured, some effort is required.
Effort vs. added value
Headless CMS is only worthwhile if several platforms and systems are to be supplied with content. If it is only a matter of operating a single website, the effort involved is not in any meaningful relation to the added value.
What SEO requirements should a headless CMS fulfill?
Good question! – We summarize the SEO requirements for a headless CMS.
Indexing requirements
The CMS should offer the possibility to manually create redirects when a page goes offline: management of redirects with selection of the redirect type (301,302,307,308,etc.) and (if necessary) selection of a maintenance code (410,451,etc.).
Information about the backend when a page is redirected to another page
It should be possible to define global rules/patterns with a higher-level “CheckBoxField” in the backend (at individual page level), such as automated NoIndex for paginated pages, etc.
It should be possible to define global rules/patterns with a higher-level “CheckBoxField” in the backend (at individual page level), such as providing external links with NoFollow attributes (levels: page type, page level, etc.).
global rules/patterns with superordinate “CheckBoxField” in the backend (on individual page level) such as automated NoIndex for paginated pages, etc. should be possible.
In the CMS, self-referencing canonicals should be adjustable as standard with higher-level “fields” in the backend (at individual page level).
Editable robots.txt, which uses Disallow/Allow attributes to define which parts of the domain can be crawled by web crawlers and which parts are prohibited for them.
Attributes (e.g. for affiliate links) or link syntax target=”_blank”, rel attribute, rel=noopener attribute should be able to be added to text links.
Requirements for meta data
It should be possible to define global rules/patterns with additional higher-level “fields” in the backend (at individual page level). These include, for example, the definition of defined fallbacks in the event that nothing has been saved, saving placeholders at different levels (e.g. page type, country level, target level, etc.), displaying the pixel length, marking/highlighting the field if the pixel length is not within the “best practice” range.
It should be possible to define global rules/patterns with additional higher-level “fields” in the backend (at individual page level). These include, for example, the definition of defined fallbacks in the event that nothing has been saved, saving placeholders at different levels (e.g. page type, country level, target level, etc.), displaying the pixel length, marking/highlighting the field if the pixel length is not within the “best practice” range.
After URL slugs are added according to the globally defined pattern, it should be possible to customize the URL slug with automatic redirection (if necessary) when customizing the URL slug.
The CMS should only generate URLs according to the following rules: URLs in lower case (avoid capitalization), short URLs, descriptive/speaking URLs, without special characters, without URL encoding, without .html ending or .php ending, etc. A change to the title should not automatically result in a change to the URL.
The CMS should allow default settings in the event that no SEO data is added. Example: The default meta title is composed of the website title and the brand name.
Requirements for SEO content
It should be possible to save hreflang tags for other language variants or language ranges in the source code so that Google distributes the corresponding website/language version to users depending on the country and language. Including default settings for languages other than those available.
The CMS should allow the H1-H6 tags to be decoupled from the visual display. It should be possible to mark each text element as an H1-H6 tag, P tag, div tag, etc. without changing the styling.
Es sollte die Möglichkeit geben, reines html5 zu Textbausteinen hinzuzufügen (z. B. <br>, <strong>, <em>, etc.).
The CMS should enable the setting of global rules/patterns with additional higher-level “fields” at individual page level, e.g. rules that state that the page title becomes the breadcrumb element.
A SEO plugin stored in the CMS can provide information about optimization potential, e.g. by determining the keyword density of the content, missing keywords, the number of words,…
The option of setting and displaying the focus keyword for a page in the backend of a page makes further work easier for SEO and content teams.
Other SEO requirements
A status code checker indicates the status code of the respective URL in the backend. This is used, for example, to check the status code via the API response) and incorrect status codes can be quickly adjusted and (if necessary) redirects set up.
A health check in the CMS shows which pages need to be improved (e.g. pages with files that are too large, incorrect image resolution, large number of CSS and JavaScript files).
SEO-specific fields should contain parameters, counters, specifications such as the maximum title length and a warning if the data is incorrect.
It should be possible to add site verifications to a website (Google, Bing, Baidu, Yandex, etc.).
To see which pages are not optimally set in the SEO-relevant data, an overview at macro level is helpful, in which relevant data can be selected/displayed/changed.
Relevant tags can be set and displayed here in the backend (e.g. for SEO/SEA/campaigns/etc.). There are often features for this where, for example, if a page is tagged as a pure SEA page, a rule takes effect and it is automatically set to NoIndex.
Provides information on the number of links to other internal URLs to ensure good internal linking and a clear website structure and to prevent excessive internal linking.
It should be possible to add tags that indicate whether a page is relevant for the site search or not.
Custom meta information for optimal display on social media (Facebook, LinkedIn, Twitter, Instragram and Pinterest) should be able to be added. Including fallback image, etc.
The htaccess should be editable in the CMS.
What requirements should a headless CMS fulfill for a good workflow?
A good workflow makes it easier to create and edit websites. A headless CMS should fulfill the following requirements.
The CMS should offer the following:
– A simple structure of content components that are easy to use
– Full flexibility when creating new pages, without (technical) restrictions
– Flexible combinations of all content components and the option to reuse components
– Modules and sections that are decoupled from the page types
It should be possible to repeat each section on a single page multiple times and reuse components on different pages and templates.
There should be no restrictions on components, number of contents, type of contents and the like.
The CMS should allow the creation of hub pages that have a hierarchy to each other and whose content is only partially edited or edited via parameters.
Functions such as full-text search or fuzzy search make it easier to navigate the content.
For a more efficient workflow, it should be possible to update data in bulk in the CMS.
The workflow is also facilitated by the function of automatic pre-filling of the basic infrastructure, such as the insertion of UUIDs, in order to avoid manual errors.
It should be possible to create a preview of the pages for pre-live checks. A preview for mobile versions (smartphone, tablet) should also be possible.
Correct tracking codes should be implemented and checked regularly to obtain important KPIs, e.g. display of views, sessions per page, bounce rate, CTR, impressions, conversions/leads
Not a must, but a nice-to-have are to-do lists for an automatic check for missing content or pages that still need to be edited. This should be used to create to-do lists for the creation of new (missing) content and the regular updating of existing content.
What content requirements should a headless CMS fulfill?
In terms of content creation, a CMS should fulfill the following requirements.
DE/AT/CH pages must be individually editable
With the help of a publication date, it must be possible to plan publication by time stamp and to deactivate campaigns at a defined time.
It should be possible to create global modules that dynamically access specific content. At the same time, it would be good if these modules could be decoupled so that individual settings can be made.
It should be possible to define default settings for fields, for example for sections. Use case: all pages of a type should already preload the matching sections.
The ability to check the content for completeness, spelling, plausibility, etc. is an advantage.
The CMS should allow content tagging by topic to organize similar content.
Depending on the country and language, linguistic changes should be made automatically. For example, double S instead of ß in Switzerland.
The ability to edit content in the front end means that changes can be made more quickly and efficiently.
A visual builder simplifies the construction of pages and provides a visual illustration during the creation process.
Conclusion
By using a headless CMS, content maintenance can be greatly simplified, the focus can be placed more on content management and high-quality content can be provided thanks to better planning. In principle, the use of a headless CMS makes sense as soon as more than one platform is to be used with similar content and as soon as several people want to collaboratively adapt content in the cloud at the same time.
A headless CMS has many advantages, but it is also important that the respective SEO, workflow and content requirements are met in order to offer real added value. If you are considering using a headless CMS but still need help in certain areas, don’t hesitate to contact us.