Schema Markup JSON-LD: Aufbau, Beispiel, Test

Was JSON-LD ist und woraus ein Block besteht

JSON-LD steht für JavaScript Object Notation for Linked Data. Gemeint ist ein Datenformat, das aus Schlüsseln und Werten besteht und in einem Skript-Tag mit dem Typ application/ld+json im Quelltext liegt. Browser zeigen diesen Block nicht an, Crawler lesen ihn aus. Dadurch kannst du Informationen über eine Seite hinterlegen, ohne das sichtbare Layout anzufassen, und das macht das Format für Redaktionen und Entwickler gleichermaßen angenehm.

Jeder Block hat zwei feste Bestandteile. Mit @context legst du fest, welches Vokabular gilt, in der Praxis immer schema.org. Mit @type bestimmst du, was du beschreibst, zum Beispiel Article, Organization oder BreadcrumbList. Alles andere sind Eigenschaften dieses Typs, etwa headline, datePublished oder url. Eigenschaften können selbst wieder Objekte sein, ein Artikel hat dann einen author, der seinerseits vom Typ Person ist.

Wie viel du ausfüllen musst, hängt vom Typ ab. Google unterscheidet in seiner Dokumentation Pflichtfelder von empfohlenen Feldern: Ohne die Pflichtfelder ist die Seite für die jeweilige Darstellung nicht geeignet, mit empfohlenen Feldern wird das Ergebnis vollständiger. Beim Typ Organization nennt Google zum Beispiel gar keine Pflichtfelder, du ergänzt einfach, was zutrifft. Den Gesamtzusammenhang erklärt der Grundlagenartikel zu strukturierten Daten.

Ein Beispiel Zeile für Zeile

Das folgende Beispiel beschreibt einen Blogartikel. Es ist bewusst klein gehalten und mit Platzhalterwerten gefüllt. In deinem Projekt ersetzt du sie durch die Angaben, die auch sichtbar auf der Seite stehen, sonst widerspricht dein Markup dem Inhalt. Die Zeilen am Ende dieses Abschnitts bilden gemeinsam einen vollständigen Block, den du so in den Quelltext einfügen könntest.

Willst du aus dem Beispiel einen anderen Typ machen, tauschst du @type und die Eigenschaften aus. Für eine Organisation nutzt du etwa name, url, logo und sameAs, wobei Google für das Logo ein crawlbares Bild mit mindestens 112 mal 112 Pixeln verlangt. Pflichtfelder gibt es dort keine, die Angaben müssen aber stimmen. Lies für jeden Typ die jeweilige Doku, bevor du Felder erfindest.

Lies das Beispiel am Ende dieses Abschnitts von oben nach unten. Das Skript-Tag kündigt den Datenblock an, die geschweiften Klammern fassen das Objekt zusammen, danach folgen Kontext und Typ. Die Überschrift gehört zum sichtbaren Titel der Seite, das Datum folgt dem Format Jahr-Monat-Tag, und der Autor steckt als verschachteltes Objekt in einer eigenen Klammer. Zwischen den Zeilen steht jeweils ein Komma, nach der letzten Eigenschaft nicht.

<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Article",
"headline": "Schema Markup mit JSON-LD",
"datePublished": "2026-10-01",
"author": {"@type": "Person", "name": "Max Mustermann"}
}
</script>

Mehrere Objekte verbinden mit @id und @graph

Selten beschreibt eine Seite nur eine einzige Sache. Ein Ratgeber ist ein Artikel, gehört zu einer Website, wurde von einer Organisation veröffentlicht und hat einen Breadcrumb-Pfad. Statt alles ineinander zu schachteln, kannst du die Objekte nebeneinanderstellen und über eine @id verknüpfen. Die @id ist ein eindeutiger Bezeichner, meist eine URL mit Anker, und jedes Objekt kann auf diese Kennung verweisen.

Die Google-Dokumentation erwähnt genau diesen Weg: Elemente können verschachtelt oder getrennt aufgeführt werden, und über @id lassen sich zusammengehörige Elemente verbinden, zum Beispiel ein Rezept und sein Video. Mit dem Schlüssel @graph packst du mehrere Objekte in einen gemeinsamen Block, so musst du nicht mehrere Skript-Tags pflegen. Beides ist normales JSON-LD, nichts Exotisches.

Der Nutzen geht über das Aufräumen hinaus. Wenn dein Organization-Objekt auf der Startseite eine feste @id hat und die Artikel darauf verweisen, wird sichtbar, dass alle Beiträge zur selben Organisation gehören. Das ist die technische Seite dessen, was in unserem Artikel zu Entity SEO inhaltlich beschrieben wird: eindeutige Dinge mit eindeutigen Beziehungen.

Woher das Markup kommt: Plugin, Template oder Skript

Handarbeit lohnt sich nur bei einzelnen Seiten. Bei jedem System mit Vorlagen solltest du das Markup aus den Daten erzeugen lassen, die ohnehin vorhanden sind: Titel, Veröffentlichungsdatum, Autor, Bild. SEO-Plugins und Themes machen das bereits, oft automatisch für Artikel und Seiten. Eigene Templates sind sauberer, wenn du genau kontrollieren willst, was ausgegeben wird.

Google erklärt, dass JSON-LD auch dann funktioniert, wenn es per JavaScript in die Seite eingefügt wird, etwa über einen Tag-Manager. Das ist praktisch, wenn du keinen Zugriff auf die Templates hast. Trotzdem gilt: Je näher das Markup am Server-Code liegt, desto geringer ist die Gefahr, dass ein Skriptfehler es verschwinden lässt. Prüfe im URL-Prüftool der Search Console den gerenderten HTML-Code, um sicherzugehen.

Achte außerdem auf Dopplungen. Liefern Theme, SEO-Plugin und ein Spezial-Plugin jeweils einen eigenen Artikel-Block, entstehen drei leicht verschiedene Beschreibungen derselben Seite. Entscheide dich für eine Quelle und schalte die anderen ab. Für Seiten mit Breadcrumbs lohnt sich der Blick in unseren Artikel zu Breadcrumbs und SEO, weil dort häufig Plugin und Theme parallel arbeiten.

Ein Praxisbeispiel für die Struktur: Beim Breadcrumb-Typ verlangt Google mindestens zwei Einträge, jeweils mit position und name, dazu eine URL im Feld item. Beim letzten Eintrag darf die URL fehlen, dann nimmt Google die Adresse der Seite selbst. So klein die Regel wirkt, sie zeigt, wie genau die Dokumentation zu jedem Typ gelesen werden sollte.

Testen und Fehlermeldungen lesen

Vor dem Livegang prüfst du das Markup mit dem Rich Results Test von Google. Er zeigt, welche Typen erkannt wurden und ob Pflichtfelder fehlen. Google rät, kritische Fehler zu beheben, und empfiehlt, zunächst einige Seiten zu veröffentlichen und mit dem URL-Prüftool zu kontrollieren, ob sie nicht per robots.txt, noindex oder Login blockiert sind. Für allgemeine schema.org-Prüfungen, unabhängig von Google-Features, gibt es zusätzlich den Schema-Markup-Validator.

Nach dem Livegang übernimmt die Search Console. Sobald Google Markup mit Rich-Result-Berechtigung findet, taucht es in den Berichten zu erweiterten Darstellungen auf, inklusive Fehlern und Warnungen. Fehler bedeuten, dass der Eintrag nicht für die Darstellung berücksichtigt wird, Warnungen sind optionale Verbesserungen. Wie du die Search Console einrichtest, steht im Artikel Google Search Console einrichten.

Beachte dabei: Ein grüner Haken heißt nur, dass die Syntax und die Pflichtfelder stimmen. Ob die Angaben inhaltlich zur Seite passen und ob Google eine erweiterte Darstellung ausspielt, sagt dir kein Testwerkzeug. Das bleibt eine Entscheidung des Algorithmus, wie die Google-Doku ausdrücklich festhält. Plane Tests deshalb als Routine ein, nicht als einmalige Abnahme vor dem Launch.

Typische Syntaxfehler und wie du sie vermeidest

JSON verzeiht keine Flüchtigkeit. Ein fehlendes Komma, eine nicht geschlossene Klammer oder ein überzähliges Komma am Ende machen den ganzen Block ungültig. Die häufigste Ursache in der Praxis sind typografische Anführungszeichen, die ein Textverarbeitungsprogramm statt der geraden Zeichen einfügt. Schreibe Code deshalb in einem Code-Editor und nicht in einem Dokument, das später kopiert wird.

Wenn du dir unsicher bist, ob deine Seite überhaupt sauber ausgeliefert wird, hilft ein Gesamtblick: Unser SEO-Check zeigt dir technische Auffälligkeiten, bevor du Stunden in einzelne Markup-Zeilen steckst. Oft liegt das Problem nämlich nicht im Code, sondern darin, dass die Seite selbst gar nicht indexiert wird oder ein falsches Template ausliefert, und dann hilft auch perfektes JSON-LD nicht weiter.

Kommas zwischen den Eigenschaften prüfen, nach der letzten Eigenschaft kein Komma setzen
Nur gerade Anführungszeichen verwenden, keine typografischen
Datumsangaben im Format Jahr-Monat-Tag schreiben
Typnamen exakt in der schema.org-Schreibweise verwenden, inklusive Groß- und Kleinschreibung
URLs vollständig und absolut angeben, also mit https und Domain
Sonderzeichen im Text maskieren, besonders Anführungszeichen innerhalb von Werten

Quellen

Häufige Fragen

Wohin gehört der JSON-LD-Code, in den Head oder in den Body?

Google akzeptiert JSON-LD im Head und im Body. In den Google-Beispielen steht der Block meist im Head, entscheidend ist, dass er im ausgelieferten HTML vorhanden ist.

Brauche ich für JSON-LD ein Plugin?

Nein. Du kannst den Block von Hand oder per Template einfügen. Plugins erleichtern die Arbeit, solltest du aber nicht mehrfach parallel laufen lassen.

Was ist der Unterschied zwischen JSON-LD und schema.org?

Schema.org ist das Vokabular, also die Liste der Typen und Eigenschaften. JSON-LD ist eines der Formate, mit denen du dieses Vokabular in eine Seite schreibst.

Wie prüfe ich, ob mein JSON-LD funktioniert?

Mit dem Rich Results Test und dem Schema-Markup-Validator vorab, danach mit dem URL-Prüftool und den Berichten der Search Console.