Strukturierte Daten für Content-Plattformen: Datenmodell statt Markup

Strukturierte Daten sind für Content-Plattformen mehr als ein JSON-LD-Snippet. Entscheidend ist, ob die Informationen im System sauber modelliert sind und sich daraus konsistente Ausgaben für Website, Suche, API und strukturierte Daten erzeugen lassen. Das betrifft Unternehmen, deren Inhalte aus mehreren Quellen kommen, viele Seitentypen umfassen oder von unterschiedlichen Teams gepflegt werden. Wird Schema.org direkt in einzelne Templates geschrieben, entstehen leicht doppelte Logik und widersprüchliche Angaben. Die bessere Grundlage ist ein internes Datenmodell, das Entitäten, Beziehungen, Quellen und Veröffentlichungsregeln festlegt. Schema.org dient dann als Ausgabeformat. Dieser Beitrag zeigt, welche Entscheidungen dafür nötig sind, wie Sie Markup sinnvoll abbilden und welche Prüfungen vor und nach der Veröffentlichung dazugehören.

Kurz gesagt

Modellieren Sie Inhalte und Entitäten zuerst im eigenen System; verwenden Sie Schema.org anschließend als strukturierte Ausgabe. Das Markup muss zu den sichtbaren Inhalten passen und darf keine Information behaupten, die intern nicht verlässlich gepflegt wird. Legen Sie für jeden Seitentyp fest, welche Felder erforderlich sind, woher sie kommen und wie sie validiert werden. Strukturierte Daten können Suchmaschinen helfen, Inhalte einzuordnen, garantieren aber weder besondere Suchergebnisse noch bessere Rankings.

Ausgangslage

Eine Content-Plattform bildet selten nur Artikel ab. Sie kann Produkte, Orte, Organisationen, Personen, Themen, Quellen oder Beziehungen zwischen diesen Entitäten enthalten. Dieselbe Information wird oft an mehreren Stellen verwendet: auf einer Detailseite, in einer Suche, in einem Export oder in einer API.

Wenn strukturierte Daten erst im Frontend ergänzt werden, ist das Datenmodell häufig bereits entschieden – oder es existiert gar keines. Entwicklerinnen und Entwickler greifen dann auf Seitentitel, Taxonomien oder benutzerdefinierte Felder zurück und setzen sie direkt in Schema.org-Eigenschaften um. Das kann für einen einzelnen Seitentyp funktionieren. Bei mehreren Inhaltstypen und Quellen wird es jedoch schwierig, abweichende Begriffe und Beziehungen sauber zu behandeln.

Schema.org löst dieses Modellierungsproblem nicht. Es stellt ein gemeinsames Vokabular für die Beschreibung von Dingen bereit. Welche Entitäten eine Plattform führt und welche Informationen für das Unternehmen verbindlich sind, muss das interne Modell festlegen. Eine vertiefte Betrachtung der Grundlage bietet Content-Modell entwickeln; der Zusammenhang zwischen Daten, URLs und SEO ist im Beitrag SEO-Datenmodellierung beschrieben.

Entscheidungskriterien

Bevor Sie Schema.org-Typen und Eigenschaften auswählen, sollten Sie folgende Punkte klären:

1. Welche Entität wird beschrieben?

Bestimmen Sie, ob eine Seite einen Artikel, ein Produkt, einen Ort oder eine Organisation beschreibt – oder mehrere miteinander verbundene Dinge. Die URL allein ist keine Entität. Eine Übersichtsseite kann beispielsweise viele Datensätze listen; sie sollte nicht so ausgezeichnet werden, als beschreibe sie nur einen einzelnen Eintrag.

2. Was ist die verbindliche Datenquelle?

Für jedes Feld braucht es eine Quelle und eine Zuständigkeit. Ein Name kann redaktionell gepflegt, aus einer externen Datenquelle übernommen oder aus anderen Feldern abgeleitet werden. Wenn dieselbe Information mehrfach manuell eingetragen wird, steigt das Risiko von Abweichungen. Legen Sie fest, welcher Wert maßgeblich ist und wie Änderungen übernommen werden.

3. Welche Beziehungen müssen erhalten bleiben?

Eine Entität steht oft in Beziehung zu anderen: ein Artikel zu einer Autorin, ein Ort zu einer Region oder ein Produkt zu einer Marke. Entscheiden Sie, ob diese Beziehung im Datenmodell eindeutig gespeichert ist. Wenn sie nur aus Text oder URL-Strukturen abgeleitet wird, kann sie bei Umbenennungen oder Migrationen verloren gehen.

4. Welche Felder sind erforderlich und belastbar?

Nicht jedes interne Feld gehört in das Markup. Geben Sie nur Informationen aus, die zutreffend, ausreichend gepflegt und für die beschriebene Entität relevant sind. Unbekannte Werte sollten nicht mit plausibel klingenden Standardangaben gefüllt werden. Wo Felder optional sind, muss das System fehlende Werte sauber behandeln.

5. Wo wird die Ausgabe erzeugt?

Bei einer klassischen Website kann das Rendering im CMS erfolgen. Bei einer API-first- oder Headless-Architektur kann die Ausgabe im Frontend liegen. Legen Sie fest, welche Komponente für die Abbildung auf Schema.org verantwortlich ist. Mehrere unabhängige Stellen, die dasselbe Markup erzeugen, erschweren die Kontrolle.

6. Wie wird Konsistenz geprüft?

Prüfen Sie nicht nur, ob JSON-LD syntaktisch gültig ist. Entscheidend ist auch, ob die Werte mit dem sichtbaren Inhalt und dem internen Datensatz übereinstimmen. Für jede Ausgabe sollten sich Herkunft, Aktualität und gegebenenfalls Freigabestatus nachvollziehen lassen.

Vom Datenmodell zur Schema.org-Ausgabe

Ein robustes Vorgehen trennt drei Ebenen:

1. Internes Modell: Entitäten, Felder, Beziehungen, Quellen und redaktionelle Regeln.
2. Abbildung: Zuordnung interner Felder zu passenden Schema.org-Typen und -Eigenschaften.
3. Ausgabe und Prüfung: JSON-LD im Frontend sowie technische und inhaltliche Validierung.

Die Abbildung ist keine bloße Übersetzung von Feldnamen. Ein internes Feld wie region_id kann eine Beziehung zu einer Region darstellen. Je nach Inhalt und Seitenzweck kann diese Beziehung in Schema.org anders ausgedrückt werden oder für die konkrete Ausgabe entfallen. Dokumentieren Sie solche Entscheidungen, damit sie bei neuen Templates nicht jedes Mal neu getroffen werden.

Das folgende vereinfachte Beispiel zeigt eine touristische Attraktion als Entität. Der Name und die Beschreibung sind illustrative Werte, keine Angaben aus einem konkreten Projekt. In einem realen System würden sie aus freigegebenen Feldern des Datenmodells stammen.

{
  "@context": "https://schema.org",
  "@type": "TouristAttraction",
  "@id": "https://example.com/beispiel-ausflugsziel",
  "name": "Beispiel-Ausflugsziel",
  "description": "Ein beispielhafter Eintrag für eine touristische Attraktion.",
  "additionalProperty": {
    "@type": "PropertyValue",
    "propertyID": "Datenstatus",
    "value": "Illustratives Beispiel"
  }
}

Im produktiven Einsatz sollte die @id stabil auf die konkrete Entität verweisen und mit der kanonischen URL abgestimmt sein. Die Ausgabe sollte nur Felder enthalten, die in der jeweiligen Quelle vorhanden und für die Entität freigegeben sind. Interne Verwaltungsfelder gehören nicht automatisch in das Markup.

Validierung auf mehreren Ebenen

Eine verlässliche Prüfung umfasst mindestens vier Schritte:

• Syntax: Ist das JSON-LD gültiges JSON und technisch korrekt eingebunden?
• Vokabular: Sind Typen und Eigenschaften im Schema.org-Vokabular passend verwendet?
• Inhalt: Stimmen die ausgezeichneten Angaben mit dem sichtbaren Inhalt und dem Datensatz überein?
• Betrieb: Bleibt die Ausgabe nach Änderungen am Datenmodell, Template oder Importprozess korrekt?

Werkzeuge zur Prüfung strukturierter Daten können technische Fehler und bestimmte Suchdarstellungsanforderungen sichtbar machen. Sie ersetzen aber nicht die fachliche Prüfung, ob eine Auszeichnung den tatsächlichen Inhalt beschreibt. Prüfen Sie repräsentative Seitentypen und Grenzfälle: fehlende Felder, mehrere zugehörige Entitäten, veraltete Quellen und zurückgezogene Inhalte.

Typische Fehler

• Schema.org als Datenmodell behandeln: Das Vokabular ersetzt keine Definition der internen Entitäten und Zuständigkeiten.
• Markup pro Template improvisieren: Ähnliche Seitentypen erhalten dadurch oft unterschiedliche oder widersprüchliche Ausgaben.
• Alle verfügbaren Felder ausgeben: Mehr Markup bedeutet nicht automatisch bessere Verständlichkeit. Irrelevante oder unbelegte Angaben schwächen die Konsistenz.
• Unsichtbare Inhalte auszeichnen: Das Markup sollte keine Informationen behaupten, die Nutzerinnen und Nutzer auf der Seite nicht nachvollziehen können.
• Nur die Syntax prüfen: Valides JSON kann fachlich falsche Werte enthalten.
• Beziehungen aus URLs ableiten: URLs können sich ändern. Beziehungen gehören, wenn sie wichtig sind, ins Datenmodell.
• Änderungen ohne Regressionstest ausrollen: Eine Anpassung an einem gemeinsamen Template kann viele Seitentypen gleichzeitig betreffen.

Praxisbeispiel

Bei erlebe-nrw werden rund 8.300 Ausflugsziele aus mehreren Datenquellen verarbeitet. Die Pipeline führt Daten über SQLite und JSONL in eine Astro-Plattform; Slugs sind eingefroren, und bei jeder Angabe werden Quelle und Stand geführt. Für strukturierte Daten ist daran vor allem das Prinzip relevant: Entitäten und Herkunft müssen im Verarbeitungsschritt nachvollziehbar bleiben, bevor sie in eine Seitenausgabe überführt werden. Die öffentliche Seite kann so eine kontrollierte Darstellung des Datenbestands erzeugen, statt Markup unabhängig von der Datenpipeline zu pflegen. Mehr zum Projekt: erlebe-nrw.

Empfehlung

• Wenn Ihre Website wenige, stabile Inhaltstypen hat und ein CMS die Felder sauber verwaltet, bilden Sie die nötigen Schema.org-Ausgaben kontrolliert in den Templates ab.
• Wenn mehrere Seitentypen dieselben Entitäten oder Beziehungen verwenden, definieren Sie zuerst ein gemeinsames Datenmodell und dokumentieren Sie die Zuordnung zu Schema.org.
• Wenn Daten aus mehreren Quellen stammen, speichern Sie Herkunft und Aktualität mit und legen Sie Regeln für Konflikte und fehlende Angaben fest.
• Wenn dieselben Daten über Website, API und weitere Ausgabekanäle genutzt werden, trennen Sie internes Modell und Ausgabeformat. Vermeiden Sie, Schema.org zum einzigen Ort zu machen, an dem die Bedeutung eines Feldes festgelegt ist.
• Wenn sich die Anforderungen häufig ändern oder Markup über viele Systeme hinweg gepflegt wird, ergänzen Sie automatisierte Prüfungen und einen geregelten Freigabeprozess.

Checkliste

• Sind die zentralen Entitäten und ihre Beziehungen im internen Modell dokumentiert?
• Ist für jedes ausgegebene Feld eine verbindliche Datenquelle festgelegt?
• Sind die Schema.org-Typen für die beschriebenen Inhalte passend?
• Werden nur vorhandene, relevante und belegbare Werte ausgegeben?
• Stimmen Markup, sichtbarer Inhalt und kanonische URL überein?
• Ist geklärt, welche Systemkomponente das Markup erzeugt?
• Werden fehlende, veraltete oder zurückgezogene Daten korrekt behandelt?
• Prüfen Tests Syntax, Inhalt und repräsentative Grenzfälle?
• Ist dokumentiert, wie Änderungen am Datenmodell die Ausgabe beeinflussen?

Häufige Fragen

Verbessern strukturierte Daten automatisch das Ranking?

Nein. Strukturierte Daten helfen, Inhalte maschinenlesbar zu beschreiben. Sie garantieren weder eine bestimmte Darstellung in Suchergebnissen noch bessere Rankings.

Muss jede Seite JSON-LD enthalten?

Nein. Markup ist sinnvoll, wenn es die Entität und den sichtbaren Inhalt der Seite treffend beschreibt. Eine Seite ohne passende strukturierte Angaben braucht keine künstliche Auszeichnung.

Soll Schema.org direkt im CMS-Datenmodell verwendet werden?

In der Regel sollte das interne Modell die fachlichen Anforderungen des Systems abbilden. Schema.org kann darauf gemappt werden. So bleibt das Datenmodell nicht von einem einzelnen Ausgabeformat abhängig.

Wie oft muss die Ausgabe geprüft werden?

Prüfen Sie sie bei Änderungen an Datenmodell, Templates, Importen oder Inhaltsregeln und regelmäßig anhand repräsentativer Seiten. Automatisierte Tests helfen, unbeabsichtigte Abweichungen früh zu erkennen.

Weiterführend

• Content-Modell entwickeln: Von Seiten zu strukturierten Inhalten
• SEO-Datenmodellierung: Wie Inhalte, URLs und Links zusammenhängen
• Content-Architektur: Inhalte, Daten und SEO für große Websites organisieren
• erlebe-nrw

Weiterführende Quellen

Diese offiziellen Dokumentationen und Standards vertiefen die behandelten Themen.

• Schema.org: Getting started
• Google Search Central: Strukturierte Daten