Content-Modellierung: Die zentrale Herausforderung für Headless-Projekte und ihre drei Ebenen

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.

Ist die Farbe einer Headline eigentlich Content?

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.

Was ist Content Modellierung überhaupt?

Ein Content-Modell beschreibt, aus welchen Bausteinen Ihre Inhalte bestehen und wie diese zusammenhängen:

• Welche Inhaltstypen gibt es? (Artikel, Produkt, Veranstaltung, Ansprechpartner, FAQ …)

• Aus welchen Feldern besteht jeder Typ? (Titel, Teaser, Autor, Datum, Bild …)

• Wie hängen die Typen zusammen? (Ein Artikel hat einen Autor. Ein Produkt gehört zu einer Kategorie.)

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 zentrale Denkübung: Drei Ebenen sauber trennen

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 1: Der eigentliche Inhalt

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.

Ebene 2: Semantische Steuerung

Inhalt braucht Struktur, um verstanden zu werden – von Menschen und von Maschinen. Die semantische Ebene sagt, was etwas bedeutet, nicht wie es aussieht:

• Das hier ist die Hauptüberschrift, das eine Zwischenüberschrift.

• Das ist eine Aufzählung, das ein Zitat, das eine Tabelle.

• Dieser Absatz ist eine Zusammenfassung, jener eine Handlungsaufforderung.

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.

Ebene 3: Kanalspezifische Funktionssteuerung

Und dann die dritte Kategorie – die heimliche Quelle der meisten Modellierungssünden: Steuerungsinformationen für genau einen Kanal.

• Die Headline soll auf der Website in Orange erscheinen.

• Dieses Teaser-Element soll auf der Startseite zweispaltig laufen.

• Dieser Inhalt soll in der App ausgeblendet, auf der Website gezeigt werden.

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.

Die drei Ebenen im Überblick

Wo die drei Ebenen am häufigsten verschmelzen: im Rich Text

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.

Warum das gerade jetzt wichtiger wird: Maschinen lesen mit

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.

Ein Paradox, das man kennen sollte

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.

Vier Fehler, die Sie kennen sollten

Aus den Best Practices der gängigen Headless-Systeme lässt sich eine Fehlerliste destillieren. Vier davon tauchen besonders zuverlässig auf:

1. “Wir modellieren einen Content-Typ pro Seite - dann bilden wir 1:1 das Design ab.” 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.

2. Zu tiefe Verschachtelung. 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.

3. Alles übersetzbar schalten. 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.

4. Modellieren im Umsetzungsprojekt. 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.

Ist Content Modellierung nicht systemabhängig?

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.

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.

Was am Ende dabei herauskommen sollte

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:

• Baustein-Inventar: alle Felder, Komponenten und Seitentypen aus der Screen-Zerlegung

• Beziehungs- und Verschachtelungsdiagramm: was darf in was, bis zu welcher Tiefe

• Lokalisierungsmatrix: welches Feld ist übersetzbar, welche Sprach-Land-Kombinationen, welche Fallbacks

• Terminologie-Mapping: das neutrale Modell in der Sprache des gewählten Zielsystems

• Namenskonventionen: festgelegt, bevor gebaut wird

• Abnahme: der Punkt, an dem das Modell verbindlich wird

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.

Was hängen bleiben sollte.

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.

Content-Modell vor dem Projektstart? Lassen Sie uns schnacken.

Wir erarbeiten Content-Modelle herstellerneutral – vom Zerlegen Ihrer Screens über die Lokalisierungsstrategie bis zum dokumentierten Bauplan, den Ihre Agentur übernimmt. Weil wir nicht implementieren, haben wir dabei keine andere Agenda als ein Modell, das trägt.

Kontakt zu SUTSCHE

SUTSCHE bietet unabhängige Beratung, Konzeption und Management von CMS-, e-Commerce und Onlinemarketing Projekten. Dabei helfen wir, Anforderungen aufzunehmen, die richtige Lösung auszuwählen und die passenden Dienstleister zu beauftragen.

Oftmals betreuen wir die komplette Durchführung als externe Projektleiter und sorgen für die fachgerechte Umsetzung des Konzeptes. Durch unsere Unabhängigkeit sparen wir unseren Kunden Geld und Zeit, da wir ohne Interessenkonflikt beraten können.

Bei Ihnen steht ein Projekt vor der Tür und Sie wünschen sich einen ersten Austausch. Lassen Sie uns bei einem virtuellen Kaffee unverbindlich über Ihre Herausforderungen und Ziele sprechen.

Kontakt aufnehmen »