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.
Bevor im Headless-Projekt die erste Zeile Code entsteht, fällt die Entscheidung, die alles Weitere prägt: das Content-Modell. Wer dabei Inhalt, semantische Struktur und kanalspezifische Steuerung nicht sauber trennt, baut sich Probleme ein, die bei jedem neuen Kanal und jedem Relaunch wieder auftauchen. Die gute Nachricht: Wie es richtig geht, ist erstaunlich unstrittig – man muss es nur vor dem Bau tun, nicht während.
Die Frage in der Überschrift klingt albern. Sie ist es nicht. Sie ist der schnellste Weg, um zu prüfen, ob ein Content-Modell trägt. Denn die Farbe einer Headline landet erstaunlich oft im Content-Modell – als Dropdown mit zwölf Optionen, gleich neben dem Feld für den Text. Und wenn dann der zweite Kanal dazukommt, die App, der Newsletter, der Sprachassistent oder das KI-System, dann steht dort ein Wert namens „Orange”, mit dem niemand etwas anfangen kann.
Genau darum geht es bei Content Modellierung. Und in Headless-Projekten ist sie keine Fleißaufgabe für später, sondern eine der zentralen Herausforderungen ganz am Anfang. Dieser Artikel erklärt, warum – und welche drei Ebenen Sie dabei auseinanderhalten müssen.
Was Sie danach nicht können müssen: es selbst machen. Dafür gibt es uns.
Ein Content-Modell beschreibt, aus welchen Bausteinen Ihre Inhalte bestehen und wie diese zusammenhängen:
Im klassischen CMS war das oft implizit gelöst: Die Seite war die zentrale Einheit, der Redakteur schob Inhalte in ein Layout, fertig. Das Content-Modell stand nirgendwo – war aber überall.
Im Headless-CMS funktioniert das nicht mehr. Hier gibt es keine „Seite”, die alles zusammenhält. Es gibt strukturierte Inhalte, die über eine API an beliebige Kanäle ausgeliefert werden. Das Content-Modell ist damit nicht mehr Nebensache, sondern das Fundament. Und Fundamente korrigiert man nach dem Einzug nur ungern.
Die häufigste Falle: Es wird alles in einen Topf geworfen, was der Redakteur „irgendwie braucht”. Inhalt, Formatierung, Design-Steuerung. Das fühlt sich am Anfang pragmatisch an – und rächt sich spätestens beim zweiten Kanal.
| Ebene | Frage | Beispiel | Gehört... |
|---|---|---|---|
| Inhalt | Was ist die Information? | Produktname, Preis, Text | ... kanalneutral ins Content-Modell |
| Semantik | Was bedeutet die Struktur? | Überschriftenebene, Liste, Zitat | ... als Struktur ins Content-Modell |
| Kanalsteuerung | Wie verhält es sich in Kanal X? | Headline-Farbe, Spaltigkeit | ... in Kanal-Konfiguration und Designsystem |
Der Kern. Die Information, die unabhängig von jedem Kanal Bestand hat: der Text einer Pressemitteilung, Name und technische Daten eines Produkts, Datum und Ort einer Veranstaltung.
Ein einfacher Test: Würde diese Information auch dann noch stimmen und gebraucht werden, wenn es Ihre Website morgen nicht mehr gäbe? Dann ist es Inhalt – und gehört vollständig und kanalneutral ins Modell.
Inhalt braucht Struktur, um verstanden zu werden – von Menschen und von Maschinen. Die semantische Ebene sagt, was etwas bedeutet, nicht wie es aussieht:
Wichtig: Semantik ist nicht Design. Eine H2 ist keine „große fette Schrift” – sie ist die Aussage „hier beginnt ein neuer Unterabschnitt”. Wie groß und fett das dargestellt wird, entscheidet der Kanal: die Website rendert ein HTML-Element, die App eine eigene Komponente, der Sprachassistent eine Pause mit Betonung.
Wie sehr Semantik zum Standard geworden ist, zeigt ein Blick über den Tellerrand: Die Website Specification von Joost de Valk dokumentiert plattformunabhängig 137 Merkmale einer technisch guten Website – mit eigenen Kategorien für Accessibility, SEO und Agent Readiness. Semantik ist dort kein Nice-to-have, sondern durchgehende Anforderung.
Und dann die dritte Kategorie – die heimliche Quelle der meisten Modellierungssünden: Steuerungsinformationen für genau einen Kanal.
Das sind legitime Anforderungen. Aber: Sie sind kein Inhalt. Die Farbe einer Headline sagt nichts über die Pressemitteilung aus – sie sagt etwas über das Design eines Kanals.
Hier hilft ein Prinzip, das sich quer durch die Dokumentation der etablierten Headless-Systeme findet: Ein Content-Typ ist ein API-Vertrag. Ein Versprechen an jedes System, das ihn konsumiert. Und in einen Vertrag schreibt man nichts hinein, was der Vertragspartner nicht lesen kann. Die App kennt kein „Orange”.
Die Lösung ist nicht, solche Steuerung zu verbieten – sondern sie bewusst zu verorten: in kanalspezifischen Varianten, in der Frontend-Konfiguration, in den Design-Tokens. Und wenn sie doch ins CMS muss, dann klar gekennzeichnet als das, was sie ist.
Ein Ort verdient besondere Aufmerksamkeit, weil dort alle drei Ebenen zu Brei werden: das Rich-Text-Feld.
Ein klassisches HTML-Rich-Text-Feld speichert Inhalt, Semantik und Formatierung in einem einzigen Klumpen. Was dort einmal drin ist, lässt sich kaum noch getrennt auswerten. Der Klassiker aus der Praxis: filterbare Fakten im Fließtext vergraben. Die Leistung eines Motors, der Preis, die Verfügbarkeit – als Satz im Rich Text formuliert statt als eigenes Feld. Die Folge: nicht filterbar, nicht wiederverwendbar, nicht maschinenlesbar. Und genau die Information, nach der Ihre Kunden suchen würden.
Deshalb geht die Empfehlung inzwischen breit in Richtung strukturierter, JSON-basierter Rich-Text-Felder gegenüber HTML-basierten: Sie speichern Bedeutung statt Darstellung. Und was wirklich ein Fakt ist, gehört ohnehin in ein eigenes Feld.
Lange war das stärkste Argument für saubere Modelle die Wiederverwendung über Kanäle hinweg. Das gilt weiterhin. Aber es ist ein neuer, gewichtiger Leser dazugekommen.
KI-Agenten besuchen Ihre Inhalte heute schon – sie vergleichen Produkte, beantworten Fragen Ihrer Kunden, empfehlen oder ignorieren Ihr Angebot. Tom Cranstoun beschreibt das in “AI, MX, and the Future of Business”treffend: Wenn ein Agent Ihre Inhalte nicht versteht, schreibt er keine Beschwerde-Mail – er routet einfach um Sie herum. Seine Disziplin „Machine Experience” fordert genau das, was gute Content Modellierung leistet: Bedeutung gehört in die Struktur, nicht in eine Render-Pipeline vergraben.
Anders gesagt: Ein Modell, in dem Inhalt und Semantik sauber von kanalspezifischem Design getrennt sind, ist automatisch maschinenlesbarer. Eine KI kann mit „das ist der Produktpreis” etwas anfangen. Mit „orangefarbener Textblock, zweispaltig” nicht.
Jetzt kommt die Stelle, an der es in der Praxis knirscht. Denn gute Content Modellierung beginnt ausgerechnet beim Design: Man nimmt Wireframes, Mockups oder Figma-Screens und zerlegt sie in ihre Bausteine, statt sich Inhaltstypen am Schreibtisch auszudenken. Da dürften sich die Hersteller ausnahmsweise einig sein.
Das Paradox: Man startet beim Kanal – und muss sich beim Modellieren genau davon lösen. Aus dem Screen kommt die Erkenntnis „hier gibt es einen Teaser mit Bild, Headline und Link”. Nicht die Erkenntnis „hier gibt es einen Teaser, der orange ist und zweispaltig läuft”.
Diese Übersetzungsleistung – vom konkreten Screen zum kanalneutralen Modell – ist der eigentliche fachliche Kern der Content Modellierung. Und der Punkt, an dem Projekte ohne Erfahrung reproduzierbar hängen bleiben.
Aus den Best Practices der gängigen Headless-Systeme lässt sich eine Fehlerliste destillieren. Vier davon tauchen besonders zuverlässig auf:
Das ist ein teuerer Fehler / eine teure Entscheidung. Es multipliziert ggf. die eigentlich benötigten Modell-Typen aus, obwohl das nicht notwendig ist. Richtig ist das Gegenteil: wenige generische Seitentypen, zusammengesetzt aus wiederverwendbaren Bausteinen. Andernfalls ist die Instandhaltung sehr aufwändig und teuer – genau das, weshalb man sich eigentlich potentiell für ein headless System entschieden hat. Es erfordert also ein Umdenken im Content Management.
Bausteine in Bausteinen in Bausteinen. Die Faustregel aus der Praxis: nicht tiefer als drei Ebenen. Vierte und fünfte Ebene sind für Editoren und Redaktionsteams schon eine Herausforderung - also absolutes Maximum vier bis fünf. Jenseits davon weiß der Redakteur nicht mehr, wo er sich befindet.
Lokalisierung ist keine Voreinstellung, sondern eine Entscheidung pro Feld. Ein Datum, eine Zahl, ein interner Schlüssel muss nicht übersetzt werden – wird das Feld trotzdem lokalisierbar, entstehen Pflegeaufwand und Inkonsistenzen. Und: Die Lokalisierungsstrategie muss vor dem Bau feststehen, weil sie sich später kaum noch ändern lässt.
Der teuerste Zeitpunkt für Korrekturen. Wenn das Modell erst entsteht, während schon gebaut wird, zahlt man jede Erkenntnis doppelt: einmal im Konzept und einmal im Rückbau.
Erstaunlicherweise - oder vielleicht auch eben nciht - sind sich die großen CMS Hersteller bei der Art und Weise, bei Best Practices und wie man modellieren sollte, recht einig. Jedoch drücken es natürlich alle etwas anders aus. Ein Detail, das bei der Systemauswahl regelmäßig für Verwirrung sorgt: Die gängigen Headless-Systeme arbeiten mit derselben Schichtenlogik, benutzen aber unterschiedliche Begriffe dafür.
| Was gemeint ist | Contentful | Storyblok | Contentstack |
|---|---|---|---|
| Seitentyp / Template | Content Type (Assembly) | Content Type | Content Type |
| Wiederverwendbare Komponente | Referenced Entry | Nestable Block | Modular Block |
| Wiederverwendbares Feldset | – | - | Global Field |
| Beziehung zwischen Inhalten | Reference Field | Reference Field | Reference Field |
| Feststehende Auswahl | Validation / Dropdown | Datasource | Select Field |
Drei Systeme als Beispiel, weil sie ihre Modellierungslogik offen dokumentieren – nicht als Empfehlung und nicht als Marktübersicht. Andere Systeme lösen es mit eigenen Begriffen.
Wir halten hier an der Stelle fest: Ein Content-Modell lässt sich herstellerneutral erarbeiten und erst am Ende in die Sprache des Zielsystems übersetzen. Sie müssen also nicht erst ein System kaufen, um mit dem Modellieren beginnen zu können. Im Gegenteil: Ein sauberes neutrales Modell ist eines der besten Werkzeuge, um Systeme überhaupt sinnvoll vergleichen zu können.
Ein Content-Modell ist kein Diagramm, das nach dem Workshop im Laufwerk verstaubt. Es ist ein Bauplan, den die umsetzende Agentur übernimmt – und der genau deshalb dokumentiert sein muss:
Und weil ein Content-Modell nie fertig ist – es wächst mit Kampagnen, Ländern und neuen Kanälen – gehört die Pflege dieser Dokumentation dazu. Ein Modell ohne aktuelle Doku ist nach zwei Jahren ein Rätsel.
Erstens: Content Modellierung ist eine Aufgabe für den Projektstart, nicht für die Implementierungsphase. Es ist der teuerste Zeitpunkt für Korrekturen, wenn schon gebaut wird.
Zweitens: Trennen Sie konsequent drei Ebenen – Inhalt, semantische Struktur, kanalspezifische Steuerung. Die ersten beiden gehören ins Modell, die dritte in den Kanal. Das Rich-Text-Feld ist der Ort, an dem diese Trennung am häufigsten scheitert.
Drittens: Das Modell ist herstellerneutral erarbeitbar. Die Systeme sagen dasselbe in anderen Worten. Wer neutral modelliert, kann Systeme besser vergleichen und behält die Bauplan-Hoheit.
Viertens: Saubere Modelle zahlen doppelt ein. Sie machen Inhalte über Kanäle hinweg wiederverwendbar – und gleichzeitig lesbar für die KI-Systeme, die zunehmend zwischen Ihnen und Ihren Kunden stehen.
Fünftens: Sie müssen das nicht selbst können. Awareness reicht für den Anfang. Wichtig ist, dass die Fragen zum richtigen Zeitpunkt gestellt werden – und dass jemand am Tisch sitzt, der die Bärenfallen kennt.
Ja. Jedes CMS hat ein Content-Modell – im klassischen System ist es nur unsichtbar in Templates und Redaktionsgewohnheiten versteckt. Der Unterschied: Im Headless-Projekt müssen Sie es explizit machen. Das ist unbequemer, aber ehrlicher.
Vier Perspektiven gehören an den Tisch: Redaktion (was wird gebraucht), Entwicklung (was ist umsetzbar), Design (welche Komponenten und Varianten gibt es), Marketing (was fordern Kampagnen). Entscheidend ist eine Leitung, die entscheidet – sonst wird das Modell ein Kompromiss aus vier Wunschlisten.
Vor der Implementierung, idealerweise parallel zur oder direkt nach der Systemauswahl. Weil das Modell herstellerneutral erarbeitet werden kann, geht es sogar davor.
Nicht als Posten auf einer Rechnung, sondern als Dauerzustand: Jede neue Seite braucht einen Entwickler. Jeder neue Kanal braucht Nacharbeit. Jeder Relaunch fasst tausende Inhalte an, weil Präsentationslogik im Modell steckt. Das summiert sich schneller, als eine saubere Modellierung im Vorfeld kostet.
KI-Systeme denken in Entities – in klar definierbaren Dingen mit Eigenschaften und Beziehungen. Unternehmen, Personen, Dienstleistungen, Konzepte.
Kann Content an sein Ziel gelangen, wenn er von der Darstellung losgelöst erstellt und verwaltet wird? Er kann! Zumindest dann, wenn das mit einem sorgfältig und richtig eingerichteten Headless CMS geschieht.
Content-Management-Systeme dienen der Erstellung, Verwaltung und Veröffentlichung von Inhalten auf digitalen Kanälen wie Websites, Apps und vielem mehr.
„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.
