JSON-LD

JSON-LD steht für JavaScript Object Notation for Linked Data und ist ein Format, mit dem sich strukturierte Daten in eine Webseite einbetten lassen. Statt die Auszeichnung wie bei älteren Verfahren in den sichtbaren HTML-Code zu verweben, steht ein JSON-LD-Block als eigenständiges Skript im Seitenkopf oder -körper: <script type="application/ld+json">. Innerhalb dieses Blocks beschreibt ein Shop oder eine Redaktion in maschinenlesbarer Form, worum es auf der Seite eigentlich geht – welches Produkt, welcher Preis, welche Marke, welche Bewertung. Suchmaschinen und zunehmend generative KI-Systeme lesen diese Angaben als verlässliche Faktenbasis, gegen die sie den übrigen, unstrukturierten Text abgleichen.

Der Name beschreibt das Verfahren präzise. „JSON“ ist das aus der Softwareentwicklung bekannte, schlanke Datenformat aus Schlüssel-Wert-Paaren. Das angehängte „LD“ – Linked Data – steht für die Idee, einzelne Datenpunkte über gemeinsame Vokabulare miteinander und mit der Außenwelt zu verknüpfen. Das Vokabular, das im Web praktisch überall genutzt wird, ist schema.org, ein gemeinsam von Google, Microsoft, Yahoo und Yandex getragenes Schema-Verzeichnis. JSON-LD ist also das Format, schema.org das Wörterbuch. Beide Begriffe werden oft synonym gebraucht, beschreiben aber verschiedene Ebenen derselben Sache.

Wie JSON-LD funktioniert

Technisch ist JSON-LD ein in sich geschlossener Datenblock, der nichts am sichtbaren Layout einer Seite verändert. Ein Crawler liest den Skriptinhalt, erkennt am @type, um welche Entität es sich handelt – etwa Product, Article, FAQPage oder Organization – und ordnet die folgenden Eigenschaften dieser Entität zu. Ein minimaler Produkt-Block sieht im Kern so aus:

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Wanderjacke Alpin 3000",
  "brand": { "@type": "Brand", "name": "Beispielmarke" },
  "gtin13": "4012345678901",
  "offers": {
    "@type": "Offer",
    "price": "189.00",
    "priceCurrency": "EUR",
    "availability": "https://schema.org/InStock"
  }
}

Der entscheidende Vorteil dieser Trennung: Die strukturierten Daten liegen unabhängig vom Markup vor, das ein Mensch im Browser sieht. Ein Designer kann das Layout umbauen, ohne aus Versehen ein Auszeichnungsattribut zu zerstören, und die Pflege läuft an einer einzigen, klar abgegrenzten Stelle. Genau das macht JSON-LD auch für Redaktionssysteme und Shop-Software so handhabbar: Das System generiert den Block aus den ohnehin vorhandenen Stammdaten und hängt ihn an die Seite, statt jede einzelne Preis- oder Verfügbarkeitsangabe im Template auszeichnen zu müssen.

Warum Google JSON-LD bevorzugt

Strukturierte Daten lassen sich grundsätzlich in drei Formaten ausliefern: JSON-LD, Microdata und RDFa. Google unterstützt alle drei, empfiehlt aber ausdrücklich JSON-LD. Die Gründe sind handfest und decken sich mit dem, was Umsetzungsteams in der Praxis erleben:

• Weniger Fehler. Microdata und RDFa verteilen Attribute über den gesamten sichtbaren HTML-Baum. Wird ein Element umgebaut, gelöscht oder per JavaScript ersetzt, geht die Auszeichnung leicht kaputt – oft unbemerkt. Ein isolierter JSON-LD-Block bleibt davon unberührt.
• Einfachere Pflege. Die Daten stehen an einer Stelle, sind versionierbar und lassen sich automatisiert erzeugen, statt über Dutzende Template-Fragmente verstreut zu liegen.
• Zuverlässigeres Crawling. Ein Block im Dokumentkopf wird verlässlich gelesen, während dynamisch nachgeladene Microdata-Attribute je nach Rendering-Reihenfolge übersehen werden können.
• Schutz vor versehentlichen Änderungen. Eine Person, die nur am Layout arbeitet, löscht eher ein itemprop-Attribut als einen klar als Datenblock erkennbaren Skript-Abschnitt.

Microdata hat weiterhin eine Berechtigung, wenn Auszeichnung zwingend inline am sichtbaren Element hängen muss, und RDFa besetzt eine schrumpfende Nische. Für den Großteil heutiger Projekte ist JSON-LD jedoch der vernünftige Standard – eine Einschätzung, die auch der Format-Überblick bei Wikipedia teilt.

JSON-LD für E-Commerce: das Product-Schema

Im Onlinehandel ist das Product-Schema der mit Abstand wichtigste Anwendungsfall. Es war einer der ersten Schema-Typen, die strukturierte Daten in der SEO-Community populär machten, weil es direkt sichtbare Effekte hatte: Sternebewertungen, Preis- und Verfügbarkeitsangaben in den Suchergebnissen, die sogenannten Rich Snippets. Entscheidend für die Wirkung sind nicht die Anwesenheit irgendeines Product-Blocks, sondern die ausgefüllten Felder. Relevant sind insbesondere:

Gerade die letzten beiden Felder gewinnen an Bedeutung, seit generative KI-Systeme Kaufempfehlungen formulieren: Ein Agent, der eine Empfehlung ausspricht, liest Lieferzeit und Rückgaberecht direkt aus dem Markup mit. Wichtig ist dabei eine eiserne Regel: Strukturierte Daten dürfen nur Informationen enthalten, die auch für Nutzer sichtbar auf der Seite stehen. Wer per JSON-LD Preise oder Bewertungen ausweist, die im sichtbaren Inhalt fehlen, riskiert eine manuelle Maßnahme von Google.

JSON-LD in Shopware

Für Shopware-Betreiber ist JSON-LD aktuell besonders relevant, weil sich die Plattform bewegt. Neuere Shopware-6-Versionen können strukturierte Daten nativ als separaten JSON-LD-Block im Seitenkopf ausgeben, statt sie wie früher über Microdata oder ein Custom-Plugin einbetten zu müssen. Diese Fähigkeit hängt teils an einem Feature-Flag und ist nicht in jeder Installation automatisch aktiv. Wer auf einer älteren Version steht oder mehr Felder braucht als das Standard-Set, deckt die Lücke mit etablierten Erweiterungen aus dem Shopware Store ab – etwa SEO-Tool-Plugins, die das Product-Schema vervollständigen.

Der oft unterschätzte Punkt: JSON-LD ist nur so gut wie die Produktdaten dahinter. Ein lückenhaftes Sortiment mit fehlenden GTINs, inkonsistenten Attributen und veralteten Beschreibungen lässt sich nicht durch ein Schema-Plugin retten. Das saubere Markup macht die vorhandenen Fakten eindeutig – es erfindet keine. Die Pflege der Quelldaten, häufig im PIM, ist deshalb der unsichtbare, aber entscheidende Teil der Arbeit.

JSON-LD und KI-Sichtbarkeit

Während JSON-LD ursprünglich ein reines Display-Signal für hübsche Snippets war, hat es sich zu einem Verständnis-Signal entwickelt. Sprachmodelle interpretieren strukturierte Daten nicht wie Fließtext, den sie erst deuten müssen, sondern nehmen sie als geordnete Faktenbasis. Produktdaten, die sauber ausgezeichnet sind, lassen sich eindeutig einer Entität zuordnen, statt aus Prosa geraten zu werden. Wie stark der direkte Effekt auf KI-Zitate ist, wird in der Branche allerdings überschätzt: Einzelne Studien finden nur geringe Bewegung bei den Zitaten nach dem Hinzufügen von Markup. Der belastbare Grund, JSON-LD ernst zu nehmen, ist daher nicht ein versprochener Zitations-Multiplikator, sondern die Grundvoraussetzung, dass die eigenen Produktfakten überhaupt eindeutig und ohne Interpretationsspielraum vorliegen.

JSON-LD im Zusammenspiel mit anderen Schema-Typen

In der Praxis bleibt es selten beim reinen Product-Block. Eine gut ausgezeichnete Seite kombiniert mehrere Schema-Typen, die jeweils einen anderen Aspekt beschreiben und sich gegenseitig stützen. Auf einer Shop-Seite treffen so schnell drei oder vier Entitäten zusammen, ohne dass sich der Code unübersichtlich anfühlen muss – weil jeder Typ in seinem eigenen, klar benannten Objekt steht.

• Organization bzw. Store. Beschreibt das Unternehmen selbst – Name, Logo, Kontaktwege, Social-Profile. Dieser Block hilft KI-Systemen und Suchmaschinen, die Marke als eigenständige Entität zu erkennen und Aussagen über sie korrekt zuzuordnen.
• BreadcrumbList. Bildet die Navigationshierarchie ab und macht für Crawler nachvollziehbar, wo eine Seite im Katalog steht.
• FAQPage. Zeichnet Frage-Antwort-Paare aus. Gerade für generative Engines, die oft direkt auf eine Frage antworten wollen, ist sauber strukturierter FAQ-Inhalt ein dankbarer, leicht extrahierbarer Baustein.
• Review und AggregateRating. Liefern Bewertungen als eigene, verifizierbare Datenpunkte statt als Fließtext.

Wichtig ist, die Blöcke nicht beliebig zu stapeln, sondern nur das auszuzeichnen, was wirklich auf der Seite steht und für die Suchabsicht relevant ist. Übermäßiges, irrelevantes Markup verbessert nichts und erhöht nur das Fehlerrisiko bei der Pflege.

Typische Fehler bei der JSON-LD-Implementierung

Die meisten Probleme mit JSON-LD entstehen nicht durch fehlendes, sondern durch fehlerhaftes oder unaufrichtiges Markup. Die wiederkehrenden Stolperfallen:

• Markup ohne sichtbare Entsprechung. Bewertungen oder Preise auszeichnen, die auf der Seite nicht stehen – der klassische Grund für eine manuelle Maßnahme.
• Veraltete Werte. Ein statisch gepflegter Block, der den Preis von gestern trägt, während die Seite längst einen neuen zeigt. JSON-LD sollte aus der gleichen Quelle gespeist werden wie der sichtbare Inhalt.
• Falsche oder fehlende Pflichtfelder. Ein Offer ohne price oder priceCurrency ist unvollständig und wird von Google teils ignoriert.
• Ungültige Syntax. Ein fehlendes Komma oder eine nicht geschlossene Klammer macht den gesamten Block unbrauchbar. Validierung vor dem Deployment ist deshalb Pflicht, kein Nice-to-have.

Ein praktischer Arbeitsablauf sieht so aus: Markup automatisiert aus den Stammdaten generieren, vor jedem Release durch den Rich-Results-Test und einen Schema-Validator schicken und stichprobenartig auf produktiven Seiten gegenprüfen. So bleibt die Auszeichnung dauerhaft korrekt, statt einmal sauber aufgesetzt und dann stillschweigend zu veralten.

Die Geschichte: von Microformats zum bevorzugten Standard

JSON-LD ist nicht aus dem Nichts entstanden, sondern das vorläufige Ergebnis einer längeren Entwicklung hin zu einem maschinenlesbaren Web. Die ersten Versuche, Bedeutung in HTML einzubetten, liefen über Microformats und später über Microdata sowie RDFa – allesamt Verfahren, die Auszeichnung direkt an die sichtbaren HTML-Elemente hefteten. Das funktionierte, war aber fehleranfällig und eng mit dem Layout verflochten. Jede Designänderung barg das Risiko, die Semantik zu beschädigen.

JSON-LD wurde als eigenständige Spezifikation entwickelt und 2014 als Empfehlung des World Wide Web Consortium veröffentlicht. Der entscheidende konzeptionelle Bruch: Die Bedeutung wird vom Layout entkoppelt und in einen separaten Datenblock ausgelagert. Als Google in den Folgejahren JSON-LD zunehmend bevorzugte und schließlich offen empfahl, kippte die Praxis – heute ist es im professionellen Umfeld der Normalfall, während Microdata und RDFa eher in Altbeständen oder Spezialfällen überleben. Wer ein Projekt neu aufsetzt, hat kaum noch einen Grund, sich gegen JSON-LD zu entscheiden.

Diese Entwicklung erklärt auch, warum JSON-LD so gut zur aktuellen KI-Ära passt. Ein Web, dessen Inhalte in klar getrennten, maschinenlesbaren Datenblöcken vorliegen, ist genau das, was sowohl Suchmaschinen-Crawler als auch die Retrieval-Schichten generativer Systeme zuverlässig auswerten können. Was als SEO-Werkzeug für hübsche Snippets begann, ist damit zu einem Baustein der maschinellen Wissensaufbereitung geworden – und seine Bedeutung wächst eher, als dass sie schwindet.

Häufige Fragen zu JSON-LD

Ist JSON-LD ein Ranking-Faktor? Nicht direkt. JSON-LD verbessert nicht die Position als solche, sondern ermöglicht Rich Snippets und eine eindeutige Entitätszuordnung. Die bessere Darstellung in den Ergebnissen kann die Klickrate erhöhen, der Effekt ist aber indirekt.

Wo gehört der JSON-LD-Block hin? Empfohlen ist der Dokumentkopf, technisch funktioniert auch der Body. Wichtiger als die Position ist, dass der Block valide ist und nur sichtbare Inhalte beschreibt.

Wie prüfe ich mein JSON-LD? Über Googles Rich-Results-Test und den Schema-Markup-Validator. Beide melden Syntaxfehler und fehlende Pflichtfelder, bevor sie produktiv geschaltet werden.

Brauche ich JSON-LD und einen Merchant-Center-Feed? Für Google ja – beide Quellen speisen den Shopping Graph. Der Feed ist der kanonische Datenkanal, das Seiten-Markup ergänzt ihn. Sie ersetzen einander nicht.

Schadet falsches JSON-LD? Ja. Markup, das Inhalte beschreibt, die auf der Seite nicht sichtbar sind, oder das irreführende Angaben macht, kann zu einer manuellen Maßnahme führen. Korrektheit geht vor Vollständigkeit.