JSON-LD Semantische Infrastruktur

JSON-LD

JSON-LD serialisiert Linked Data im verbreiteten JSON-Format und wird als Script-Block im HTML-Header oder Body einer Webseite eingebettet. Im Gegensatz zu Microdata und RDFa erfordert JSON-LD keine Annotation des sichtbaren HTML-Markups, sondern liefert die strukturierten Daten als separaten Block. Das @context-Attribut verweist auf das verwendete Vokabular (typischerweise Schema.org), @type definiert die Klasse und @id den eindeutigen Identifikator der beschriebenen Entität. Google empfiehlt JSON-LD als bevorzugtes Format für strukturierte Daten. JSON-LD wird intern als RDF-Graph interpretiert; jedes Schlüssel-Wert-Paar entspricht einem Triple. In der semantischen Infrastruktur ist JSON-LD das Standardformat, in dem Webseiten ihre Entitäten, Attribute und Relationen für Suchmaschinen und KI-Systeme auszeichnen. Die einfache Implementierung und Wartbarkeit machen JSON-LD zum meistverwendeten Format für strukturierte Daten im Web.

JSON-LD vs. Microdata vs. RDFa: Warum das Format eine strategische Entscheidung ist

Alle drei Formate serialisieren strukturierte Daten und sind von Google offiziell unterstützt. Trotzdem ist JSON-LD die überlegene Wahl, und zwar nicht wegen Googles Empfehlung, sondern wegen seiner technischen Eigenschaften. Microdata und RDFa sind in den sichtbaren HTML-Markup eingebettet und damit unlösbar an die Darstellungsschicht gekoppelt. JSON-LD ist davon vollständig getrennt.

Diese Trennung hat konkrete Vorteile. JSON-LD kann über JavaScript dynamisch erzeugt und angepasst werden, ohne das DOM zu verändern. Es kann von Content Management Systemen in Templates generiert werden, unabhängig vom redaktionellen Inhalt. Updates an der semantischen Auszeichnung erfordern keine Änderungen am sichtbaren Markup. Für technische SEO-Teams bedeutet das drastisch reduzierte Implementierungskosten und höhere Wartbarkeit.

Ein häufig übersehener Aspekt ist die Möglichkeit, mehrere JSON-LD-Blöcke auf einer Seite zu verwenden. Eine Seite kann gleichzeitig ein WebPage, eine Organization und ein BreadcrumbList-Objekt beschreiben, in separaten Script-Tags. Suchmaschinen fusionieren diese Blöcke zu einem kohärenten Graph.

Die Grenze von JSON-LD liegt bei dynamisch geladenem Content. Inhalte, die erst nach dem initialen Seitenload via JavaScript gerendert werden, sind für Google in JSON-LD nur dann verlässlich verarbeitbar, wenn das Rendering vollständig abgeschlossen ist, bevor der Crawler die Seite verlässt. Server-Side-Rendering bleibt die sicherste Option für kritische strukturierte Daten.

JSON-LD korrekt implementieren: Die häufigsten Fehler und wie du sie vermeidest

Der häufigste JSON-LD-Fehler ist kein Syntaxfehler, sondern ein semantischer: Die ausgezeichneten Daten stimmen nicht mit dem sichtbaren Seiteninhalt überein. Google wertet diese Diskrepanz als Spam-Signal. Wenn der JSON-LD-Block ein aggregateRating von 4.8 Sternen enthält, auf der Seite aber keine Bewertungen sichtbar sind, riskierst du Manuelle Maßnahmen.

Ein weiterer kritischer Fehler ist das Weglassen von @id. Ohne @id entsteht ein Blank Node, der nicht mit externen Quellen verknüpft werden kann. Jede Organization, Person, Product oder WebPage sollte eine explizite @id tragen, die der kanonischen URL der Entität entspricht.

Für komplexe Seiten empfiehlt sich die Nested-Entity-Strategie: Anstatt die Organization-Entität auf jeder Seite vollständig zu wiederholen, wird sie auf der Entity Home vollständig beschrieben und auf anderen Seiten nur per @id referenziert. Das reduziert Redundanz und erleichtert konsistente Updates.

Testing ist kein optionaler Schritt. Googles Rich Results Test und der Schema Markup Validator zeigen Fehler, Warnungen und erkannte Rich-Result-Typen. Beide Tools sollten nach jeder Implementierungsänderung konsultiert werden. Dazu kommt die Search Console, die über tatsächlich indexierte strukturierte Daten Auskunft gibt. Die Lücke zwischen dem, was implementiert ist, und dem, was Google tatsächlich verarbeitet, ist oft größer als erwartet.