Agentic Relations
☰

JSON-LD

JSON-basiertes Serialisierungsformat für Linked Data, das als W3C-Standard die bevorzugte Auslieferung von Schema.org-Markup im Web ist und LLMs sowie Suchmaschinen strukturierten Zugriff auf Inhalte ermöglicht.

Definition

JSON-LD ist ein W3C-Standardformat zur Serialisierung von Linked Data in JSON-Syntax. Der Name steht für JavaScript Object Notation for Linked Data. Das Ziel der Spezifikation, erstmals 2014 als W3C-Recommendation veröffentlicht und 2020 in JSON-LD 1.1 erweitert, ist es, semantisches Web-Markup für Web-Entwickler nutzbar zu machen, ohne dass diese RDF-Tooling lernen müssen.

In der Praxis ist JSON-LD 2026 der unbestrittene Standard für Schema.org-Markup auf Webseiten. Google, Bing, Yandex und alle relevanten LLM-Crawler empfehlen JSON-LD und parsen es bevorzugt. Im Unterschied zu Microdata und RDFa ist JSON-LD vollständig vom sichtbaren HTML entkoppelt und liegt typischerweise als einzelner script-Block im head- oder body-Bereich.

Struktur und Mechanismus

Ein JSON-LD-Block ist ein script-Element mit type application/ld+json und einem JSON-Objekt als Inhalt. Drei Felder bilden den semantischen Kern:

  • @context: Die Vokabular-URL, die Property-Namen in vollständige URIs auflöst. Bei Schema.org ist das https://schema.org.
  • @type: Die Klasse der Entität, etwa Organization, Person, Article oder FAQPage.
  • @id: Eine eindeutige URI für die Entität, idealerweise eine stabile URL der eigenen Domain.

Darum herum gruppieren sich die Properties: name, url, logo, sameAs für Organisationen, headline, author, datePublished für Artikel, mainEntity mit verschachtelten Question-Objekten für FAQPages. Werte können primitiv (Text, Zahl, Datum) oder strukturiert (verschachtelte Objekte mit eigenem @type) sein.

JSON-LD unterstützt auch Graphen mehrerer Entitäten via @graph, was sinnvoll ist, wenn eine Seite mehrere Inhalte modelliert. Property-Wert-Listen erlauben mehrwertige Beziehungen, etwa mehrere sameAs-Links auf Wikidata, LinkedIn und Crunchbase.

Praxis und Anwendung

Typische Einsatzszenarien für JSON-LD im Citation-Infrastructure-Kontext:

  • Globale Identität: Ein Organization-Block im head jeder Seite mit name, url, logo, sameAs zu Wikidata, LinkedIn, Crunchbase.
  • Personen-Seiten: Person-Blocks für Autoren und Geschäftsführer mit jobTitle, affiliation, sameAs.
  • Artikelseiten: Article oder BlogPosting mit author, datePublished, dateModified, image, mainEntityOfPage.
  • FAQ-Seiten: FAQPage mit mainEntity-Liste von Question-Objekten, jeweils mit acceptedAnswer.
  • Produktseiten: Product mit offers, aggregateRating, brand, gtin.
  • Veranstaltungen: Event mit startDate, endDate, location, performer, eventStatus.
  • Breadcrumbs: BreadcrumbList für Navigation, was Rich-Result-Anzeige verbessert.

Serverseitig wird JSON-LD typischerweise als Template-Block generiert. Next.js, Nuxt und ähnliche Frameworks bieten dedizierte Komponenten oder Helper. Wichtig ist, dass das Markup zur Crawl-Zeit vollständig im HTML steht, nicht erst per Client-side-JavaScript injiziert wird. Crawler von Suchmaschinen rendern JavaScript zwar inzwischen, aber LLM-Fetcher tun das oft nicht.

Häufige Fehler

  • Ungültiges JSON: fehlende Kommas, doppelte Anführungszeichen im String, BOM-Bytes brechen den ganzen Block.
  • Falsche Datumsformate: JSON-LD und Schema.org verlangen ISO 8601, also 2026-06-07, nicht 7. Juni 2026.
  • @id mit url verwechseln: @id ist die identifizierende URI, url eine darstellbare Adresse. Beide können identisch sein, müssen es aber nicht.
  • JavaScript-only-Injection: Markup, das erst per Client-JS gesetzt wird, sehen viele LLM-Crawler nicht.
  • Mismatch zum sichtbaren Inhalt: Wer im Markup andere Inhalte deklariert als sichtbar, riskiert Manual Action durch Google.
  • Mehrfache @context-Definitionen: Pro Block ein @context, mehrere widersprüchliche Contexts führen zu Parse-Fehlern.

Abgrenzung

  • JSON: reine Datenstruktur ohne semantische Bedeutung. JSON-LD ist JSON plus @context.
  • Microdata: alternative Schema.org-Syntax, inline im HTML, weniger empfohlen.
  • RDFa: RDF-Attribute im HTML, vor allem im akademischen Web verbreitet.
  • RDF/XML: klassisches RDF-Format, fast nur in Spezialkontexten verwendet.
  • Turtle: kompakte RDF-Syntax, beliebt in der Linked-Data-Community, aber nicht web-nativ.
  • Schema.org: Vokabular, JSON-LD ist eine der drei Syntaxen, in der Schema.org ausgeliefert werden kann.

Weiter im KI-Lexikon

← Zurück zum Lexikon

Häufige Fragen

Was ist JSON-LD?+

JSON-LD (JavaScript Object Notation for Linked Data) ist ein W3C-Standard zur Serialisierung von Linked Data in JSON. Das Format erlaubt es, klassische JSON-Strukturen mit semantischer Bedeutung anzureichern, ohne dass Anwendungen, die nur JSON verstehen, daran scheitern. JSON-LD ist 2026 das dominante Format für Schema.org-Markup auf Webseiten.

Warum JSON-LD statt Microdata oder RDFa?+

Google, Bing und die meisten LLM-Crawler empfehlen explizit JSON-LD. Der Hauptgrund: JSON-LD ist vollständig vom sichtbaren HTML entkoppelt, lässt sich serverseitig generieren, lebt in einem einzigen script-Block und ist deutlich einfacher zu pflegen als Inline-Attribute. Microdata und RDFa verstreuen Markup über das gesamte Template.

Wie sieht ein JSON-LD-Block aus?+

Ein JSON-LD-Block ist ein script-Element mit type application/ld+json, das ein JSON-Objekt enthält. Drei Felder sind kanonisch: @context (Vokabular-URL, meist https://schema.org), @type (Klasse, z. B. Organization) und @id (eindeutige URI). Weitere Felder sind Properties wie name, url, sameAs.

Was bedeutet @context?+

Der @context löst Property-Namen wie name oder address in vollständige URIs auf. Wer https://schema.org als Context setzt, bedeutet damit: alle nicht-präfixierten Properties stammen aus dem Schema.org-Vokabular. Damit wird JSON-LD zu echtem Linked Data, vollständig kompatibel zu RDF und SPARQL.

Wo wird JSON-LD im HTML platziert?+

JSON-LD-Blöcke können im head- oder body-Bereich stehen. Beide sind technisch gleichwertig, head ist gängiger weil Crawler ihn früher parsen. Mehrere Blöcke auf einer Seite sind erlaubt, etwa Organization global im head und Article spezifisch im body. Vermeiden sollte man Blöcke in body-Footern, die manche Renderer abschneiden.

Welche Typen werden am häufigsten als JSON-LD ausgeliefert?+

Für Citation Infrastructure sind Organization, WebSite, WebPage, Article, FAQPage, BreadcrumbList und Person die zentralen Typen. E-Commerce ergänzt um Product und Offer, lokales Geschäft um LocalBusiness, Forschung um Dataset und ScholarlyArticle. Veranstalter nutzen Event, Recruiter JobPosting.

Wie validiere ich JSON-LD?+

Erstens syntaktisch mit einem JSON-Linter, zweitens semantisch mit Googles Rich Results Test oder dem Schema Markup Validator von Schema.org. Beide prüfen Vokabular-Konformität und Constraints. Drittens praktisch über die Google Search Console, die Markup-Probleme aus produktiven Crawls meldet. Versions-Diffs sind im CI sinnvoll.

Was sind häufige Fehler in JSON-LD?+

Erstens ungültiges JSON, etwa fehlende Kommas oder einfache Anführungszeichen. Zweitens falsche Datumsformate, JSON-LD verlangt ISO 8601. Drittens Verwechslung von @id und url, @id ist die identifizierende URI, url eine darstellbare Adresse. Viertens fehlende sameAs-Verknüpfung zu Wikidata, was die Entitätsidentität verschenkt.

Verwandte Begriffe

Quellen

  • W3C JSON-LD 1.1 Specification
  • Google Search Central
  • Schema.org Community

Wikidata: Q6108942 · Zuletzt geprüft: 2026-06-07