Wie JSON-LD KI dabei hilft, Ihre Website zu verstehen

Jun 3, 2026 · 9 min read

Wie JSON-LD KI dabei hilft, Ihre Website zu verstehen

JSON-LD ist ein <script>-basiertes Format zur Einbettung von Schema.org-Vokabular als strukturierte, maschinenlesbare Metadaten in Ihrem HTML. Es ermöglicht Suchmaschinen und KI-Systemen, Entitäten zu identifizieren – Artikel, Organisationen, Produkte, Breadcrumbs, Personen – ohne diese aus Fließtext ableiten zu müssen. Für die Google-Suche macht korrektes JSON-LD Seiten für bestimmte Suchfunktionen qualifizierbar und hilft beim Befüllen des Knowledge Graph. Für KI-Crawler wie GPTBot, ClaudeBot und PerplexityBot gibt es eine harte Einschränkung, die Frontend-Entwickler konsequent übersehen: Diese Crawler führen kein JavaScript aus, weshalb JSON-LD in der Server-Antwort vorhanden sein muss, um sie überhaupt zu erreichen.

Dieser Artikel behandelt, was JSON-LD tatsächlich leistet, wo es hilft und wo nicht, drei praxistaugliche Beispiele, die Sie anpassen können, die Rendering-Lücke, die clientseitig injiziertes Markup für KI-Crawler unbrauchbar macht, sowie die Validierung des ausgelieferten Codes.

Die wichtigsten Erkenntnisse

JSON-LD ist Googles empfohlenes Format für strukturierte Daten und verwendet Schema.org-Vokabular, um Entitäten und ihre Beziehungen in maschinenlesbarer Form zu beschreiben.
KI-Crawler – darunter GPTBot, ClaudeBot und PerplexityBot – führen kein JavaScript aus. JSON-LD, das über useEffect, Google Tag Manager oder einen anderen clientseitigen Pfad injiziert wird, ist für sie unsichtbar.
AI Overviews und AI Mode erfordern kein KI-spezifisches Markup; es gelten dieselben Qualifikationskriterien wie für die reguläre Google-Suche, und strukturierte Daten unterstützen die Interpretation, garantieren aber keine Aufnahme.
Google hat im Mai 2026 aufgehört, FAQ-Rich-Results anzuzeigen; die Unterstützung in der Search Console und im Rich Results Test wird im Juni 2026 eingestellt. FAQPage bleibt ein gültiger Schema.org-Typ, ist aber keine sinnvolle Taktik mehr zur Steigerung von Rich Results.
Für langfristige Validierung ist validator.schema.org die sicherere Standardwahl – es prüft das vollständige Schema.org-Vokabular, während der Google Rich Results Test nur von Google unterstützte Funktionen abdeckt.

Was JSON-LD ist und warum es existiert

JSON-LD (JavaScript Object Notation for Linked Data) ist eine vom W3C standardisierte Syntax zur Darstellung von Linked Data in JSON. Im Web wird es fast ausschließlich verwendet, um Schema.org-Vokabular in einem <script type="application/ld+json">-Tag im Dokument einzubetten. Die Daten beschreiben die Entitäten einer Seite – worum es geht, wer es geschrieben hat, welche Organisation es veröffentlicht hat, wie es sich zu anderen Seiten verhält – in einer Form, die ein Parser verarbeiten kann, ohne Fließtext lesen zu müssen.

Der Grund dafür liegt im Interpretationsaufwand. Ohne strukturierte Daten muss ein Crawler ableiten, ob „Apple” auf einer Seite das Unternehmen oder die Frucht meint; ob die Autorenzeile „Jane Chen” die Verfasserin oder ein Thema des Artikels bezeichnet; ob ein Preis im Markup zum Produkt auf der Seite oder zu einem verwandten Artikel in einer Seitenleiste gehört. Schema.org versieht diese Fakten mit expliziten Typen und Eigenschaften. JSON-LD liefert sie in einem Block, der vom sichtbaren DOM entkoppelt ist – weshalb Google es gegenüber Microdata und RDFa empfiehlt: Sie können es generieren und aktualisieren, ohne das Layout anzufassen.

Einige Punkte, die präzise formuliert werden sollten: JSON-LD ist kein bestätigter Rankingfaktor in Googles dokumentierten Ranking-Systemen. Es garantiert keine Rich Results – die Qualifikation ist notwendig, aber nicht hinreichend. Es garantiert keine Aufnahme in AI Overviews oder AI Mode. Und KI-Systeme benötigen JSON-LD nicht; sie können Fließtext lesen. Was JSON-LD leistet, ist die Reduzierung des Interpretationsaufwands, was eine korrekte Interpretation wahrscheinlicher und die Fehlklassifizierung mehrdeutiger Inhalte unwahrscheinlicher macht.

Wie JSON-LD in AI Overviews und AI Mode eingebunden ist

AI Overviews und AI Mode basieren auf Googles bestehendem Suchindex. Googles veröffentlichte Richtlinien besagen, dass es kein KI-spezifisches Markup gibt – Seiten werden für KI-Funktionen durch dieselben Inhalts- und Strukturdaten-Signale qualifiziert, die auch für die reguläre Suche gelten. Wenn Ihre Seite korrekt indexiert, strukturiert und auf die Suchabsicht des Nutzers abgestimmt ist, sind die strukturierten Daten, die Sie für die Suche ausliefern, dieselben, auf die diese Funktionen zurückgreifen.

Die ehrliche Einschätzung: Strukturierte Daten helfen KI-Systemen, Ihre Inhalte korrekt zu interpretieren. Sie erkaufen keine Aufnahme in generierte Antworten. Betrachten Sie sie als Mittel zur Beseitigung von Mehrdeutigkeiten, nicht als Wachstumshebel.

Die Rendering-Lücke bei KI-Crawlern

Dies ist der technisch wichtigste Punkt für Frontend-Entwickler, der in den meisten JSON-LD-Artikeln fehlt: KI-Crawler sollten grundsätzlich als nicht-rendernde Crawler behandelt werden, weshalb strukturierte Daten in der initialen HTML-Antwort vorhanden sein müssen.

OpenAIs GPTBot ruft HTML ab und rendert kein clientseitiges JavaScript.
Anthropics ClaudeBot arbeitet als Standard-HTTP-Crawler ohne JS-Ausführung.
PerplexityBot liest ebenfalls nur rohes HTML.

Googlebot ist die Ausnahme: Es rendert JavaScript grundsätzlich in einem verzögerten Durchlauf, sodass clientseitig injiziertes JSON-LD irgendwann für die Suche verarbeitet wird. KI-Crawler holen das nicht nach. Wenn Ihr JSON-LD erst nach der Hydration existiert, ist es für die Systeme unsichtbar, über die die meisten Nutzer heute Fragen stellen.

Ein häufiges Fehlermuster in realen Frontend-Anwendungen: Ein Entwickler fügt JSON-LD in einem useEffect-Hook ein oder überträgt es via Google Tag Manager. Der Block erscheint im gerenderten DOM, der Rich Results Test (der rendert) zeigt ihn als gültig an, und das Team geht davon aus, die Aufgabe sei erledigt. Dabei sieht jeder nicht-rendernde Crawler eine HTML-Antwort ganz ohne strukturierte Daten.

Die Lösung besteht darin, den <script type="application/ld+json">-Block in die initiale Server-Antwort zu integrieren.

JSON-LD serverseitig nach Framework rendern

Framework	Wo JSON-LD platzieren
Next.js App Router	Inline `<script type="application/ld+json">` in einer Server Component oder im `other`-Feld der Metadata API
Next.js Pages Router	Inline `<script>` innerhalb von `<Head>` aus `next/head`, gerendert in `getServerSideProps`/`getStaticProps`-Pfaden
Nuxt 3	`useHead` mit einem `script`-Eintrag, aufgerufen im Server-Kontext
Astro	Inline `<script type="application/ld+json">` direkt im `.astro`-Template (standardmäßig statisch, keine JS-Ausführung erforderlich)
SvelteKit	`<svelte:head>`-Block mit dem Script, serverseitig gerendert

Das Prinzip ist Framework-übergreifend identisch: Der JSON-LD-Block muss in den Bytes vorhanden sein, die der Server zurückliefert – nicht in Bytes, die der Browser nach dem ersten Rendering hinzufügt.

Drei praxistaugliche JSON-LD-Beispiele

Die folgenden Beispiele verwenden das Schema.org-Vokabular gemäß Version 30.0, veröffentlicht am 19. März 2026.

BlogPosting (ein Untertyp von Article)

In der Schema.org-Hierarchie ist BlogPosting ein Untertyp von Article, das selbst ein Untertyp von CreativeWork ist. Die Deklaration "@type": "BlogPosting" erbt implizit alle Article-Eigenschaften – beide müssen nicht angegeben werden.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "@id": "https://openreplay.com/blog/json-ld-ai-search#article",
  "mainEntityOfPage": {
    "@type": "WebPage",
    "@id": "https://openreplay.com/blog/json-ld-ai-search"
  },
  "headline": "How JSON-LD Helps AI Understand Your Website",
  "description": "A frontend-focused guide to JSON-LD, Schema.org, and the server-rendering requirement for AI crawlers.",
  "image": "https://openreplay.com/images/blog/json-ld-ai-search.png",
  "datePublished": "2026-05-20T09:00:00-04:00",
  "dateModified": "2026-05-20T09:00:00-04:00",
  "author": {
    "@type": "Organization",
    "name": "OpenReplay Team",
    "url": "https://openreplay.com"
  },
  "publisher": {
    "@id": "https://openreplay.com/#organization"
  }
}
</script>

Verwenden Sie dies auf Seiten mit längeren Artikeln. mainEntityOfPage verknüpft den Artikel mit seiner kanonischen URL; dateModified ist relevant, weil Google es als Aktualitätssignal bei zeitkritischen Suchanfragen verwendet.

Organization

Der Typ Organization beschreibt die veröffentlichende Entität. Verwenden Sie sameAs, um auf kanonische externe Profile zu verweisen – so können Systeme Ihre Marke von anderen mit ähnlichen Namen unterscheiden.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://openreplay.com/#organization",
  "name": "OpenReplay",
  "url": "https://openreplay.com",
  "logo": {
    "@type": "ImageObject",
    "url": "https://openreplay.com/images/logo.png",
    "width": 512,
    "height": 512
  },
  "sameAs": [
    "https://github.com/openreplay",
    "https://www.linkedin.com/company/openreplay",
    "https://x.com/OpenReplayHQ"
  ]
}
</script>

Binden Sie dies einmalig seitenübergreifend ein – typischerweise im Document Head jeder Seite. Verwenden Sie die @id in anderen Schema-Blöcken wieder (wie BlogPosting.publisher oben), sodass eine einzige kanonische Organization-Definition überall referenziert statt dupliziert wird.

BreadcrumbList

BreadcrumbList beschreibt die Position der Seite in der Website-Hierarchie. Google unterstützt Breadcrumb-Rich-Results, und dieselben Daten helfen KI-Systemen, die Seitenstruktur zu verstehen.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    {
      "@type": "ListItem",
      "position": 1,
      "name": "Home",
      "item": "https://openreplay.com/"
    },
    {
      "@type": "ListItem",
      "position": 2,
      "name": "Blog",
      "item": "https://openreplay.com/blog"
    },
    {
      "@type": "ListItem",
      "position": 3,
      "name": "How JSON-LD Helps AI Understand Your Website"
    }
  ]
}
</script>

Das letzte Element lässt item weg, da es die aktuelle Seite ist. position ist 1-basiert.

Strukturierte Daten mit sichtbaren Inhalten in Einklang halten

Googles Richtlinien für strukturierte Daten sind eindeutig: Inhalte in JSON-LD müssen mit dem übereinstimmen, was auf der Seite zu sehen ist. Bewertungen auszuzeichnen, die nicht auf der Seite erscheinen, Preise, die nicht angezeigt werden, oder Autorennamen, die den sichtbaren Autorenzeilen widersprechen, birgt das Risiko einer manuellen Maßnahme. Die strukturierten Daten sollen die Seite beschreiben, nicht mit Aussagen anreichern, die im DOM nicht belegt sind.

Dies ist auch für KI-Systeme relevant. Wenn Ihr sichtbarer Text eine Sache besagt und Ihr JSON-LD eine andere, haben Sie genau die Mehrdeutigkeit erzeugt, die strukturierte Daten eigentlich auflösen sollen.

Vor der Auslieferung validieren

Zwei Tools decken den Workflow ab:

Tool	Prüft	Am besten geeignet für
Google Rich Results Test	Qualifikation für von Google unterstützte Rich-Result-Typen	Vorab-Prüfung für Article, Product, Breadcrumb usw.
Schema Markup Validator	Konformität mit dem vollständigen Schema.org-Vokabular	Allgemeine Validierung; alle Typen, die Google nicht als Rich Result anzeigt

Der Rich Results Test rendert die Seite (und sieht daher clientseitig injiziertes JSON-LD, das KI-Crawler nicht sehen). Um zu prüfen, was nicht-rendernde Crawler sehen, führen Sie curl -A "GPTBot" https://ihre-seite gegen Ihre URL aus und durchsuchen Sie die Antwort nach application/ld+json. Wenn der Block nicht im rohen HTML enthalten ist, werden KI-Crawler ihn nicht sehen.

Der Bereich „Verbesserungen” in der Google Search Console meldet Parsing-Fehler und die Qualifikation für die von Google erfassten strukturierten Datentypen. Nutzen Sie ihn für die laufende Überwachung, nicht als Ersatz für die Vorab-Validierung.

Hinweis zu FAQPage

FAQPage ist weiterhin ein gültiger Schema.org-Typ, und Google verwendet ihn nach wie vor für das Inhaltsverständnis. Allerdings weist Google in seiner FAQPage-Dokumentation darauf hin, dass FAQ-bezogene Suchfunktionen eingestellt werden: FAQ-Rich-Results sind seit Mai 2026 nicht mehr in der Suche sichtbar; die Berichterstattung in der Search Console und die Unterstützung im Rich Results Test werden im Juni 2026 eingestellt; die Search Console API folgt im August 2026. Wenn Sie Schema-Typen implementieren möchten, die aktuell sichtbare Rich-Result-Vorteile bringen, ist FAQPage nicht die richtige Wahl. Implementieren Sie es, wenn Sie eine echte FAQ-Seite haben und die Semantik festhalten möchten – nicht als Taktik zur Gewinnung von SERP-Fläche.

Dies ist auch der Grund, warum validator.schema.org für langfristige Validierungsarbeiten die sicherere Standardwahl ist: Es hängt nicht davon ab, welche Funktionen Google als Rich Results anzeigt.

Was zuerst ausgeliefert werden sollte

Wenn Sie bei null anfangen, ist die sinnvollste Reihenfolge: ein einzelner Organization-Block seitenübergreifend, BreadcrumbList auf jeder Seite außer der Startseite und Article/BlogPosting auf redaktionellen Inhalten. Rendern Sie alles serverseitig. Validieren Sie mit beiden Tools. Prüfen Sie dann die rohe HTML-Antwort mit einem nicht-rendernden User Agent, um zu bestätigen, dass KI-Crawler tatsächlich das empfangen, was Sie geschrieben haben.

Strukturierte Daten werden Rankings nicht allein verbessern und verschaffen Ihnen keinen Platz in AI Overviews. Was sie leisten – zuverlässig, wenn korrekt ausgeliefert – ist die Beseitigung des Interpretationsaufwands, der dazu führt, dass Suchmaschinen und KI-Systeme Ihre Inhalte falsch verstehen. Für Frontend-Teams ist die entscheidende Frage nicht, welche Schema-Typen hinzugefügt werden sollen, sondern an welcher Stelle der Rendering-Pipeline sie leben. Platzieren Sie JSON-LD in der Server-Antwort – der Rest ist eine Frage der Inhalte.

FAQs

Verwenden Sie JSON-LD. Google empfiehlt es ausdrücklich gegenüber Microdata und RDFa, weil es in einem einzigen Script-Block lebt, der vom sichtbaren DOM entkoppelt ist. Das bedeutet, Sie können strukturierte Daten generieren und aktualisieren, ohne das Layout-Markup anzufassen. Alle drei Formate können Schema.org-Vokabular ausdrücken und werden von Google geparst, aber JSON-LD ist einfacher zu pflegen, einfacher serverseitig zu rendern und das Format, das Google in seiner eigenen Dokumentation zu strukturierten Daten durchgängig verwendet.

Ja. Google unterstützt mehrere separate Script-Tags auf einer einzelnen Seite – das ist das Standardmuster für die Kombination von Typen wie Organization, BreadcrumbList und BlogPosting. Die Alternative ist ein einzelnes Script mit einem Graph-Array unter dem @graph-Schlüssel, bei dem jede Entität eine eigene @id erhält. Beide Ansätze sind gültig; das @graph-Muster ist übersichtlicher, wenn Entitäten sich gegenseitig über @id referenzieren, da es eine einzige kanonische Definition pro Entität beibehält.

Nur wenn das JSON-LD in der initialen Server-Antwort vorhanden ist. SPAs, die strukturierte Daten erst nach der Hydration injizieren, sind für nicht-rendernde Crawler wie GPTBot, ClaudeBot und PerplexityBot unsichtbar. Die Lösung ist serverseitiges Rendering oder statische Generierung für Seiten, die strukturierte Daten benötigen – mit Next.js, Nuxt, Astro oder SvelteKit im SSR- oder SSG-Modus –, sodass das Script-Tag in den HTML-Bytes vorhanden ist, bevor JavaScript ausgeführt wird.

Aktualisieren Sie dateModified nur, wenn sich der inhaltliche Kern des Artikels ändert – Korrekturen, neue Abschnitte, aktualisierte Fakten, überarbeitete Beispiele. Erhöhen Sie es nicht bei jedem Deploy oder für kosmetische Änderungen wie Tippfehlerbereinigungen oder Styling-Anpassungen. Google verwendet dateModified als Aktualitätssignal bei zeitkritischen Suchanfragen, und eine Anpassung ohne echte inhaltliche Änderungen widerspricht der Regel, dass strukturierte Daten mit den sichtbaren Inhalten übereinstimmen müssen – was das Risiko einer manuellen Maßnahme birgt.

Understand every bug

Uncover frustrations, understand bugs and fix slowdowns like never before with OpenReplay — the open-source session replay tool for developers. Self-host it in minutes, and have complete control over your customer data. Check our GitHub repo and join the thousands of developers in our community.