Mit ⏎ Eingabe suchen – die KI fasst zusammen.
Stellen Sie eine ganze Frage und drücken Sie ⏎ Eingabe — die KI fasst die passenden Seiten zusammen.
Keine passenden Seiten gefunden.
Versuchen Sie es mit anderen Worten.
Quellen auf sutsche.com, öffnen in neuem Tab.
Headless beschreibt, wie ein System Inhalte ausliefert. Nicht, wie modern es ist. Die Entscheidung wird trotzdem oft als Modernisierung verhandelt – und dann prüft man die falschen Dinge. Worauf es stattdessen ankommt.
9 Min. Lesezeit
Ein Headless CMS verwaltet Inhalte in einem technischen Format und stellt sie über eine API bereit. Wie diese Inhalte aussehen, entscheidet der Kanal, der sie abruft.
Der Inhalt liegt hinter der Schnittstelle und wartet. Website, App, Newsletter, Sprachassistent, KI-System: Jeder Abnehmer holt sich dasselbe Material und macht daraus seine eigene Darstellung.
Ein Headless CMS trennt also die Verbindung zwischen Inhalten und Darstellung noch stärker als ein „klassisches“ CMS. Die Hoheit der Darstellung wirdan eine separate Anwendung oder Frontend-Technologie delegiert.
Fast jede Verwirrung um das Thema löst sich auf, wenn man die drei Varianten nebeneinanderlegt. Sie unterscheiden sich nur in einem Punkt: ob das System einen eigenen Kopf mitbringt.
In einem Headless-System werden die Inhalte (im Wesentlichen strukturierte Daten und Rich Text) über eine API bereitgestellt, die von einer Frontend-Anwendung zur Darstellung der Inhalte genutzt wird. Dies ermöglicht es, die Frontend-Technologie unabhängig von der Backend-Technologie auszuwählen und zu ändern, ohne dass die Inhalte neu strukturiert oder migriert werden müssen. Inhalte können über die API auf verschiedenen Plattformen und Geräten veröffentlicht werden, ohne auf eine bestimmte Darstellungstechnologie beschränkt zu sein.
Ein CMS mit einer hybriden Ausgabeschicht kann Inhalte sowohl in Form von strukturierten Daten (d. h. „headless“) über eine API als auch als vollständig gerendertes HTML („headful“) mithilfe einer Template-Engine bereitstellen. Ein hybrides CMS bietet sozusagen das Beste aus beiden Welten. Während Anbieter reiner headless Systeme auf dem Markt noch verhältnismäßig jung (wir reden hier von rund 13 Jahren) und neu sind (auch wenn das Konzept selbst schon sehr alt ist), haben die Anbieter „traditioneller“ CMS diesen Trend erkannt und ihre Systeme um diese Ausgabeschicht erweitert.
Der Hauptunterschied zwischen einem Headless-CMS und einem Headful-CMS besteht darin, dass ein Headless-CMS die Inhalte in kleinen Teilen verwaltet und sie sehr stark von der Darstellungsebene trennt. Ein Headful-CMS trennt ebenfalls die Darstellungsebene und die Inhalte, bietet jedoch ein fest definiertes Frontend („Head“) an. Heißt der Content mit Darstellungsinformationen kommen direkt aus dem CMS. Die Logik wird dementsprechend ebenso im CMS implementiert.
Das ist der Punkt, an dem die meisten Projekte sich verrechnen. Ein Headless CMS ist auf den ersten Blick schlanker, weil Templating, Seitenlogik und Rendering wegfallen. Diese Arbeit verschwindet aber nicht. Sie wandert nur an zwei andere Stellen.
Die erste Stelle: das Frontend. Was das headful System als Template mitgebracht hat, wird jetzt gebaut. Für jeden Kanal.
Und die zweite: das Contentmodell. Im klassischen CMS war es implizit vorhanden, die Seite hielt alles zusammen und niemand musste es aufschreiben. Fällt die Seite weg, muss die Struktur explizit werden, bevor irgendetwas gebaut wird.
Was ein headful System an “Vorannahmen” und “kanalspezifischen Definitionen” implizit mitliefert, müssen Sie bei headless selbst entscheiden. Das ist kein Argument gegen Headless. Es ist das Argument dafür, den Aufwand ehrlich zu kalkulieren. Projekte scheitern hier selten an der Technik, sondern daran, dass der verschobene Aufwand im Budget nie aufgetaucht ist.
Das Versprechen von Headless lautet: Inhalt einmal pflegen, in beliebig vielen Kanälen ausspielen. Dieses Versprechen hängt vollständig daran, ob der Inhalt passend geschnitten ist.
Und ist er es nicht? Dann passiert in der Praxis immer dasselbe. Der zweite Kanal braucht den Inhalt in einer anderen Form, das Modell gibt es nicht her, also baut jemand einen Workaround. Am Ende liegt derselbe Text doppelt im System, einmal für die Website und einmal für die App. Danach dreifach. Genau der Zustand, den das Projekt abschaffen sollte, nur mit mehr Schnittstellen. Nicht schön.
Die typische Ursache ist nicht Nachlässigkeit, sondern eine naheliegende Verwechslung: Kanalspezifische Steuerung landet im Contentmodell, weil sie sich dort am bequemsten pflegen lässt. Die Farbe einer Headline, die Spaltigkeit eines Teasers, ein Ausblenden in der App. Alles legitime Anforderungen, nur eben kein Inhalt. Die App kennt kein „Orange”.
Inhalt: Was ist die Information? Produktname, Preis, Text
Semantik: Was bedeutet die Struktur? Überschriftenebene, Liste, Zitat
Kanalsteuerung: Wie verhält es sich in Kanal X? Headline-Farbe, Spaltigkeit
Diese drei Ebenen auseinanderzuhalten ist die eigentliche fachliche Arbeit eines Headless-Projekts, und sie gehört an den Anfang. Ein Contentmodell ist ein Fundament, und Fundamente korrigiert man nach dem Einzug nur ungern.
Zum Weiterlesen
Wie die drei Ebenen im Detail funktionieren, warum das Rich-Text-Feld die häufigste Fehlerquelle ist und welche vier Modellierungsfehler zuverlässig wiederkehren, steht in unserem Artikel Content-Modellierung: Die zentrale Herausforderung für Headless-Projekte.
Dort steht auch, warum sich ein Contentmodell herstellerneutral erarbeiten lässt. Sie müssen also kein System kaufen, um anzufangen. Im Gegenteil: Ein neutrales Modell ist eines der besseren Werkzeuge, um Systeme überhaupt vergleichen zu können.
Dorthin verschiebt sich der Aufwand. Vieles ist über die Modellierungsoberflächen der Systeme auch ohne tiefes Entwicklerwissen machbar. Der Aufwand für die Darstellung sitzt im Frontend. Wenn entsprechende Entwicklungskapazitäten bereitstehen, lohnt sich ein Blick auf headless Systeme.
Der Inhalt wird an einer Stelle gepflegt, kanalunabhängig, und der Rest läuft über API-Aufrufe. Je mehr Kanäle, desto deutlicher rechnet sich das. Alternativ müssten für jeden Kanal die Inhalte separat gepflegt und verwaltet werden. Hier zeigt sich der Vorteile einer übergreifenden und belastbaren Content Modellierung.
Menschen, die in Entitäten und Strukturen denken statt in Seiten einer Website. Das ist von Vorteil. Es zeigt sich, dass einige Editoren Schwierigkeiten haben das Konzept der Headless Modellierung zu adaptieren. Hier sollte auf jeden Fall im Projekt Zeit und Aufwand eingeplant werden um die Redaktionen auszubilden.
Apps, Kundenportale, Displays in der Filiale, IoT-Geräte. Häufig gibt es keine Alternative, bei der ein System die entsprechenden Verwaltungsoberflächen für Content mitbringt. Es wird dann selbst gebaut oder hart in den Kanal hineinprogrammiert. Jede Änderung kostet Zeit und Geld. Das Kanal Argument zieht hier noch viel mehr.
Bauen sich die jeweiligen Contents in den Kanälen aus vielen verschiedenen Quellen zusammen, lohnt sich auch hier ein Blick in Richtung Headless CMS. Es dreht sich darum, welcher Inhalt wird eigentlich wo verwaltet und lebt entsprechend in welchem System? Dieser Punkt geht Hand-in-Hand mit dem vorangegangenen Kanal-Argument.
Umgekehrt gibt es Situationen, in denen ein headful oder hybrides System die ehrlichere Wahl ist. Eine Website als einziger Kanal, eine Redaktion, die seitenbezogen arbeitet und das auch soll, keine Frontend-Kapazität, enge Budget- und Zeitgrenzen. Jeder dieser Punkte für sich ist noch kein Ausschluss. Drei davon zusammen schon.
Der häufigste Fall in unseren Projekten ist allerdings keiner von beiden: Es sind Unternehmen, die einzelne Kanäle headless bedienen wollen und für die Website beim gerenderten Weg bleiben. Dafür gibt es hybride Systeme, und diese Mischform ist keine halbe Entscheidung, sondern meistens die richtige.
In Projektdiskussionen taucht regelmäßig die Vorstellung auf, Headless sei der aktuelle Stand der Technik und alles andere Altlast. Wer noch ein System mit Kopf betreibt, habe den Anschluss verpasst.
Zwei Gründe, warum das nicht stimmt.
Erstens, begrifflich: Headless beschreibt eine Auslieferungsart, keine Generation. Ein System, das HTML rendert, ist nicht älter als eines, das JSON ausliefert. Es trifft eine andere Annahme darüber, wer die Darstellung verantwortet.
Zweitens, der Markt selbst: Die Trennung, um die hier gestritten wird, haben die Hersteller längst aufgelöst. Die etablierten Systeme haben eine API-Auslieferung ergänzt, die reinen Headless-Anbieter haben Vorschau, Visual Editing und Seitenlogik nachgerüstet. Beide Lager bewegen sich seit Jahren aufeinander zu.
Die Frage ist nicht, ob Sie headless werden. Sie ist, welche Kanäle Sie über eine API bedienen wollen und was Sie dafür an Modell und Frontend investieren.
Wer die Entscheidung als Modernisierung führt, prüft die falschen Dinge. Dann geht es um Produktkategorien statt um Anforderungen, und am Ende steht ein System, dessen größte Stärke niemand im Haus nutzen kann.
Nicht zwingend eigene, aber verlässliche. Die Modellierung läuft über die Oberflächen der Systeme, dafür muss niemand programmieren. Die Frontends muss jemand bauen und danach betreiben. Ob das intern sitzt oder bei einem Dienstleister, ist eine Organisationsfrage. Dass die Kapazität existiert, ist keine.
Ja, und das ist der häufigere Weg. Oft beginnt es mit einem Kanal neben der bestehenden Website, einer App oder einem Portal. Wichtig ist nur, dass das Contentmodell von Anfang an für mehr als diesen einen Kanal gedacht ist.
Nein, aber sie wird zur Aufgabe statt zum Nebenprodukt. Viele Systeme bringen eine Vorschau mit, manche sogar Inline-Editing. Eingerichtet werden muss sie je Kanal.
Nein. Ein Contentmodell lässt sich herstellerneutral erarbeiten und am Ende in die Begriffe des Zielsystems übersetzen. Umgekehrt ist ein neutrales Modell eines der besseren Werkzeuge, um Systeme überhaupt zu vergleichen.
Weder besser noch schlechter. Das Frontend muss natürlich entsprechend angepasst werden, damit es den technischen SEO Anforderungen genügt. Das gilt aber sowohl für headless als auch headful.
Das hängt an der Menge und der Komplexität in Bezug auf Anzahl Kanäle ab. Pauschal kann man das nicht sagen. Viele Systeme bringen Kickstarter-Modell mit, die schon einen bestimmten Satz an Modell-Typen abdecken. Der Zeitpunkt ist dabei wichtiger als die Dauer: vor dem Bau, nicht währenddessen.
Erfahren Sie, wann ein Headless-CMS für Ihr Unternehmen sinnvoll ist. Entdecken Sie die Vorteile und Nachteile und wann ein Headless-CMS Ihnen helfen kann.
Bevor im Headless-Projekt die erste Zeile Code entsteht, fällt die Entscheidung, die alles Weitere prägt: das Content-Modell.
KI-Systeme denken in Entities – in klar definierbaren Dingen mit Eigenschaften und Beziehungen. Unternehmen, Personen, Dienstleistungen, Konzepte.
„Projektkümmerer“ hat uns vor Jahren ein Kunde genannt. Der Name ist geblieben, weil er stimmt. Sagen Sie uns, wo es gerade hakt – wir kümmern uns.
