Die Einführung eines CMS stellte etwa ab Beginn der Nullerjahre eine der typischen Investitionen in die Unternehmens-Website dar. Das hatte einen einfachen Grund. Die Inhalte, die Besucher der Website sehen würden, sollten von den Personen eingepflegt werden, die die Inhalte fachlich auch erstellen konnten. Damit legten CMS einen Konflikt bei, nämlich den zwischen Designer und Content-Ersteller.

Vor dem Auftreten der CMS waren Websites stets eine Mischung aus Design und Inhalt. Die Inhalte wurden vom Designer eingepflegt, weil die Content-Lieferanten sonst mit großer Wahrscheinlichkeit das Design zerstört hätten. Das ging rund zehn Jahre ganz gut, aber irgendwann nahm der Wunsch der Website-Auftraggeber, immer mehr und immer aktuellere Informationen immer unkomplizierter und ohne kostspieligen Designer-Einsatz kommunizieren zu können, massive Ausmaße an.

Die Lösung waren die damals noch Redaktionssysteme genannten CMS. Diese Systeme waren in der Regel Datenbank-Aufsätze, die deren Inhalte über spezielle Tags abrufen konnten. Diese Tags wiederum musste der Designer in die Gestaltung integrieren, wo sie als Platzhalter für die eigentlichen Inhalte galten. Die Template-Engine war integraler Bestandteil des CMS, im Grunde sogar dessen Kern. Webdesign wurde so zum Template-Design, der ersten Design-Abstraktion von vielen, die noch kommen sollten.

Hatte der Designer nun für alle infrage kommenden Inhaltstypen ein Template, eine Vorlage, erstellt, konnten der Kunde oder seine Mitarbeiter über eine eigene Verwaltungsoberfläche, das Backend, Inhalte erfassen. Für den Designer war diese Teilung nur semi-gut, denn Bilder gehörten natürlich ebenfalls zum Inhalt, konnten aber bei unsachgemäßer Verwendung das sorgsam gestaltete Layout ebenso zerschießen wie ein Text, dessen Autor dabei versehentlich ein paar HTML-Tags überschrieben hatte.

Viele Schulungen, Tutorials und Nervenzusammenbrüche später, im Jahr 2020, funktionieren CMS, Design und Inhaltezulieferer ganz ordentlich. Redakteure, wie die Inhaltezulieferer im CMS-Kontext heißen, wissen zumindest grob über Bildformate, Größen, Auflösungen und Schriftarten und -größen Bescheid. CMS wurden zudem mit Funktionen ausgestattet, die die gröbsten Nutzerfehler, etwa viel zu große Bilder, automatisiert behandeln.

Das ist alles fein. Aber, es reicht nicht mehr. Denn heutzutage wollen immer mehr Unternehmen ihre Inhalte nicht mehr nur auf die eigene Website bringen. Vielmehr gibt es inzwischen eine Vielfalt verschiedener Geräte, die im besten Falle alle bedient werden wollen. Der Marketer wird das jedenfalls vorschlagen, weil er das Mantra pflegt, man müsse die Kunden da abholen wo sie sind, womit er nicht Unrecht hat.

Nun kann aber das Template eines Standard-CMS nur bedingt geräteagnostisch gestaltet werden. Bis zu gewissen Grenzen kommen wir hier mit responsiven Design-Ansätzen weiter. Damit erreichen wir Desktop- und Mobilbrowser mit Abstrichen recht zuverlässig.

Wie aber bringen wir die Inhalte auf Geräte ohne Browser, etwa Smartwatches, Smart TVs, Autos oder sonstige noch zu ersinnende Displayformen? Wäre es zudem nicht gut, wenn Inhalte aus dem Web-Auftritt in der nativen App eingesetzt werden könnten?

Wenn diese Überlegungen angestellt werden, kommt das Headless CMS ins Spiel. Diese neue Art von Content-Management-System liefert Inhalte über eine Schnittstelle aus. Es kommt nicht mit einer eigenen Template-Engine, die für die Anzeige verwendet werden müsste. Dieses Fehlen der Anzeigeeinheit gibt dem CMS den Zusatz „Headless“. Eigentlich müsste es „Faceless“ heißen, weil dem CMS ja quasi nur das Gesicht fehlt, aber die Terminologie sieht nunmal das Headless vor.

Statt mit einer Template-Engine kommt ein Headless CMS mit einer API, einer Programmierschnittstelle. Die Datenbank und das Backend existieren nach wie vor im CMS-Konzept, die Inhalte aber werden per API ausgeliefert respektive ausgelesen. Diese Schnittstelle ist eine REST-API, die per HTTP-Requests über das Web abgefragt werden kann. Dabei ist die Methode ansonsten variabel.

So kann die REST-API mit beliebigen Programmiersprachen angesprochen werden. Daten werden vollkommen dynamisch geliefert und nicht nur bei einem Reload wie bei konventionellen CMS. So können die Inhalte eines Headless CMS wie bisher in Websites zur Anzeige gebracht werden. Dabei muss die Website aber nicht auf dem gleichen Server liegen. Vielmehr sind die Inhalte mittels API-Zugriff überallhin zu transferieren wo sie der Entwickler sehen will. Das kann neben einer oder mehrerer Websites auch ein Portfolio nativer Apps oder die Syndikation an andere Abnehmer sein.

Ein weiterer positiver Aspekt ist die erhöhte Sicherheit einer Headless-Lösung. Da das Backend nicht transparent zur Darstellung gehört, ist es nicht so einfach zu identifizieren und entsprechend zu attackieren wie bei traditionellen CMS, allen voran WordPress.

Dennoch, aufmerksame Leser erkennen schon, das Headless CMS ist nicht der native Nachfolger traditioneller CMS wie WordPress, sondern eher eine Weiterentwicklung des Systems für besondere Bedarfe. Wer lediglich seine Website mit Inhalten bestücken will, kann das zwar prinzipiell auch Headless realisieren, sollte aber bei den unkomplizierteren herkömmlichen CMS bleiben. Man schießt schließlich nicht mit Kanonen auf Spatzen. Die erhöhte Sicherheit reicht nicht allein als Umstiegsgrund.

Wo aber die Inhaltsdistribution über diverse Plattformen, Medien und Geräte zur Standardanforderung gehört, ist das Headless CMS das Werkzeug der Wahl. Da diese Form des Inhalteabrufs schon konzeptionell mit erhöhten Anforderungen einhergeht, muss von Beginn an darauf geachtet werden, dass die Headless-Lösung selber keinen Flaschenhals darstellt.

Moderne Headless CMS arbeiten daher in der Regel als Cloud-SaaS (Software-as-a-Service), was sinnvoll ist, weil die Leistung damit nach Bedarf skalieren kann. Ein Headless CMS auf einem herkömmlichem Webserver zu betreiben, wird in der Regel nicht zu empfehlen sein. Selbst wenn die potenziell sehr vielen Requests auf die REST-API das System nicht in die Knie zwingen sollten, bleibt doch das Risiko eines Serverausfalls, der dann zur Folge hätte, dass nicht nur die Website ohne Inhalte da stünde.

Wenn ihr euch langsam an das Thema Headless CMS rantasten wollt, empfiehlt sich der Weg des Progressive Decoupling, der progressiven Entkopplung. Für diese Vorgehensweise könnt ihr bei traditionellen CMS wie WordPress oder Drupal bleiben. Beide lassen sich über ihre jeweilige REST-API „decoupled“, entkoppelt von ihrer Template-Engine betreiben.

Dabei wird die Website jeweils weiterhin über die integrierte Template-Engine mit ihren Funktions-Hooks als Inhaltsplatzhaltern bedient. Die ebenfalls vorhandene REST-API kann hingegen genutzt werden, um etwa Progressive-Web-Apps (PWA) mit den CMS-Inhalten zu bestücken. Für die Entwicklung solcher PWA kommen in der Regel Javascript-Frameworks wie ReactJS, Vue oder Angular zum Einsatz, die in dieser Form nicht mit WordPress zu verwenden wären, im Decoupled-Ansatz aber funktionieren. Die Interaktion etwa mit der REST-API von WordPress funktioniert über das Senden und Empfangen von JSON-Paketen.

Wir werden uns hier bei t3n in Kürze intensiver mit den verschiedenen Anbietern eines Headless CMS beschäftigen. Hier erhaltet ihr daher zunächst nur eine Liste der verschiedenen Anbieter, die ihr dazu nutzen solltet, selbst erste Eindrücke zu gewinnen.

Diese Headless CMS konkurrieren derzeit am Markt (ohne Gewähr für Vollständigkeit):

1. Contentstack
2. Butter CMS
3. Kentico Content
4. Graph CMS
5. EZ Platform
6. Prismic
7. Contentful
8. DotCMS
9. Mura
10. Core DNA
11. Craft CMS
12. Cockpit CMS
13. Cloud CMS
14. Storyblok
15. Scrivito
16. Strapi
17. Superdesk
18. Evoq Content
19. Squidex
20. Sanity
21. Cosmic JS
22. Gentics Mesh
23. Directus
24. Zesty.io
25. Quintype
26. Comfortable
27. Gather Content
28. Prime
29. Takeshape

Passend dazu:

• Von klassisch bis headless: Content-Management-Systeme im Überblick
• Headless CMS bieten mehr Flexibilität: Die neue Architektur auf dem Prüfstand
• Headless CMS Contentstack erhält Finanzspritze über 31,5 Millionen US-Dollar
• Playwright: Headless-Node-Bibliothek automatisiert Chrome, Firefox und Webkit
• The Headless Web und das Ende des Webdesigns