JSON-LD für SEO

TL;DR — JSON-LD ist ein kleiner Codeblock, den Sie einer Seite hinzufügen, um klar zu machen, worum es auf der Seite geht – ob Artikel, Produkt oder Rezept – in einem Format, das Suchmaschinen und KI-Systeme leicht lesen können. Er steht in einem eigenen <script>-Tag und ändert nie etwas, das Besucher sehen. Google empfiehlt ihn gegenüber den anderen beiden Formaten, weil er am einfachsten hinzuzufügen und sauber zu halten ist. Er verbessert nicht Ihr Ranking, kann Ihre Ergebnisse aber reichhaltiger erscheinen lassen (Sterne, Preise, FAQs).

Was JSON-LD ist

Wenn Sie eine Seite veröffentlichen, kann ein Mensch sie lesen und erkennen: „Oh, das ist ein Rezept für Bananenbrot.“ Eine Suchmaschine muss das aus den Wörtern erraten. Strukturierte Daten sind die Möglichkeit, das Raten zu beenden – Sie kennzeichnen die Seite in maschinenlesbarem Code, sodass Suchmaschinen wissen, dass es ein Rezept ist, wer der Autor ist und wie die Bewertung ist.

JSON-LD ist die beliebteste Methode, diese Kennzeichnung zu schreiben. Der Name steht für JavaScript-Objektnotation für verknüpfte Daten. Evidence for this claim JSON-LD is a structured-data format that can express Schema.org types and properties in a script block. Scope: Schema.org JSON-LD guidance; JSON-LD is a format, not the vocabulary itself. Confidence: high · Verified: 2026-07-14 Schema.org: JSON-LD Sie müssen nicht wissen, was das bedeutet, um es zu verwenden. In der Praxis ist JSON-LD ein Codeblock, der wie eine Liste beschrifteter Fakten aussieht und in einem <script>-Tag steckt:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "How to Bake Banana Bread",
  "author": { "@type": "Person", "name": "Patrick Stox" },
  "datePublished": "2026-06-26"
}
</script>

Das Entscheidende: Dieser Block lebt getrennt von den Wörtern auf Ihrer Seite. Er ändert nichts an dem, was Ihre Besucher sehen. Er ist nur eine Anweisung für die Roboter.

Warum Google es mag

Es gibt tatsächlich drei Möglichkeiten, strukturierte Daten zu schreiben – JSON-LD, Microdata und RDFa. Die anderen beiden funktionieren, indem sie zusätzlichen Code in Ihr sichtbares HTML einstreuen, verflochten mit Ihren Überschriften und Absätzen. JSON-LD hält alles in einer ordentlichen Box.

Deshalb empfiehlt Google JSON-LD: Es ist am einfachsten hinzuzufügen, am einfachsten korrekt zu halten, und die Wahrscheinlichkeit, etwas zu beschädigen, ist weitaus geringer. Googles Worte: Es ist “the easiest solution for website owners to implement and maintain at scale.” (Übersetzung) „die einfachste Lösung für Website-Betreiber, die sich in großem Maßstab implementieren und pflegen lässt“. Alle drei Formate sind in Ordnung – JSON-LD ist nur das am wenigsten fehleranfällige.

Was es tatsächlich für Sie tut

Zwei ehrliche Dinge und ein Mythos:

• Es kann Ihr Suchergebnis reichhaltiger erscheinen lassen. Rezeptbewertungen, Produktpreise, FAQ-Aufklappmenüs, Veranstaltungstermine – diese „Rich Results“ stammen aus strukturierten Daten.
• Es hilft Suchmaschinen (und KI), Ihre Inhalte zu verstehen. Es verbindet Ihre Seite mit bekannten Dingen – Ihrem Unternehmen, einem Autor, einem Produkt.
• Es verbessert nicht Ihr Ranking. Das ist der Mythos. Das Hinzufügen von JSON-LD ist keine Ranking-Verbesserung. Google hat das klar und wiederholt gesagt.

Die eine Regel, die zählt

Markieren Sie nur, was tatsächlich auf der Seite steht. Behaupten Sie keine 5-Sterne-Bewertung in Ihrem JSON-LD, wenn Besuchern keine Bewertung angezeigt wird. Beschreiben Sie keinen Preis, der nicht vorhanden ist. Strukturierte Daten müssen mit der sichtbaren Seite übereinstimmen – das Beschreiben von Dingen, die nicht vorhanden sind, verstößt gegen die Regeln und kann dazu führen, dass Ihre Rich Results entfernt werden.

Möchten Sie die präzise Version – die @context / @type / @id-Syntax, das @graph-Muster, die JavaScript-Injektionsfalle, die Ihre Auszeichnung vor KI-Crawlern verbirgt, und wie Sie das Markup validieren? Wechseln Sie zum Tab Erweitert.

TL;DR — JSON-LD (JavaScript-Objektnotation für verknüpfte Daten) ist eine W3C-Empfehlung aus dem Jahr 2014 — basierend auf JSON, aber @context ist das, was es zu Linked Data macht, nicht nur JSON. Es ist das strukturierte Datenformat, das Google empfiehlt, weil es am einfachsten zu implementieren und in großem Maßstab zu pflegen ist und niemals sichtbares HTML berührt; Microdata und RDFa sind gleichermaßen gültig, wenn sie korrekt sind. Die Syntax-Grundlage ist @context (Vokabular — schema.org für die meisten SEO-Markups, obwohl die Spezifikation andere Kontexte zulässt), @type (Entität), @id (eine nützliche, aber optionale stabile URI zur Referenzierung von Entitäten — die Grundlage von @graph, selbst ein gültiges Muster unter anderen, keine Anforderung). Platzieren Sie es in <head> oder <body> — Google akzeptiert beides. Googlebot rendert JS, sodass dynamisch injiziertes JSON-LD für Google funktioniert; mehrere KI-Crawler (GPTBot, ClaudeBot inklusive, wie getestet) führen kein JS aus, aber das ist anbieter- und datumsabhängig — verifizieren Sie direkt, anstatt es für jeden KI-Crawler anzunehmen, und serverseitig zu rendern, was Sie nicht bestätigen können. Strukturierte Daten sind kein Ranking-Signal — sie steuern die Berechtigung für Rich Results und das Verständnis von Entitäten und müssen Inhalte beschreiben, die auf der Seite sichtbar sind.

JSON-LD ist ein Format, kein Vokabular

Zunächst eine Unterscheidung, die viel Verwirrung beseitigt: JSON-LD ist das Format; schema.org ist das Vokabular. JSON-LD ist wie Sie das Markup schreiben; schema.orgs Article, Product, Organization-Typen sind was Sie sagen. Rich Results sind die Feature-Ebene darüber. Diese Seite behandelt das Format. (Der Vokabular-für-KI-Aspekt findet sich in Schema Markup for AI.)

JSON-LD ist eine W3C-Empfehlung, erstmals veröffentlicht im Jahr 2014 — es geht seiner SEO-Übernahme voraus und wurde für die allgemeine Interoperabilität von Linked Data im gesamten Web entwickelt, nicht speziell für die Suche. Diese Geschichte erklärt, warum eine Eigenschaft wie @id überhaupt existiert, und es ist der spezifikationsbezogene Punkt, den die meisten SEO-Leitfäden überspringen: JSON-LD ist nicht nur JSON. Es basiert auf der JSON-Syntax, aber die @context-Deklaration macht die Daten verknüpft — identifizierbar und verbindbar über das gesamte Web. Entfernen Sie @context und Sie haben Daten, die ein Parser nicht interpretieren kann.

JSON-LD ist auch nicht an schema.org gebunden. Die Spezifikation erlaubt es, dass @context auf jedes veröffentlichte Vokabular verweist — seine eigenen Beispiele verlinken auf Nicht-schema.org-Kontexte —, also ist JSON-LD die richtige Antwort auf “welches Format”, während schema.org eine Antwort, die übliche für Such- und KI-Such-Markups, auf “welches Vokabular” ist. Eine Seite könnte gültig JSON-LD mit einem anderen Vokabular verwenden; es wäre dann nur kein schema.org-Markup mehr.

JSON-LD im Vergleich zu Microdata und RDFa

Es gibt drei Möglichkeiten, strukturierte Daten auszudrücken, und Google unterstützt alle:

Googles Empfehlung ist explizit, aber eng gefasst: “In general, Google recommends using JSON-LD for structured data if your site’s setup allows it, as it’s the easiest solution for website owners to implement and maintain at scale (in other words, less prone to user errors).” (Übersetzung) „Im Allgemeinen empfiehlt Google, JSON-LD für strukturierte Daten zu verwenden, wenn das Setup Ihrer Website dies zulässt, da es die einfachste Lösung für Website-Betreiber ist, um es in großem Maßstab zu implementieren und zu pflegen (mit anderen Worten, weniger anfällig für Benutzerfehler).“

Die Nuance, die Konkurrenten meist übersehen – und die es wert ist, beibehalten zu werden – stammt von derselben Google-Seite: “All 3 formats are equally fine for Google, as long as the markup is valid and properly implemented per the feature’s documentation.” (Übersetzung) „Alle 3 Formate sind für Google gleichermaßen in Ordnung, solange das Markup gültig und gemäß der Dokumentation der Funktion ordnungsgemäß implementiert ist.“ Die Empfehlung betrifft also die Implementierungsfreundlichkeit und die Fehlerrate, nicht die Parsing-Geschwindigkeit oder einen Ranking-Vorteil. Die Verwendung von Mikrodaten ist keine Strafe. JSON-LD gewinnt in der Praxis nur, weil es strukturierte Daten nicht mit dem Markup verknüpft, das ein Designer morgen bearbeiten könnte.

Die Syntax: @context, @type, @id, Eigenschaften, Verschachtelung

Hier ist ein kommentierter Article-Block:

<script type="application/ld+json">
{
  "@context": "https://schema.org",          // the vocabulary — the common value for SEO
  "@type": "Article",                          // the entity type
  "@id": "https://example.com/post#article",   // a stable URI for this entity
  "headline": "How JSON-LD Works",            // a property (key/value)
  "datePublished": "2026-06-26",
  "author": {                                  // a nested entity
    "@type": "Person",
    "name": "Patrick Stox",
    "url": "https://patrickstox.com/"
  }
}
</script>

• @context – legt den semantischen Rahmen fest (das Vokabular). Für schema.org-SEO-Markup ist es typischerweise "https://schema.org", aber das ist eine Konvention, keine Regel: @context ordnet Begriffe Identifikatoren zu, und die Spezifikation erlaubt es, auf andere Vokabulare zu verweisen. Es teilt dem Parser mit, wie jeder folgende Eigenschaftsname zu interpretieren ist. Dies ist der Teil, der es zu verknüpften Daten macht.
• @type – deklariert die Entität: Article, Product, Organization, BreadcrumbList usw. Es wird einem schema.org-Typ zugeordnet. Verwenden Sie den spezifischsten passenden Typ – NewsArticle statt Article, wenn es passt.
• @id – eine eindeutige URI, die eine Ressource identifiziert. Über diesen Mechanismus können Sie eine Entität über eine andere referenzieren (siehe @graph unten), und es lohnt sich, ihn für alles zu setzen, das Sie querverweisen – aber er ist nicht universell erforderlich. Die JSON-LD-Spezifikation erlaubt nicht identifizierte Blank Nodes, sodass gültiges JSON-LD @id bei Entitäten weglassen kann, auf die Sie nie anderswo verweisen müssen.
• Eigenschaften – gewöhnliche JSON-Schlüssel-Wert-Paare, die Vokabularbegriffe aus dem @context verwenden.
• Verschachtelung – untergeordnete Entitäten werden als verschachtelte JSON-Objekte (das author-Objekt oben) oder als Arrays von Objekten ausgedrückt.

Das @graph-Muster (der skalierbare Ansatz)

Die meisten Seiten benötigen mehr als eine Entität: eine Organization, eine WebSite, eine BreadcrumbList und die Article- oder WebPage-Entität selbst. Der naive Ansatz sind vier separate <script>-Blöcke, die Daten wiederholen. Eine skalierbare Alternative ist ein einzelner Block mit @graph – ein Array von Entitäten, die über @id querverwiesen werden. Weder die JSON-LD-Spezifikation noch Google schreiben @graph als das Muster vor – es ist Syntax zum Ausdrücken eines Graphen, und andere gültige Layouts existieren (separate typisierte Blöcke, verschachtelte Objekte ohne ein Top-Level-@graph, Blank Nodes ohne @id) – aber auf einer Website mit mehreren querverwiesenen Entitäten ist es das Muster, das vermeidet, dieselben Organization- oder WebSite-Daten auf jeder Seite zu wiederholen:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://example.com/#org",
      "name": "Example Co",
      "url": "https://example.com/"
    },
    {
      "@type": "WebSite",
      "@id": "https://example.com/#website",
      "url": "https://example.com/",
      "publisher": { "@id": "https://example.com/#org" }   // reference, not a copy
    },
    {
      "@type": "WebPage",
      "@id": "https://example.com/post#webpage",
      "isPartOf": { "@id": "https://example.com/#website" },
      "breadcrumb": { "@id": "https://example.com/post#breadcrumb" }
    }
  ]
}
</script>

Definieren Sie Organization einmal und verweisen Sie dann überall anders mit { "@id": "...#org" } darauf, anstatt Name, Logo und URL zu wiederholen. So bauen die Schema-Plugins der großen CMS ihre Ausgabe auf, und deshalb existiert @id. Bing argumentiert ähnlich für die Verschachtelung von JSON-LD: Es “makes defining links and relationships between data and entities… easy because it supports nested data.” (Übersetzung) „macht das Definieren von Links und Beziehungen zwischen Daten und Entitäten … einfach, weil es verschachtelte Daten unterstützt.“

Wo platzieren: <head> oder <body>

Google bestätigt, dass beides funktioniert – “You can put the JSON-LD data in the <head> or the <body> of the page.” (Übersetzung) „Sie können die JSON-LD-Daten in den <head> oder den <body> der Seite setzen.“ <head> ist üblich, aber viele CMS-Plugins fügen es am Ende von <body> ein, und das ist in Ordnung. Bing stimmt zu, dass es “in the header, body or foot of the page” (Übersetzung) „im Kopf, Körper oder Fuß der Seite“ stehen kann. Verschwenden Sie keine Zeit damit, einen gültigen Block vom Body in den Head zu verschieben; es ändert nichts. Evidence for this claim Google permits JSON-LD in either the head or body of an HTML document for supported structured-data features. Scope: Google Search JSON-LD guidance; markup must still match visible page content. Confidence: high · Verified: 2026-07-14 Google: Structured data introduction

JSON-LD dynamisch generieren – und die KI-Crawler-Falle

Sie können JSON-LD mit JavaScript dynamisch erstellen, und Google dokumentiert zwei Möglichkeiten:

1. Google Tag Manager — ein benutzerdefiniertes HTML-Tag mit dem JSON-LD und Werten aus GTM-Variablen zieht. (Vermeiden Sie doppelte Daten zwischen Seite und Tag.)
2. Benutzerdefiniertes JavaScript — erstellen Sie das Skriptelement programmatisch:

   const script = document.createElement('script');
   script.setAttribute('type', 'application/ld+json');
   script.textContent = structuredDataText;
   document.head.appendChild(script);

Das funktioniert für Googlebot, weil Google die Seite rendert: “Google Search can understand and process structured data that’s available in the DOM when it renders the page.” (Übersetzung) „Google Search kann strukturierte Daten verstehen und verarbeiten, die beim Rendern der Seite im DOM verfügbar sind.“ So weit, so gut.

Hier ist der Punkt, den die meisten Anleitungen übersehen, vorsichtig formuliert. Mehrere KI-Crawler – einschließlich GPTBot und ClaudeBot, wie üblicherweise getestet – haben JavaScript nicht ausgeführt. Wenn Ihr JSON-LD erst nach der Ausführung eines clientseitigen Skripts existiert, sieht ein JS-überspringender Crawler es nie – es ist für diesen Bot unsichtbar, obwohl Googlebot es problemlos liest, weil Google dokumentiert, dass es das DOM rendert, bevor es nach strukturierten Daten sucht.

Zwei ehrliche Einschränkungen zu diesem KI-Crawler-Verhalten: Googles eigene Dokumentation legt die Googlebot-Seite fest; die KI-Crawler-Seite stammt aus Tests und Berichten einzelner Anbieter, nicht aus einer Spezifikation, die einer von ihnen veröffentlicht, also ist sie anbieter- und datumsabhängig – die JavaScript-Unterstützung eines Crawlers kann sich ändern, und ich habe nicht jeden Anbieter direkt verifiziert. Behandeln Sie „KI-Crawler überspringen JS“ nicht als universelle Regel, auf der Sie aufbauen; behandeln Sie es als Grund, den Crawler zu überprüfen, der Ihnen tatsächlich wichtig ist (oder standardmäßig Server-Rendering zu verwenden, wenn Sie nicht überprüfen können). Wenn es nicht im serverseitig gerenderten HTML ist und Sie nicht bestätigt haben, dass der Crawler JS ausführt, nehmen Sie an, dass er es nicht sehen kann. Für KI-Such-Sichtbarkeit rendern Sie JSON-LD serverseitig in das statische HTML, es sei denn, Sie haben etwas anderes verifiziert. (Dies ist das JavaScript-Rendering-Problem aus der Perspektive strukturierter Daten – siehe JavaScript-SEO.)

Es gibt eine zweite Einschränkung für E-Commerce: Google warnt, dass dynamisch generiertes Product-Markup “Shopping-Crawls weniger häufig und weniger zuverlässig machen kann,” was ein echtes Problem für sich schnell ändernde Preise und Verfügbarkeit darstellt. Für Produkte bevorzugen Sie serverseitiges Rendering, unabhängig von KI.

Die Richtlinien (die jetzt Zähne haben)

Googles Richtlinien für strukturierte Daten sind kurz und tragend:

• “Markieren Sie keine Inhalte, die für Leser der Seite nicht sichtbar sind.”
• “Markieren Sie keine irrelevanten oder irreführenden Inhalte, wie gefälschte Bewertungen.”
• “Platzieren Sie die strukturierten Daten auf der Seite, die sie beschreiben.”
• “Verwenden Sie die spezifischsten anwendbaren Typ- und Eigenschaftsnamen, die von schema.org definiert werden.”
• Blockieren Sie Ihre Seiten mit strukturierten Daten nicht über robots.txt oder noindex für Googlebot.

Die Regel für sichtbare Inhalte ist die, die Sie verinnerlichen sollten. Schema, das Inhalte beschreibt, die nicht auf der Seite angezeigt werden, war schon immer ein Verstoß; die Durchsetzung von „unsichtbarem“ Schema wurde verschärft. Bing formuliert die Warnung unverblümt: “even though the markup is not visible on your page, it is still read by the search engines, and putting spam data in the markup can hamper your presence.” (Übersetzung) „Auch wenn das Markup auf Ihrer Seite nicht sichtbar ist, wird es von Suchmaschinen gelesen, und Spam-Daten im Markup können Ihre Präsenz beeinträchtigen.“

Häufige JSON-LD-Fehler

• Markup, das nicht zur sichtbaren Seite passt – das Problem Nr. 1 (eine Bewertung im JSON-LD, die kein Besucher sieht).
• Fehlerhaftes JSON – ein nachgestelltes Komma, ein nicht maskiertes Anführungszeichen oder Word-Smart-Quotes (" statt "), die den gesamten Block stillschweigend zerstören. JSON-LD ist streng.
• Falsche Eigenschaftsnamen – Erfinden von Eigenschaften, die nicht in schema.org sind, oder Tippfehler bei echten, sodass der Parser sie ignoriert.
• Ein generischer Typ, wo ein spezifischer existiert – Thing oder Article, wo Recipe oder NewsArticle angebracht war.
• Doppelte, inkonsistente Organization-Blöcke auf Seiten mit widersprüchlichen Namen/Logos.
• Fehlende erforderliche Eigenschaften für das angestrebte Rich Result (jede Funktion listet ihre eigenen Pflichtfelder).
• JS-injiziertes Markup, das als für jeden Crawler sichtbar angenommen wird – Google rendert es, aber einige KI-Crawler haben das nicht getan, und das ist pro Crawler zu überprüfen (der obige Haken).

JSON-LD validieren

Vier verschiedene Fragen werden unter „Ist mein JSON-LD gültig?“ gestellt, und sie sind nicht dieselbe Frage – das Bestehen einer bedeutet nicht das Bestehen der anderen:

• Testen Sie per URL, nicht per eingefügtem Code, für JS-gerenderte Seiten. Der Code-Eingabemodus des Rich Results Tests führt Ihre Skripte nicht aus oder löst relative Referenzen nicht so auf wie der Live-URL-Test – er kann Ihnen nicht sagen, wie ein clientseitig injizierter Block nach dem Rendern aussieht.
• Bing Webmaster Tools – Markup-Validator – Bing validiert JSON-LD seit August 2018.
• Keiner dieser Tests spricht für Crawler, die kein JavaScript rendern (siehe den KI-Crawler-Hinweis oben) – das Testen der gerenderten URL bestätigt, was Google sieht, nicht was ein JS-überspringender Bot erhält.

Hilft JSON-LD bei SEO?

Setzen Sie die Erwartungen ehrlich:

• Kein Ranking-Signal. John Mueller hat gesagt, dass strukturierte Daten eine Website nicht besser ranken lassen. Punkt.
• Rich-Result-Berechtigung. Es macht Sie berechtigt für erweiterte SERP-Funktionen (Sterne, Preise, FAQs, Breadcrumbs) – Berechtigung, keine Garantie.
• CTR, indirekt. Reichhaltiger aussehende Ergebnisse können mehr Klicks einbringen, das ist der eigentliche Nutzen für die meisten Websites.
• Entity-Verständnis. Es hilft Suchmaschinen, Ihre Seite mit bekannten Entitäten und dem Knowledge Graph zu verbinden.
• KI-Suche. Fabrice Canel (Bing) bestätigte 2025, dass Schema-Markup den LLMs von Microsoft hilft, Inhalte zu verstehen – aber beachten Sie den Hinweis zur kontrollierten Studie in Schema Markup for AI: Es ist Infrastruktur zur Disambiguierung, kein direkter Zitationshebel.

Also: Implementieren Sie JSON-LD für Rich-Result-Berechtigung, Entity-Klarheit und KI/LLM-Verständnis – nicht als Ranking-Hack.

Dieser Artikel befindet sich im Hub für strukturierte Daten. Für die KI-spezifische Betrachtung des schema.org-Vokabulars siehe Schema-Markup für KI; für die Render-Mechanik hinter dynamischer Injektion siehe JavaScript-SEO.

KI-Zusammenfassung

Eine komprimierte Darstellung der erweiterten Version:

• Was es ist: JSON-LD (JavaScript-Objektnotation für verknüpfte Daten) ist ein Format für strukturierte Daten, kein Vokabular – ein <script type="application/ld+json">-Block. Auf der SEO-Seite wird es typischerweise mit dem schema.org-Vokabular kombiniert, aber @context kann auch woanders hinzeigen. Eine W3C-Empfehlung seit 2014; basiert auf JSON, aber @context macht es zu Linked Data, nicht zu einfachem JSON.
• Warum Google es empfiehlt: Google nennt es “the easiest solution… to implement and maintain at scale” (Übersetzung) „die einfachste Lösung, die sich in großem Maßstab implementieren und pflegen lässt“. Es berührt niemals sichtbares HTML. Aber alle drei Formate (JSON-LD, Microdata, RDFa) sind gleichermaßen gültig, wenn sie korrekt sind – der Vorteil liegt in der Fehlerrate, nicht im Parsing oder Ranking.
• Syntax-Grundgerüst: @context (Vokabular – schema.org für die meisten SEO-Markups, nicht der einzige gültige Wert) · @type (Entität, verwenden Sie die spezifischste) · @id (nützliche, optionale stabile URI für Querverweise; nicht identifizierte Blank Nodes sind ebenfalls gültiges JSON-LD) · Eigenschaften (Schlüssel/Wert) · Verschachtelung (Objekte/Arrays).
• @graph-Muster: Ein Block, ein Array von Entitäten, die über @id referenziert werden – definieren Sie Organization einmal, referenzieren Sie es überall. Ein skalierbarer Ansatz für Seiten mit mehreren Entitäten, kein Spezifikations- oder Google-Zwang; andere gültige Graph-Layouts existieren.
• Platzierung: <head> oder <body> – Google akzeptiert beides; verschieben Sie gültige Blöcke nicht.
• Dynamische Injektion + KI-Hinweis: Googlebot rendert JavaScript, sodass injiziertes JSON-LD für Google funktioniert; mehrere KI-Crawler – einschließlich GPTBot und ClaudeBot, wie getestet – haben JavaScript nicht ausgeführt, aber das ist anbieter- und datumsabhängig, keine universelle Regel, also überprüfen Sie pro Crawler und serverseitig rendern, was Sie nicht bestätigen können. Dynamisches Product-Markup birgt auch das Risiko seltenerer Shopping-Crawls.
• Richtlinien: Markieren Sie nur sichtbare Inhalte; passen Sie zur Seite; spezifischster Typ; blockieren Sie die Seite nicht für Crawler. Die Durchsetzung von “unsichtbarem” Schema wurde verschärft.
• Häufige Fehler: Nicht übereinstimmendes/unsichtbares Markup, fehlerhaftes JSON (geschweifte Anführungszeichen, nachgestellte Kommas), falsche Eigenschaftsnamen, generische Typen, fehlende erforderliche Eigenschaften.
• Validierung: Vier separate Prüfungen (JSON-Syntax, schema.org-Vokabular, Google Rich-Results-Berechtigung, Live-Parsing in der Search Console), die sich nicht gegenseitig ersetzen – Rich Results Test (per URL, nicht eingefügter Code), Schema.org Validator, GSC-Erweiterungen, Bing Markup Validator.
• SEO-Effekt: kein Ranking-Signal. Ermöglicht Rich-Results-Berechtigung, CTR, Entitätsverständnis und LLM-Verständnis (Canel, Bing, 2025).

Offizielle Dokumentation

Primärquellen-Dokumentation von den Suchmaschinen und der Spezifikation.

Google

• Einführung in die Funktionsweise von strukturierten Daten – die JSON-LD-Empfehlung, die Nuance “alle 3 Formate sind gleichermaßen in Ordnung” und die Platzierung in <head>/<body>.
• Allgemeine Richtlinien für strukturierte Daten – die Richtlinien: nur sichtbare Inhalte, zur Seite passend, spezifischster Typ, Crawler nicht blockieren.
• Strukturierte Daten mit JavaScript generieren – die GTM- und Custom-JS-Injektionsansätze sowie der Hinweis auf dynamische Product-Shopping-Crawls.
• Rich Results Test – Berechtigung validieren (per URL für JS-gerenderte Seiten testen).

Bing / Microsoft

• Ihre Website mit strukturierten Daten auszeichnen — Bing empfiehlt JSON-LD, akzeptiert Platzierung in Kopf-, Haupt- und Fußbereich und warnt vor ungültigem Markup.
• Unterstützung für JSON-LD in Bing Webmaster Tools eingeführt (August 2018) — als Bing die JSON-LD-Validierung hinzufügte.

Standards / Vokabular

• JSON-LD 1.1 — W3C-Empfehlung — die Spezifikation selbst.
• json-ld.org — die Heimat des Formats, mit der allgemeinverständlichen Definition.
• Einstieg in Schema.org — das Vokabular, das JSON-LD ausdrückt, und die Regel für sichtbaren Inhalt.
• Schema.org Validator — validiert gegen das Vokabular.

Zitate aus der Quelle

Öffentliche Aussagen von Google, Bing und der Spezifikation. Jeder Link springt zur zitierten Passage auf der Quellseite, sofern die Seite den Text bereitstellt.

Google-Dokumente — die Empfehlung und die Nuance

• “In general, Google recommends using JSON-LD for structured data if your site’s setup allows it, as it’s the easiest solution for website owners to implement and maintain at scale (in other words, less prone to user errors).” (Übersetzung) „Im Allgemeinen empfiehlt Google die Verwendung von JSON-LD für strukturierte Daten, wenn das Setup Ihrer Website dies zulässt, da es die einfachste Lösung für Website-Betreiber ist, sie in großem Umfang zu implementieren und zu pflegen (mit anderen Worten: weniger anfällig für Benutzerfehler).“ Zum Zitat springen
• “All 3 formats are equally fine for Google, as long as the markup is valid and properly implemented per the feature’s documentation.” (Übersetzung) „Alle 3 Formate sind für Google gleichermaßen in Ordnung, solange das Markup gültig und gemäß der Dokumentation des Features ordnungsgemäß implementiert ist.“ Zum Zitat springen
• “Google Search can understand and process structured data that’s available in the DOM when it renders the page.” (Übersetzung) „Die Google-Suche kann strukturierte Daten verstehen und verarbeiten, die im DOM verfügbar sind, wenn sie die Seite rendert.“ Zum Zitat springen

Google-Dokumente — die Richtlinien

• “Don’t mark up content that is not visible to readers of the page.” (Übersetzung) „Markieren Sie keine Inhalte, die für Leser der Seite nicht sichtbar sind.“ Zum Zitat springen
• “Use the most specific applicable type and property names defined by schema.org.” (Übersetzung) „Verwenden Sie die spezifischsten anwendbaren Typ- und Eigenschaftsnamen, die von schema.org definiert sind.“ Zum Zitat springen

John Mueller, Google — JSON-LD-Präferenz und Ranking

• “We currently prefer JSON-LD markup. I think most of the new structured data that kind of come out are for JSON-LD first. So that is what we prefer.” (Übersetzung) „Wir bevorzugen derzeit JSON-LD-Markup. Ich denke, die meisten neuen strukturierten Daten, die so herauskommen, sind zuerst für JSON-LD. Das ist es also, was wir bevorzugen.“ — Google Webmaster Hangout, März 2019. Abdeckung
• Zum Ranking: “Structured data won’t make your site rank better.” (Übersetzung) „Strukturierte Daten werden Ihre Website nicht besser ranken lassen.“ — 2025. (Weitergegeben über Search Engine Roundtable; wörtlich gegen den Originalbeitrag prüfen.) Abdeckung

Bing / Microsoft

• JSON-LD “makes defining links and relationships between data and entities between the data present on your pages easy because it supports nested data.” (Übersetzung) „macht es einfach, Verknüpfungen und Beziehungen zwischen Daten und Entitäten in den auf Ihren Seiten vorhandenen Daten zu definieren, da es verschachtelte Daten unterstützt.“ — Bing Webmaster Tools-Dokumentation. Zum Zitat springen
• “Webmasters should be very alert as to not put invalid and incorrect information in the markup, as even though the markup is not visible on your page, it is still read by the search engines.” (Übersetzung) „Webmaster sollten sehr wachsam sein, um keine ungültigen und falschen Informationen in das Markup aufzunehmen, denn obwohl das Markup auf Ihrer Seite nicht sichtbar ist, wird es dennoch von den Suchmaschinen gelesen.“ — Bing Webmaster Tools-Dokumentation. Zum Zitat springen

Fabrice Canel, Microsoft Bing — Schema und LLMs

• Auf der SMX Munich (März 2025) bestätigte Canel, dass Schema-Markup den großen Sprachmodellen von Microsoft hilft, Webinhalte zu verstehen. (In der Berichterstattung paraphrasiert; bestätigen Sie den Wortlaut anhand der Konferenzaufzeichnung oder LinkedIn, bevor Sie eine einzelne Formulierung als endgültig behandeln.) Berichterstattung

Die Spezifikation — json-ld.org

• “JSON-LD is a lightweight Linked Data format. It is easy for humans to read and write. It is based on the already successful JSON format and provides a way to help JSON data interoperate at Web-scale.” (Übersetzung) „JSON-LD ist ein leichtgewichtiges Linked-Data-Format. Es ist für Menschen leicht zu lesen und zu schreiben. Es basiert auf dem bereits erfolgreichen JSON-Format und bietet eine Möglichkeit, die Interoperabilität von JSON-Daten im Web-Maßstab zu unterstützen.“ Zum Zitat springen

JSON-LD-Syntax — Kurzreferenz

Der Wrapper

<script type="application/ld+json">
{ ...your markup... }
</script>

Die reservierten Schlüsselwörter

Single entity

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Widget",
  "offers": { "@type": "Offer", "price": "19.99", "priceCurrency": "USD" }
}

Verschachtelung — eine untergeordnete Entität ist ein verschachteltes Objekt (oder ein Array von Objekten):

"author": { "@type": "Person", "name": "Patrick Stox" }

Das @graph-Muster — einmal definieren, per @id referenzieren:

{
  "@context": "https://schema.org",
  "@graph": [
    { "@type": "Organization", "@id": "https://ex.com/#org", "name": "Ex Co" },
    { "@type": "WebSite", "publisher": { "@id": "https://ex.com/#org" } }
  ]
}

Häufige Eigenschaften nach Typ

• Article / BlogPosting: headline, author, datePublished, image, publisher
• Product: name, image, brand, offers (→ price, priceCurrency, availability)
• Organization: name, url, logo, sameAs (Social-/Wikidata-URIs)
• BreadcrumbList: itemListElement → ListItem (position, name, item)
• FAQPage: mainEntity → Question → acceptedAnswer → Answer

Faustregeln

• @context ist für die meisten SEO-Markups "https://schema.org" — das ist eine Konvention, keine Spezifikationsanforderung. Verwenden Sie gerade Anführungszeichen, niemals typografische.
• Keine nachgestellten Kommas — JSON ist streng.
• Verwenden Sie den spezifischsten verfügbaren @type.
• Markieren Sie nur, was auf der Seite sichtbar ist.
• Platzieren Sie im <head> oder im <body> — beides ist gültig.
• @id und @graph helfen Ihnen, Entitäten zu referenzieren und zu organisieren, sind aber nicht erforderlich — leere Knoten und andere Layouts sind ebenfalls gültig.
• Für Crawler, von denen Sie nicht verifiziert haben, dass sie JavaScript ausführen (einschließlich mehrerer KI-Crawler, GPTBot und ClaudeBot, die in Tests nicht ausgeführt haben), rendern Sie serverseitig.
• Validieren Sie als separate Ebenen: Rich Results Test (per URL) für die Google-Eignung + Schema.org Validator für das Vokabular — das Bestehen des einen bedeutet nicht, dass das andere auch besteht.

Tools zur Validierung von JSON-LD

• Schema.org Validator — die breitere Vokabularprüfung. Ein Block kann hier bestehen und trotzdem gegen Googles funktionsspezifische Regeln verstoßen.
• Google Rich Results Test — testen Sie die bereitgestellte URL, wenn das Rendering wichtig ist, insbesondere bei clientseitig injiziertem Markup. Dieser Test deckt Googles unterstützte Rich Results ab, nicht jeden schema.org-Typ.

JSON-LD-Fehler, die Sie vermeiden sollten

Auszeichnung von Fakten, die Besucher nicht sehen können. Eine Bewertung, ein Preis, ein Autor oder eine andere Angabe in JSON-LD muss mit der sichtbaren Seite übereinstimmen. Versteckte oder irreführende strukturierte Daten können die Berechtigung für Rich Results kosten. Stattdessen: Markup aus derselben Quelle wie die sichtbaren Inhalte generieren.

Behandlung von gültigem JSON als gültiges Schema. Ein Parser kann wohlgeformtes JSON akzeptieren, dessen Eigenschaftsnamen nicht in schema.org existieren. Stattdessen: Sowohl eine JSON-LD-Vokabularprüfung als auch die Google-Anforderungen der Zielfunktion ausführen.

Verwendung von typografischen Anführungszeichen oder nachgestellten Kommas. JSON ist streng; typografische Anführungszeichen und ein Komma nach der letzten Eigenschaft können den gesamten Block ungültig machen. Stattdessen: Daten serialisieren, anstatt JSON-Strings von Hand zusammenzusetzen.

Wahl eines generischen Typs, wenn ein spezifischer existiert. Thing oder breites Article-Markup wirft nützliche Bedeutung weg, wenn die Seite eindeutig ein Recipe, Product oder NewsArticle ist. Stattdessen: Den spezifischsten anwendbaren schema.org-Typ verwenden.

Duplizieren von Entitäten mit widersprüchlichen Details. Mehrere Organization-Blöcke mit unterschiedlichen Namen, Logos oder URLs machen den Graphen mehrdeutig. Stattdessen: Der Entität eine stabile @id geben, sie einmal definieren und diese Kennung an anderer Stelle referenzieren.

Annahme, dass schema.org-Gültigkeit ein Google-Rich-Result garantiert. Google unterstützt eine Teilmenge von Typen und fügt eigene erforderliche Eigenschaften und Inhaltsrichtlinien hinzu. Stattdessen: Zuerst das Vokabular validieren, dann die Berechtigung für die spezifische Google-Funktion testen.

Einbetten von JSON-LD in JavaScript und Annahme, dass jeder Crawler es sieht. Google kann clientseitiges Markup rendern, aber JS-überspringende KI-Crawler erhalten es möglicherweise nie. Stattdessen: JSON-LD serverseitig rendern, wenn diese Konsumenten wichtig sind, und die Live-URL testen, anstatt nur eingefügten Code.

Nachweisen, dass eine JSON-LD-Bereitstellung wirksam wurde

Test 1 — Die Live-Seite enthält gültiges, seitenübereinstimmendes JSON-LD

• Durchzuführender Test — Die bereitgestellte URL mit dem Schema-Markup-Validator abrufen und die erkannten Entitäten und Werte mit der sichtbaren Seite vergleichen.
• Erwartetes Ergebnis — Das JSON parst, alle Eigenschaften gehören zu schema.org, @id-Referenzen lösen innerhalb des Graphen wie beabsichtigt auf, und Angaben wie Namen, Preise, Bewertungen und Daten stimmen mit dem überein, was Benutzer sehen.
• Fehlerinterpretation — Parserfehler weisen auf fehlerhaftes JSON hin; Vokabularwarnungen weisen auf falsch geschriebene oder nicht unterstützte Eigenschaften hin; nicht übereinstimmende Werte weisen auf getrennte Inhalts- und Schema-Datenquellen hin, die auseinanderdriften.
• Überwachungsfenster — Sofort nach der Bereitstellung und Cache-Löschung.
• Rollback-Auslöser — Den neuen Block entfernen oder zurücksetzen, wenn er falsche sichtbare Inhaltsangaben veröffentlicht, einen zuvor gültigen Graphen bricht oder nicht geparst werden kann.

Test 2 — Die Zielsuchfunktion erkennt das gerenderte Markup

• Durchzuführender Test — Die bereitgestellte URL durch den Rich-Results-Test von Google laufen lassen, dann den Rich-Result-Berechtigungsprüfer verwenden, um fehlende erforderliche und empfohlene Felder nach Typ zu überprüfen.
• Erwartetes Ergebnis — Google erkennt den beabsichtigten unterstützten Typ ohne kritische Fehler; jeder clientseitig generierte Block erscheint im gerenderten HTML.
• Fehlerinterpretation — Ein Bestehen des Schema.org-Validators gepaart mit einem Google-Fehler bedeutet normalerweise, dass der Typ keine unterstützte Google-Funktion ist, ein von Google erforderliches Feld fehlt, eine Inhaltsrichtlinie nicht erfüllt ist oder der Renderer den Block nie erhalten hat.
• Überwachungsfenster — Sofort in beiden Tests; Änderungen in der Search Console warten auf ein erneutes Crawlen.
• Rollback-Auslöser — Clientseitige Injektion zurücksetzen, wenn sie zuvor sichtbare strukturierte Daten aus dem gerenderten Ergebnis verschwinden lässt, oder nicht unterstützte Funktionsansprüche aus dem Start entfernen, bis die erforderlichen Inhalte vorhanden sind.

Testen Sie sich selbst: JSON-LD

Fünf kurze Fragen zum JSON-LD-Format. Wählen Sie für jede eine Antwort und überprüfen Sie dann.

Ressourcen, die Ihre Zeit wert sind

Meine weiterführenden Artikel

• Schema-Markup: Der einfache Weg zu Rich Results — der Ahrefs-Leitfaden zu strukturierten Daten, Schema-Typen und Rich Results (die Feature-Ebene über JSON-LD).
• Einsteigerleitfaden zur technischen SEO — wo strukturierte Daten in das größere technische Bild passen.
• JavaScript-SEO-Probleme und bewährte Verfahren — die Rendering-Seite: warum sich JS-injiziertes Markup für Crawler, die kein JavaScript ausführen, anders verhält.
• Die neuen Webcrawler kennenlernen — meine Cloudflare-Radar-Analyse von KI-Crawlern (GPTBot, ClaudeBot und Co.) — die Bots, die Ihr JS-injiziertes Schema überspringen.

Offiziell

• Googles Einführung in die Funktionsweise von strukturierten Daten — die JSON-LD-Empfehlung und die Nuance der „alle 3 Formate“, direkt von der Quelle.
• Googles Strukturierte Daten mit JavaScript generieren — die Methoden zur dynamischen Injektion und der Produkt-Hinweis.
• JSON-LD 1.1 — W3C-Empfehlung und json-ld.org — das Format selbst.

Aus der Branche

• Welche strukturierten Daten Google bevorzugt — Search Engine Journal — der Bericht über Muellers Kommentar „we currently prefer JSON-LD“.
• Microsoft Bing Copilot nutzt Schema für seine LLMs — Search Engine Land — Fabrice Canels Bestätigung auf der SMX Munich 2025, dass Schema den LLMs von Bing hilft.
• Was sind strukturierte JSON-LD-Daten und wozu dienen sie? — Ignite Visibility — eine solide Einführung für Einsteiger.
• Einsteigerleitfaden zu JSON-LD-Schema für SEOs — SALT.agency — ein praktischer Leitfaden zu Syntax und Implementierung, der sich an SEOs richtet.

Änderungsprotokoll