In Verbindung mit Jamstack Websites und Gatsby Projekten taucht auch das Schalgwort "Headless CMS" immer öfter auf.
Bei einem Headless CMS sind - im Gegensatz zu einem klassischen CMS wie WordPres oder Joomla - das Frontend und das Backend nicht ineinander integriert.
Wie das dann funktioniert, erfährst du in diesem Blogbeitrag.
Wenn ich von klassischen CMS spreche, meine ich in diesem Zusammenhang Content Management Systeme wie WordPress, Joomla oder Drupal. Bei diesen CMS sind traditionellerweise Content, Theme, Plugins und CMS-Funktionen miteinander verflochten. In der Fachsprache nennt man das auch "coupled".
Ich kann also im Backend des CMS die Texte und Bilder meiner Website ändern, Erweiterungen installieren und Themes anpassen. Der Vorteil ist hierbei leicht ersichtlich. Man hat einen einzigen Ort, an dem man so gut wie alles steuern kann.
Die Funktionen solch eines CMS gehen über die ursprünglichen CMS-Funktionen weit hinaus. CMS bedeutet eigentlich ja "Content Management System" - WordPress ist zum Beispiel als Blogging-Plattform entstanden. Klassische CMS-Funktionen beschränken sich also auf das Erstellen, Warten und Anpassen von Inhalten.
Gerade in der WordPress-Welt übernimmt das CMS mittlerweile aber viel mehr Funktionen. Caching, Shop-Verwaltung, Newsletter-Anmeldung, Kontaktformulare mit externer Schnittstelle ⇒ All das und noch viel mehr kann mittlerweile direkt in WordPress abgebildet werden.
Das ist aber auch gleichzeitig der große Nachteil. Das CMS wird so zum "Single-Point-Of-Failure". Wenn eine Funktion ausfällt, kann gleich die ganze Website stehen bleiben. Und meistens kann ein System, das irgendwie alles macht, nichts so richtig perfekt.
Um so etwas zu vermeiden, werden Darstellung, Datenspeicherung und Funktionen in der Programmierung generell gerne getrennt.
Ein Headless CMS handelt hier anders. Die CMS-Funktionen beschränken sich normalerweise auf das Erstellen, Bearbeiten, Kommentieren, und Veröffentlichen von Inhalten. Das kann alleine oder im Team stattfinden.
Der Content wird lediglich über die Backend-Maske verwaltet, eine Frontend-Vorschau gibt es nicht. Diese muss erst umgesetzt oder vom SSG bereitgestellt werden.
Die Inhalte werden schließlich über eine API-Schnittstelle bereitgestellt. Diese API-Schnittstelle kann vom Frontend der Website ausgelesen werden. Aber nicht nur das. Solltest du mehrere Kanäle bespielen wollen, wie zum Beispiel Werbe-Bildschirme oder eine App, kannst du die Inhalte dafür ebenfalls über das selbe Headless CMS warten und auslesen.
Das Headless CMS ist also nicht direkt mit dem Frontend verbunden. Funktionen wie Caching, Newsletter oder Ähnliches werden ebenfalls nicht über das CMS erledigt. Das klingt zwar erstmal umständlich, bringt aber einen massiven Vorteil mit sich.
So kann bei einer WordPress-Website ein falsches Plugin deine Seite komplett "zerschiessen". Du hast zwar hoffentlich ein Backup, aber im schlimmsten Fall sind deine Inhalte, dein Design und deine Funktionen beschädigt.
Bei einem Headless CMS passiert dir das nicht. Wenn dein Frontend ausfallen sollte, bleibt dein Backend weiterhin bestehen. Sollte dein Cache nicht mehr funktionieren, bleibt dein Backend bestehen. Und da du nicht so viele Plugins installieren kannst, musst du auch nicht so viel updaten.
Headless CMS gibt es mittlerweile wie Sand am Meer. Dabei kann man zwischen gehosteten CMS und selbst gewarteten CMS unterscheiden.
Gehostete Headless CMS übernehmen die gesamte Infrastruktur und Wartung für dich. Dafür verlangen diese CMS-Anbieter meistens eine monatliche Pauschale, wobei es in den meisten Fällen schon einen großzügigen Free-Plan gibt.
Der Vorteil liegt auf der Hand. Du musst dich nicht um Setup, Wartung, Updates, .. kümmern. Dein Fokus liegt auf dem Content Management. Dafür ist es nicht so einfach, eigene Funktionen oder Abläufe zu definieren.
Ein Beispiel für so ein gehostetes Headless CMS, mit welchem ich arbeite, ist Dato.
Daneben kann man sich natürlich auch selber ein Headless CMS aufsetzen und dieses verwalten. Das ist zwar mehr Aufwand in Setup und Wartung, man hat dafür aber die volle Kontrolle über das CMS. Ein bekanntes Beispiel hierfür ist Strapi.
Solltest du und deine RedakteurInnen WordPress gewöhnt sein, könnt ihr zum Beispiel WordPress als Headless CMS verwenden. Das funktioniert über die REST-API von WordPress, welche automatisch in jeder WordPress-Seite integriert ist.
Dabei solltest du aber nicht vergessen, dass die meisten Plugins und Funktionen von WordPress nicht unbedingt für die Verwendung von WordPress als Headless CMS ausgelegt sind. Wie gesagt - Headless CMS kümmern sich ja nur um den Content.
Die Antwort hierauf ist ein klassisches und herzliches JEIN. Falls du gerne eine schnelle, sichere JAM-Stack-Website haben möchtest, wirst du dafür auch ein Headless CMS brauchen. Ansonsten können die Inhalte ja nicht über die API ausgelesen werden.
Auch wenn du deine Inhalte über mehrere Kanäle präsentieren möchtest, ist so ein Headless CMS sehr sinnvoll.
Falls du dir nicht sicher bist, ob so eine Lösung die richtige für dich ist, kannst du mich aber auch gerne einfach anrufen. In einem - kostenlosen und unverbindlichen - Gespräch können wir uns überlegen, welche Lösung für dich und deinen Geschäftsfall am besten ist.