Was Schema.org und JSON-LD jeweils leisten
Schema.org stellt Begriffe wie Organization, Person, WebSite, WebPage, Service und Article bereit. JSON-LD ist ein Format, in dem du solche Angaben maschinenlesbar ausgeben kannst. Beides ergänzt den sichtbaren Inhalt einer Website; es ersetzt weder eine klare Erklärung noch funktionierende Navigation.
Ein Parser kann damit beispielsweise erkennen, dass ein Blogartikel zu einer bestimmten Website gehört und von einer bestimmten Person verfasst wurde. Ob ein Suchsystem diese Information für eine besondere Darstellung nutzt, hängt von dessen unterstützten Funktionen und Regeln ab.
Nicht jeder gültige Schema.org-Typ besitzt eine Google-Rich-Result-Funktion. Trenne deshalb die semantische Beschreibung deiner Inhalte von der Frage, welche Suchdarstellung derzeit unterstützt wird. Ein Validator beantwortet nicht automatisch beide Fragen.
Beginne mit den vorhandenen Entitäten
Lege zuerst fest, was auf deiner Website tatsächlich beschrieben wird. Bei einem Einzelunternehmen können das das Unternehmen, die verantwortliche Person, die Website und einzelne Leistungen sein. Ein Ratgeber ist dann ein Artikel über ein Thema und keine zusätzliche Unternehmensidentität.
- Unternehmen: Name, erreichbare Kontaktdaten und zutreffende Unternehmensart.
- Person: Autor oder verantwortliche Fachperson mit nachvollziehbarer Zuordnung.
- Website: Gemeinsamer Rahmen für die einzelnen Seiten.
- Einzelseite: Inhalt, Adresse, Sprache und Rolle der jeweiligen Seite.
- Leistung oder Artikel: Der eigentliche Gegenstand der Seite.
Diese Rollen dürfen miteinander verbunden sein. Sie sollten aber nicht allein deshalb vervielfacht werden, weil mehrere Plugins oder Vorlagen unabhängig voneinander Daten ausgeben. Prüfe die gesamte gerenderte Seite, nicht nur einen einzelnen Codeblock im Editor.
Stabile IDs verbinden gemeinsame Angaben
Mit einer @id lässt sich eine Entität innerhalb eines Graphen eindeutig referenzieren. Dieselbe Unternehmensidentität sollte auf Startseite, Leistungsseite und Blogartikel dieselbe ID verwenden. Die URL der konkreten Seite bleibt davon getrennt.
Das folgende vereinfachte Beispiel zeigt nur die Verbindung zwischen Website und Seite. Die Domain ist ein Platzhalter; für eine echte Website müssen URLs und Angaben angepasst werden.
{
"@context": "https://schema.org",
"@graph": [
{
"@type": "WebSite",
"@id": "https://example.com/#website",
"url": "https://example.com/",
"name": "Beispielunternehmen"
},
{
"@type": "WebPage",
"@id": "https://example.com/ratgeber/#webpage",
"url": "https://example.com/ratgeber/",
"name": "Ein hilfreicher Ratgeber",
"isPartOf": {"@id": "https://example.com/#website"}
}
]
}Für einen Blogbeitrag kommt die Artikelbeschreibung mit Autor, Überschrift und belegbaren Datumsangaben hinzu. Eine Leistungsseite benötigt eine andere inhaltliche Rolle. Die Gemeinsamkeit liegt in den stabilen Beziehungen, nicht in einem identischen Inhalt für jede Seite.
Grafik als Text lesen
Wie ein JSON-LD-Graph zusammenhängt Vereinfachtes Beispiel mit wiederverwendbaren @id-Verweisen. WebPage WebSite Service Organization isPartOf mainEntity publisher provider
Zeichne nur zutreffende und sichtbare Inhalte aus
Übernimm keine erfundenen Bewertungen, Preise oder Qualifikationen, um den Graphen größer wirken zu lassen. Angaben müssen zum dargestellten Inhalt passen. Veraltete Preise oder ein falsches Änderungsdatum machen die Beschreibung unzuverlässig, auch wenn die Syntax gültig ist.
Bei FAQs sollte die strukturierte Antwort aus derselben Quelle wie die sichtbare Antwort entstehen. CSS-Klassen und Layout-Attribute gehören nicht zum Inhalt der Antwort. Sinnvolle Textformatierung und erlaubte Links lassen sich getrennt von der Darstellung ausgeben.
Auch bei Bildern, Autorennamen und Quellen ist eine gemeinsame Datenbasis hilfreich. Sie verhindert, dass ein sichtbarer Artikel und seine maschinenlesbare Beschreibung nach einer Überarbeitung unterschiedliche Informationen enthalten.
Prüfe Syntax, Bedeutung und gerenderte Ausgabe
Der Schema.org Validator hilft beim Erkennen von Syntax- und Vokabularproblemen. Zusätzlich musst du selbst prüfen, ob Typ und Eigenschaften den tatsächlichen Inhalt beschreiben. Für von Google unterstützte Rich Results sind außerdem die jeweiligen Google-Anforderungen relevant.
Kontrolliere die Ausgabe nach Includes und Plugins. Achte auf widersprüchliche Unternehmensdaten, doppelte Artikelidentitäten und Referenzen auf nicht definierte Objekte. Teste nach Änderungen an Templates mehrere Seitentypen, damit eine technische Anpassung nicht nur auf einer Beispielseite funktioniert.
Wenn du eine bestehende Ausgabe prüfen lassen möchtest, gehört das fachlich zu einer technischen SEO-Analyse. Sind zugleich Darstellung und technische Website-Struktur betroffen, bietet ein Website Audit einen breiteren Blick.
Grafik als Text lesen
JSON-LD auf drei Ebenen prüfen Ein gültiges Format ist der erste Schritt der Prüfung. 1 Syntax Ist die JSON-LD-Ausgabe technisch lesbar? 2 Bedeutung Passen Typen, Eigenschaften und Verweise? 3 Seiteninhalt Stimmen die Angaben mit der veröffentlichten Seite überein?
Pflege den Graphen gemeinsam mit dem Inhalt
Einmal eingebautes Markup bleibt nicht automatisch korrekt. Neue Leistungen, geänderte Preise und überarbeitete Artikel müssen auch in der strukturierten Beschreibung ankommen. Gemeinsame Konfigurationen sind dafür meist zuverlässiger als kopierte Datenblöcke auf vielen Seiten.
Vermeide zugleich Angaben, die deine Website nicht belegen kann. Ein kleineres, zutreffendes Datenmodell ist hilfreicher als eine große Sammlung unpassender Eigenschaften. Umfangreiche Auszeichnung ist sinnvoll, wenn sie auf echten Informationen beruht und konsequent gepflegt wird.
Quellen und fachliche Grundlagen
Links und zugehörige Aussagen geprüft am 01.11.2026. Praxisempfehlungen sind als fachliche Einordnung formuliert.
