Wer Inhalte modelliert, bevor sie geschrieben werden, entscheidet über Konsistenz, Skalierbarkeit und Sichtbarkeit – auf jedem Kanal.
Die wichtigste redaktionelle Entscheidung fällt, bevor jemand den ersten Satz tippt. Sie betrifft nicht die Überschrift, nicht den Teaser, nicht das Bild. Sie betrifft die Frage, was ein Inhalt ist – welche Bestandteile er hat, wie sie zusammenhängen und wo sie enden. Diese Entscheidung heißt Content Modeling.
Content Modeling bedeutet, Inhalte in Typen, Felder und Beziehungen zu zerlegen. Ein Rezept ist kein Fließtext, sondern eine Kombination aus Zutatenliste, Zubereitungsschritten, Nährwertangaben und einem Bild. Ein Produkttext ist kein Absatz, sondern ein Zusammenspiel aus Name, Beschreibung, technischen Daten, Preis und Verfügbarkeit. Das Modell definiert, welche Elemente existieren, welche Regeln gelten und wie sich die Teile zueinander verhalten.
Rosenfeld, Morville und Arango haben dafür den Begriff der Informationsatome geprägt – die kleinsten sinnvollen Einheiten, in die sich Inhalt zerlegen lässt. Wie fein diese Atome geschnitten sind, bestimmt, was mit Inhalten später möglich ist. Es ist eine Vorentscheidung. Genau das macht sie so mächtig und so unsichtbar zugleich.
Content Modeling passiert vor der redaktionellen Arbeit. Es ist die Architektur hinter der Eingabemaske, die Logik hinter dem Dropdown, die Struktur hinter dem Feldsatz. Contentful beschreibt das Modell als Fundament — es bestimme, welche Inhalte die Schnittstellen ausliefern. Wer ein CMS öffnet und Felder sieht, blickt auf das Ergebnis eines Modellierungsprozesses. Meistens, ohne es zu wissen.
Historisch war das anders. Inhalt und Darstellung waren untrennbar. Rosenfeld und Morville nennen das tight coupling. Digitale Systeme lösen diese Kopplung auf. Content wird vom gebundenen Artefakt zur Information, die unabhängig vom Ausgabekanal existiert. Das ist keine technische Spielerei. Es ist die Voraussetzung dafür, dass derselbe Inhalt auf Website, App, Sprachschnittstelle und Print-Katalog funktioniert.
Der Unterschied zur Datenmodellierung in der klassischen Softwareentwicklung ist weniger technisch als perspektivisch. Datenmodelle beschreiben, wie Systeme Informationen speichern und verarbeiten. Content Models beschreiben, wie Menschen Inhalte erstellen, pflegen und ausspielen. Wer nur das eine kennt, baut ein Modell, das technisch korrekt und redaktionell unbenutzbar ist.
Ein gutes Content Model löst ein konkretes Problem: Es macht Inhalte wiederverwendbar, ohne sie beliebig zu machen. Es schafft Konsistenz, ohne Kreativität zu ersticken. Und es denkt in Strukturen, die Menschen wie Maschinen lesen können.
Ein Inhalt, viele Ausgaben. Wiederverwendbarkeit ist kein abstraktes Architekturprinzip – es ist ökonomische Notwendigkeit. Wenn ein Produkttext einmal modelliert ist – mit klar definierten Feldern für Kurzbeschreibung, technische Spezifikation, Anwendungshinweis – dann lässt sich dieser Text auf der Produktseite, im Newsletter, in der App und im Printkatalog verwenden. Ohne Copy-Paste, ohne Doppelpflege, ohne die stille Hoffnung, dass jemand daran denkt, alle Varianten zu aktualisieren. Oatly hat auf dieser Basis 16 Websites in zwei Monaten gelauncht – durch wiederverwendbare Inhaltsbausteine, die redaktionelle Teams unabhängig von Entwicklern einsetzten.
Strukturelle Regeln statt redaktioneller Konventionen. Konsistenz entsteht in den meisten Organisationen durch Styleguides, Absprachen und Hoffnung. Ein Content Model verlagert sie dorthin, wo sie hingehört: in die Struktur. Teasertext auf 160 Zeichen begrenzt. Event-Typ enthält Datum, Ort, Beschreibung. Autorenreferenz ist kein Freitext, sondern Verweis auf ein gepflegtes Objekt. Konsistenz durch Architektur, nicht durch Disziplin.
Maschinenlesbarkeit als Voraussetzung. Strukturierte Inhalte sind nicht nur für Menschen klarer. Sie sind die Grundlage dafür, dass Suchmaschinen, KI-Systeme und APIs Inhalte verstehen und verarbeiten können. Ein Freitextblock mit 500 Wörtern ist für eine Maschine Rauschen. Ein strukturiertes Objekt mit Feldern, Typen und Relationen ist ein Signal. Der Unterschied zeigt sich in der Sichtbarkeit – und in der Anschlussfähigkeit an Systeme, die heute bereits Inhalte kuratieren, empfehlen und generieren.
Kanalagnostik als Designprinzip. 47 Prozent der Unternehmen betreiben bereits zwei bis drei CMS parallel, 27 Prozent sogar vier bis fünf – so der Storyblok State of CMS Report 2024. Kanalagnostik ist in dieser Realität keine Zukunftsvision, sondern Schadensbegrenzung. Ein gutes Content Model ist unabhängig vom Ausgabekanal. Es beschreibt, was ein Inhalt ist, nicht wie er aussieht.
Die ökonomische Realität. Wer nach dem Business Case fragt, bekommt ihn. Forrester hat ihn 2022 für Contentstack berechnet: 295 Prozent ROI. 90 Prozent weniger Time-to-publish. 80 Prozent weniger Entwicklerzeit für Inhalte. Bei Virgin Media O2 entfiel manueller Aufwand von zwanzig Minuten pro Seite. Rakesh Radhakrishnan beziffert die Einsparung im mehrstelligen Millionenbereich. Jedes Jahr.
„Composable-Projekte scheitern selten an Software. Sie scheitern an einer Entscheidung, die ein halbes Jahr vor dem Launch getroffen wird — meist von der falschen Person, in zu kurzer Zeit. Diese Entscheidung heißt Content Modeling. Sie ist der unsichtbarste Hebel im Programm. Und der teuerste, wenn er kippt."
– Hagen Seidel, Geschäftsführer Triplesense Reply, Partner Reply
Diese Zahlen beschreiben nicht den Wert einer Software. Sie beschreiben den Wert einer Struktur. Ein durchdachtes Modell ist ein Skalierungsmultiplikator. Ein fehlendes Modell eine Opex-Steuer, die mit jedem neuen Kanal, jedem neuen Markt, jeder neuen Sprache wächst.
Ein Muster wiederholt sich in fast jeder Organisation: Die Probleme mit Inhalten werden in der Redaktion sichtbar. Sie entstehen in der Architektur. Wer die typischen Fehler kennt, vermeidet sie. Wer sie ignoriert, zahlt exponentiell mehr für jede spätere Korrektur.
Der erste und häufigste Fehler ist Seitendenken. Inhalte werden als Seiten modelliert, nicht als Objekte. Eine Homepage ist dann kein Zusammenspiel aus Hero-Element, Teaser-Karussell und Eventliste, sondern ein monolithischer Block mit Feldern wie „Headertext", „Mittlerer Bereich" und „Footer-Inhalt". Das funktioniert genau so lange, wie sich niemand wünscht, denselben Inhalt an einer zweiten Stelle zu verwenden. Air France-KLM hat dieses Problem jahrelang erlebt. Lydie Rodrigues, Solution Manager for Content, beschrieb, dass eine einzige Wortänderung bis zu zwei Wochen dauern konnte. Zwei Wochen für ein Wort. Nicht wegen schlechter Redakteure, sondern wegen eines Modells, das Inhalte an Seiten kettete statt sie als eigenständige Objekte zu behandeln. Die Lösung: Inhalte in kleinere Bausteine zerlegen – wie Legosteine, die sich frei kombinieren lassen. Die projizierten Effekte: 50 Prozent niedrigere Entwicklungskosten, 20 Prozent weniger Service-Line-Calls, 15 Prozent weniger Übersetzungskosten.
Der zweite Fehler ist Überstrukturierung. Zu viele Felder, zu feine Granularität, zu wenig Spielraum. Ein Content-Typ mit 40 Pflichtfeldern ist kein Modell, sondern ein Formular. Die Eingabemaske wird zur Bürokratie, die redaktionelle Geschwindigkeit bricht ein, und die Akzeptanz im Team sinkt auf null. 44 Prozent der Befragten im Storyblok State of CMS Report 2024 benennen die Schwierigkeit nicht-technischer Nutzer, eigenständig Inhalte zu ändern, als zentrale Herausforderung. Das ist kein UX-Problem. Es ist ein Modellierungs-Problem.
Der dritte Fehler ist das Gegenteil: Unterstrukturierung. Ein Rich-Text-Feld, in das alles passt. Überschriften, Bilder, Tabellen, eingebettete Videos – alles in einem einzigen Freitext-Blob. Die Eingabe fühlt sich frei an. Aber jede Automatisierung, jede Wiederverwendung, jede maschinelle Auswertung scheitert an der fehlenden Struktur. Der Inhalt existiert, aber er ist gefangen in einem Format, das nur ein Mensch auf genau einem Kanal lesen kann.
Der vierte – und strukturell schwerwiegendste – Fehler ist Modellierung ohne Redaktion. In vielen Organisationen treffen Entwicklungsteams die Entscheidungen über Content-Typen und Feldstrukturen. Nicht aus Böswilligkeit, sondern weil sie die Systeme bauen und jemand die Felder definieren muss. Die Storyblok-Erhebung zeigt das Problem in einer Zahl: 87 Prozent der Befragten sind technische Nutzer. Die redaktionelle Perspektive ist unterrepräsentiert – in der Forschung wie in der Praxis. Das Ergebnis kennt jeder Content Manager: Ein CMS, das technisch sauber ist und redaktionell nicht funktioniert. Felder, die niemand versteht. Strukturen, die den Workflow behindern statt ihn zu tragen. Fehlende Zusammenarbeit führt – so der Storyblok-Report – zu ungeordneten Inhalten, ineffizienten Abläufen und Ressourcenverschwendung.
Der Business Case des Fehlers ist simpel: Refactoring ist exponentiell teurer als initiale Planung. Wer ein Content Model nach dem Launch umbauen muss, migriert Daten, bricht Schnittstellen, schult Teams neu und verliert Monate. 41 Prozent der Befragten halten den Preis für zu hoch, 38 Prozent finden ihr System zu kompliziert oder zu entwicklerabhängig. Beides sind Symptome desselben Problems: Modelle, die ohne die Menschen gebaut wurden, die täglich mit ihnen arbeiten.
Wenn Modellierung der Ort ist, an dem die wichtigsten redaktionellen Entscheidungen fallen, dann muss dort auch redaktionelle Kompetenz vertreten sein. Das klingt offensichtlich. In der Praxis ist es die Ausnahme.
Die Rolle, die diese Lücke schließen soll, heißt Content Architect. Keine technische Rolle im engeren Sinne, keine rein redaktionelle. Ein Content Architect versteht, wie Inhalte entstehen, wie sie sich verändern und wo sie ausgespielt werden. Er oder sie übersetzt redaktionelle Bedürfnisse in strukturelle Entscheidungen – und strukturelle Einschränkungen in redaktionelle Möglichkeiten. Andy Fitzgerald beschreibt diesen Ansatz in „Structured Content Design" als Content-out-Prozess: nicht vom Screen-Template zum Inhalt, sondern vom Inhalt zur Struktur zur Darstellung. Inhalte, die so modelliert sind, seien maschinenlesbar und besser vorbereitet auf sprach- und KI-gesteuerte Interfaces.
Entscheidend ist, wer am Tisch sitzt. Contentful empfiehlt Arbeitssitzungen mit jedem beteiligten Team und iteratives Feedback – Entwickler planen und bauen, nicht-technische Kolleginnen und Kollegen testen und melden zurück. Storyblok formuliert es direkter: Designer, Redakteure und Entwickler sollten gemeinsam am Modell arbeiten. Das ist keine Forderung nach Demokratisierung. Es ist die Erkenntnis, dass ein Content Model nur funktioniert, wenn es aus vier Perspektiven gleichzeitig gedacht wird: der redaktionellen (Was brauchen wir?), der gestalterischen (Wie wird es dargestellt?), der technischen (Wie wird es gebaut?) und der strategischen (Wie wird es gefunden und verwertet?).
„Die besten Content Models entstehen nicht im Sprint-Backlog, sondern im Gespräch zwischen Redaktion, UX und Entwicklung — bevor das erste Feld benannt ist. In Briefings sehe ich oft das Gegenteil: Modellierung läuft als reine Engineering-Aufgabe. Was dabei entsteht, korrigieren später andere im Interface — was im Modell hätte gelöst werden müssen."
– Wiebke Wefer, Head of Composable Business Solutions, Triplesense Reply
Modelle sind keine statischen Artefakte. Inhalte verändern sich – neue Formate kommen hinzu, bestehende Typen werden erweitert, Anforderungen aus SEO oder Personalisierung erzeugen neue Felder. Iteratives Modellieren heißt: regelmäßig prüfen, anpassen, weiterentwickeln. Nicht als großes Refactoring-Projekt, sondern als Teil der redaktionellen Praxis. Wer ein Modell einmal baut und nie wieder anfasst, hat ein Denkmal errichtet – kein Werkzeug.
Strukturierte Inhalte sind die Voraussetzung dafür, dass Maschinen Inhalte nicht nur finden. Sondern verstehen.
Der sichtbarste Standard dafür ist Schema.org — auf über 45 Millionen Domains im Einsatz, mit über 450 Milliarden Objekten weltweit (Stand 2024). Schema.org stellt ein Vokabular bereit, das Inhalte semantisch auszeichnet: Ein Artikel ist ein Artikel, ein Event ein Event, ein Produkt hat Preis, Hersteller, Bewertung. Google koppelt die Berechtigung für Rich Results an korrektes Markup, JSON-LD ist die empfohlene Implementierung.
Das allein wäre schon relevant. Aber die eigentliche Verschiebung liegt tiefer.
KI-Systeme – von Sprachmodellen über Empfehlungsalgorithmen bis zu autonomen Agenten – arbeiten besser mit strukturierten Inhalten. Sanity beschreibt unter dem Konzept „Agent Context", wie KI-Agenten Inhalte über standardisierte Protokolle lesen und abfragen können. Das System ist schema-bewusst: Agenten können Felder abfragen, Referenzen folgen und semantisch suchen. Ein Content Model wird damit zur Schnittstelle zwischen menschlich erstellten Inhalten und maschineller Verarbeitung.
Die Forschung bestätigt das. Ein 2025 auf arXiv veröffentlichtes Preprint zu Knowledge-Graph-gestütztem Retrieval dokumentiert messbare Effekte: ROUGE-L stieg von 41,2 auf 46,9, FactScore um 13,6 Prozentpunkte. Übersetzt: Strukturierte Inhalte machen KI-Antworten relevanter und faktisch korrekter. Wer ohne Modell arbeitet, überlässt der Maschine das Raten.
Taxonomien und Knowledge Graphs sind die Weiterentwicklung des Content Models. Ein Content Model beschreibt, was ein Inhalt ist. Taxonomien beschreiben, wovon er handelt. Knowledge Graphs beschreiben, wie er mit anderen Inhalten und Konzepten zusammenhängt. Zusammen bilden sie ein semantisches Netz, das weit über klassische Suchmaschinenoptimierung hinausgeht – hin zu einer Welt, in der Maschinen nicht nach Zeichenketten suchen, sondern nach Bedeutung.
Für Content Manager heißt das: Felder, Taxonomien, Referenzen sind keine lästige Ordnungspflicht. Sie sind die Grundlage dafür, wie sichtbar, verwertbar und zukunftsfähig Inhalte in einer maschinengestützten Welt sind.
Diese Serie heißt „Content als Betriebssystem". Die Grundidee, kurz: Inhalte sind nicht die hübsche Oberfläche einer Organisation. Sie sind ihre Infrastruktur. Infrastruktur funktioniert nur, wenn jemand die Leitungen pflegt — nicht die Fassade.
Content Modeling ist eine dieser Leitungen. Unsichtbar. Entscheidend. Chronisch unterbesetzt.
Wer bis hierhin gelesen hat, kennt das Problem — oder ahnt es. Die nächsten Teile gehen weiter: was aus Design wird, wenn Inhalte über Schnittstellen fließen, und wer eigentlich zuerst liest, wenn es kein Mensch mehr ist. Wird nicht gemütlicher. Wird klarer.
Falls Sie diesen Artikel jetzt schließen und denken, „das müsste mal jemand bei uns angehen": Sie sind jemand bei uns.
