Content-Modell entwickeln: Von Seiten zu strukturierten Inhalten

Viele Websites sind zunächst nach Seiten organisiert: Startseite, Kategorie, Detailseite. Das funktioniert, solange Inhalte hauptsächlich an einem Ort erscheinen und sich selten wiederholen. Sobald dieselben Informationen in mehreren Seitentypen, Filtern, Tools oder Kanälen gebraucht werden, wird die Seitenstruktur zum Engpass. Dann stellt sich die Frage, wie sich Inhalte so modellieren lassen, dass sie redaktionell verständlich bleiben und zugleich zuverlässig weiterverarbeitet werden können.

Dieser Beitrag richtet sich an Geschäftsführung, Produktverantwortliche und technische Leitung, die eine gewachsene Website oder Content-Plattform weiterentwickeln. Die zentrale Entscheidung lautet nicht, welches CMS zuerst ausgewählt werden soll. Entscheidend ist, welche Dinge das System abbilden muss, wie sie zusammenhängen und welche Regeln für gültige Inhalte gelten. Aus diesen Antworten leiten Sie Seitentypen und technische Umsetzung ab.

Kurz gesagt

Entwickeln Sie ein Content-Modell aus den fachlichen Dingen und Beziehungen Ihres Angebots – nicht aus einer Liste vorhandener Seiten. Legen Sie für jede Entität fest, welche Felder erforderlich sind, welche Inhalte auf andere Einträge verweisen und welche Regeln die Eingaben erfüllen müssen. Leiten Sie daraus Seitentypen und Oberflächen ab. Erst danach lässt sich sinnvoll entscheiden, ob ein vorhandenes CMS genügt oder ein stärker typisiertes Content-System nötig ist.

Ausgangslage

Eine Seite ist eine Darstellung. Ein Inhalt ist ein wiederverwendbarer Datensatz mit einer fachlichen Bedeutung. Werden beide Begriffe gleichgesetzt, landet vieles in langen Textfeldern oder als Sonderfall in einer Vorlage. Eine Pflanze mit Merkmalen, passende Probleme und regionale Eignung können dann beispielsweise in einem Fließtext stehen, obwohl Nutzerinnen und Nutzer diese Informationen später filtern oder an mehreren Stellen anzeigen sollen.

Das erschwert Änderungen. Ein Feld muss an mehreren Stellen angepasst werden, Beziehungen bleiben nur im Text erkennbar und Redaktionen wissen nicht immer, welche Angaben verbindlich sind. Auch technische Funktionen wie Suche, Filter oder ein Rechner können strukturierte Werte nicht zuverlässig verwenden, wenn wichtige Informationen nur als Freitext vorliegen.

Ein Modell löst diese Probleme nicht automatisch. Es macht aber sichtbar, welche Inhalte das System kennt, welche Regeln gelten und wo Abhängigkeiten bestehen. Die Content-Architektur verbindet diese Modellierung mit Informationsarchitektur, URL-Struktur und Sichtbarkeit.

Seiten zuerst zu planen hat Grenzen

Seitentypen bleiben wichtig: Sie bestimmen, wie Inhalte dargestellt und erschlossen werden. Sie sind aber nicht immer die beste Ausgangsbasis für die Datenstruktur. Wenn eine Entität auf mehreren Seiten oder in mehreren Funktionen auftaucht, sollte sie nicht für jede Darstellung neu angelegt werden.

Umgekehrt braucht nicht jedes Textfragment einen eigenen Datensatz. Eine kurze Einleitung, die nur auf einer einzelnen Seite vorkommt, kann ein Feld dieser Seite sein. Ein eigenständiger Inhaltstyp lohnt sich, wenn ein Inhalt eigene Merkmale, Beziehungen, redaktionelle Regeln oder wiederverwendbare Darstellungen hat.

Entscheidungskriterien

Ein tragfähiges Modell entsteht schrittweise. Halten Sie die fachlichen Entscheidungen fest, bevor Sie sie in ein CMS, eine Datenbank oder ein Frontend übertragen.

1. Entitäten identifizieren

Sammeln Sie zunächst die Dinge, über die Ihre Organisation dauerhaft Informationen verwaltet. Fragen Sie nicht nur, welche Seiten es gibt, sondern welche fachlichen Objekte eine eigene Identität haben.

Mögliche Entitäten sind Produkte, Personen, Standorte, Leistungen, Veranstaltungen oder redaktionelle Beiträge. Ein nützlicher Test: Muss dieses Ding unabhängig von einer bestimmten Seite gepflegt, gefunden, verknüpft oder wiederverwendet werden? Wenn ja, spricht das für eine eigene Entität.

Trennen Sie dabei klar benannte Objekte von Themen und Merkmalen. Eine Region kann ein eigener Inhalt sein, wenn sie eine eigene Beschreibung und URL erhält. Wenn sie lediglich einen Wert zur Einordnung darstellt, reicht möglicherweise ein kontrolliertes Feld oder eine Taxonomie.

2. Felder nach Zweck und Verbindlichkeit festlegen

Definieren Sie pro Entität, welche Angaben benötigt werden. Unterscheiden Sie dabei:

• Identität: Titel, Kennung oder eindeutiger Schlüssel.
• fachliche Merkmale: Werte, die Suche, Filter oder Entscheidungen unterstützen.
• redaktionelle Angaben: Beschreibung, Bildtext oder ergänzende Hinweise.
• Steuerungsfelder: Status, Gültigkeit, Quelle oder Prüfvermerk.

Ein Feld sollte einen klaren Zweck haben. Fragen Sie, wer es pflegt, wofür es genutzt wird und welche Eingabe gültig ist. „Informationen“ oder „Sonstiges“ sind meist Warnzeichen: Sie verstecken verschiedene Angaben in einem Feld, statt sie verständlich zu trennen.

Legen Sie außerdem fest, welche Felder erforderlich sind, welche leer bleiben dürfen und welche Wertebereiche gelten. Ein Feld für eine Zahl sollte nicht dieselben Eingaben akzeptieren wie ein beschreibender Text. Wo Werte aus einer begrenzten Auswahl stammen, sollten Sie die Auswahl kontrollieren, statt beliebige Schreibweisen zuzulassen.

3. Beziehungen ausdrücklich modellieren

Viele Inhalte erhalten ihre Bedeutung erst durch Verknüpfungen. Ein Produkt gehört zu einer Kategorie, eine Veranstaltung findet an einem Ort statt, ein Beitrag behandelt ein Thema. Solche Beziehungen sollten nicht nur in Texten oder URLs angedeutet werden.

Entscheiden Sie für jede Beziehung:

• Welche Entität verweist auf welche andere?
• Ist die Beziehung verpflichtend oder optional?
• Kann ein Eintrag auf einen oder auf mehrere andere verweisen?
• Muss die Beziehung in beide Richtungen gepflegt oder nur angezeigt werden?
• Was passiert, wenn ein verknüpfter Eintrag gelöscht oder archiviert wird?

Diese Fragen beeinflussen Redaktion, Datenqualität und technische Umsetzung. Eine Verknüpfung auf einen konkreten Datensatz ist meist belastbarer als eine lose Textangabe, wenn das System später daraus Listen, Filter oder Navigation erzeugen soll.

4. Seitentypen aus Inhalt und Nutzung ableiten

Erst wenn Entitäten, Felder und Beziehungen klarer sind, planen Sie die Darstellungen. Eine Entität braucht nicht automatisch eine eigene öffentliche Seite. Manche Datensätze dienen nur als Filterwerte oder interne Referenzen. Andere können auf einer Übersichtsseite, einer Detailseite und in einem Rechner auftauchen.

Leiten Sie Seitentypen aus zwei Fragen ab: Welche Informationen benötigt eine Person in einer bestimmten Situation? Und welche Datensätze kann das System dafür zuverlässig zusammenstellen? So lassen sich Inhalte von ihrer Darstellung trennen, ohne die Anforderungen an die Oberfläche aus den Augen zu verlieren.

5. Regeln und Validierung definieren

Ein Modell wird erst belastbar, wenn das System ungültige oder unvollständige Daten erkennen kann. Beschreiben Sie, welche Werte erlaubt sind, welche Beziehungen auf existierende Einträge zeigen müssen und welche Angaben zusammengehören.

Validierung kann im CMS, beim Import oder in einer Build-Pipeline stattfinden. Wichtig ist, dass Fehler früh genug sichtbar werden und verständlich sind. Ein fehlender Pflichtwert sollte nicht erst auf einer veröffentlichten Seite auffallen. Bei umfangreichen oder automatisierten Datenflüssen empfiehlt sich außerdem, den Zeitpunkt und die Quelle einer Angabe nachvollziehbar zu halten.

Vorgehen: Vom Bestand zum Modell

Bestehende Inhalte untersuchen

Erfassen Sie typische Seiten, wiederkehrende Angaben, Listen, Filter und interne Werkzeuge. Nehmen Sie auch Ausnahmen auf. Dabei geht es nicht darum, jede historische Abweichung dauerhaft abzubilden, sondern Muster und fachliche Anforderungen zu erkennen.

Sprechen Sie mit den Personen, die Inhalte pflegen und nutzen. Eine Angabe, die im Frontend nebensächlich wirkt, kann für Beratung, Freigabe oder Datenimport entscheidend sein. Umgekehrt muss nicht jedes bestehende Feld übernommen werden.

Ein Modell skizzieren und prüfen

Zeichnen Sie Entitäten als benannte Objekte, Felder als Eigenschaften und Beziehungen als Verbindungen. Prüfen Sie das Modell anschließend mit konkreten Aufgaben: Kann eine Redaktion einen neuen Eintrag anlegen? Kann die Suche passende Inhalte finden? Lässt sich eine Liste ohne doppelte Pflege bilden? Was passiert, wenn ein Datensatz noch keine vollständigen Angaben hat?

Ein Modell muss dabei weder maximal normalisiert noch maximal flexibel sein. Es soll die tatsächlichen Abläufe abbilden und Änderungen ermöglichen, ohne unnötige Sonderfälle einzuführen. Dokumentieren Sie offene Entscheidungen, damit Annahmen nicht unbemerkt zu Systemregeln werden.

Schema im System umsetzen

Bei Astro Content Collections können Schemas Inhalte typisieren und Eingaben beim Build prüfen. Das folgende Beispiel zeigt eine Pflanzen-Entität mit Referenzen auf andere Collections:

import { defineCollection, reference, z } from 'astro:content';

const plants = defineCollection({
  schema: z.object({
    title: z.string().min(1),
    scientificName: z.string().optional(),
    problems: z.array(reference('problems')).default([]),
    tasks: z.array(reference('tasks')).default([]),
    regions: z.array(reference('regions')).default([]),
  }),
});

export const collections = {
  plants,
};

Die Referenzen verbinden einen Pflanzeneintrag mit Einträgen in den Collections für Probleme, Aufgaben und Regionen. Dadurch prüft das Schema nicht nur Feldtypen, sondern beschreibt auch Beziehungen. Welche Felder tatsächlich erforderlich sind, sollte sich aus dem Redaktionsprozess und der fachlichen Nutzung ergeben.

Praxisbeispiel

Beim Projekt Garten 1x1 wurde eine WordPress-Seite nach Astro migriert. Das Content-Modell umfasst Collections für Pflanzen, Probleme, Aufgaben, Bereiche, Regionen und Ziele; die Inhalte werden mit Content Collections und Zod-Schema typisiert. Zum Angebot gehören mehrere hundert Pflanzenprofile, eine Suche mit Pagefind und ein Gartenrechner im Browser.

Das Beispiel zeigt, warum eine reine Seitenliste für solche Inhalte nicht ausreicht: Verschiedene fachliche Inhaltstypen müssen getrennt gepflegt und für unterschiedliche Funktionen nutzbar sein. Welche konkrete Beziehung zwischen zwei Collections erforderlich ist, hängt davon ab, welche Inhalte und Abläufe das System tatsächlich unterstützen soll.

Typische Fehler

• Vorlagen als Datenmodell behandeln: Eine Detailseite beschreibt die Darstellung, aber nicht automatisch die fachliche Struktur dahinter.
• Zu früh Felder sammeln: Ohne klaren Zweck entstehen überladene Formulare und Angaben, die niemand zuverlässig pflegt.
• Alles als Freitext speichern: Freitext ist für redaktionelle Beschreibungen sinnvoll, aber für Filter und eindeutige Beziehungen oft ungeeignet.
• Jedes Feld kontrollieren wollen: Strenge Regeln helfen bei wichtigen Daten. Für Inhalte, die bewusst offen bleiben, können sie unnötige Pflegehürden schaffen.
• Zu viele Entitäten einführen: Nicht jedes wiederkehrende Wort und nicht jede Textpassage braucht einen eigenen Datensatz.
• Beziehungen nur visuell denken: Eine Verlinkung auf einer Seite ist nicht automatisch eine gepflegte, überprüfbare Datenbeziehung.
• Migrationen ausblenden: Bestehende Inhalte müssen auf das neue Modell abgebildet werden. Unklare oder fehlende Werte brauchen eine bewusste Behandlung.
• Validierung erst am Ende ergänzen: Ohne frühe Prüfungen sammeln sich Fehler im Bestand und werden beim Umstieg teuer sichtbar.

Empfehlung

Wenn Inhalte überwiegend redaktionelle Einzelstücke sind und kaum wiederverwendet werden, beginnen Sie mit einer schlanken Seiten- und Feldstruktur. Wenn dieselben Objekte in Listen, Filtern oder mehreren Darstellungen vorkommen, modellieren Sie diese als eigenständige Entitäten mit klaren Beziehungen.

Wenn Inhalte aus mehreren Quellen zusammengeführt, regelmäßig aktualisiert oder von verschiedenen Rollen gepflegt werden, definieren Sie zusätzlich Herkunft, Status und Freigaberegeln. Wenn das gewählte CMS Beziehungen und Validierung nicht zuverlässig abbilden kann, prüfen Sie eine andere Architektur oder ergänzende technische Komponenten. Die Entscheidung sollte aus dem Modell folgen – nicht aus einer Feature-Liste.

Checkliste

• Haben wir die fachlichen Entitäten unabhängig von vorhandenen Seiten benannt?
• Ist für jedes Feld klar, wer es pflegt und wofür es genutzt wird?
• Sind Pflichtfelder, optionale Felder und erlaubte Werte festgelegt?
• Sind Beziehungen zwischen Entitäten explizit beschrieben?
• Ist geklärt, ob ein Inhalt eine eigene öffentliche Seite benötigt?
• Lassen sich typische Suche-, Filter- und Redaktionsaufgaben mit dem Modell abbilden?
• Prüft das System ungültige Felder und nicht auflösbare Referenzen?
• Ist dokumentiert, wie bestehende Inhalte migriert und unvollständige Daten behandelt werden?
• Haben Redaktion und Technik das Modell anhand konkreter Fälle geprüft?

Häufige Fragen

Ist ein Content-Modell dasselbe wie eine Sitemap?

Nein. Eine Sitemap ordnet Seiten und Navigation. Ein Content-Modell beschreibt Inhalte, ihre Felder und Beziehungen. Beide sollten aufeinander abgestimmt sein, erfüllen aber unterschiedliche Aufgaben.

Muss jede Entität eine eigene Seite bekommen?

Nein. Eine Entität kann ausschließlich für Suche, Filter oder interne Verknüpfungen gebraucht werden. Eine eigene Seite ist sinnvoll, wenn sie eigenständige Informationen für Nutzerinnen und Nutzer bereitstellt.

Wann lohnt sich ein Schema mit Validierung?

Sobald fehlerhafte oder unvollständige Angaben Funktionen, Veröffentlichungen oder Datenimporte beeinträchtigen können. Umfang und Strenge der Validierung sollten dem Risiko und dem Pflegeprozess entsprechen.

Kann ich ein bestehendes Modell nachträglich ändern?

Ja, aber Änderungen können bestehende Einträge, Importe und Darstellungen betreffen. Prüfen Sie vorab, welche Daten migriert werden müssen und wie die Änderung kontrolliert getestet wird.

Weiterführend

• Content-Architektur: Inhalte, Daten und SEO organisieren
• SEO-Datenmodellierung: Inhalte, URLs und Links verbinden
• Datenmodelle statt Plugin-Stapel
• Astro für Content-Sites

Weiterführende Quellen

Diese offiziellen Dokumentationen und Standards vertiefen die behandelten Themen.

• Astro: Content Collections