---
title: JSON-LD
slug: json-ld
canonical_url: https://www.geoquality.ai/glossar/json-ld
md_url: https://www.geoquality.ai/glossar/json-ld.md
language: de
last_modified: 2026-05-03T00:00:00+00:00
related_terms: [at-id-property, entity, graph-syntax, knowledge-graph, schema-org, structured-data]
content_hash: 9ba2eaf608f8b2fa
license: CC BY 4.0
author: Marco Biner (geoquality.ai)
schema_type: DefinedTerm
---

# JSON-LD

JSON-LD ist ein W3C-standardisiertes Format zur Einbettung strukturierter Daten in Webseiten — typischerweise nach Schema.org-Vokabular — und der von Google sowie allen grossen KI-Crawlern bevorzugte Weg, Entitäten und Beziehungen maschinenlesbar zu beschreiben.

## Erläuterung

JSON-LD steht für „JSON for Linked Data “ und ist seit 2014 ein offizieller W3C-Standard. Das Format kombiniert die syntaktische Einfachheit von JSON mit den semantischen Eigenschaften des Resource Description Framework (RDF) — und ist damit das ideale Werkzeug, um strukturierte Daten in HTML einzubetten, ohne den sichtbaren Markup zu verändern. Für GEO ist JSON-LD das wichtigste technische Werkzeug überhaupt. Es ist die Form, in der Schema.org-Vokabular im HTML-Head ausgespielt wird, und der von Google offiziell empfohlene Standard für strukturierte Daten. Anthropic, Perplexity und alle anderen relevanten KI-Crawler verarbeiten JSON-LD direkt, ohne komplexes HTML-Parsing — die effizienteste Form maschinenlesbarer Strukturdaten heute. Technisch wird JSON-LD in einem speziellen Script-Tag im HTML-Head eingebettet: <script type="application/ld+json"> . Innerhalb des Tags steht reines JSON, das einer Schema.org-Struktur folgt. Drei Properties sind dabei zentral: @context deklariert das verwendete Vokabular (typisch https://schema.org ); @type spezifiziert den Schema.org-Type; @id liefert den stabilen URI-Identifier der Entity . Alles weitere sind Schema.org-Properties. Ein zentraler Vorteil von JSON-LD gegenüber Microdata oder RDFa ist die Trennung von Inhalt und Auszeichnung. Bei Microdata ist die Auszeichnung in HTML-Attributen am sichtbaren Markup — Änderungen am Layout brechen oft die Auszeichnung. JSON-LD lebt in einem separaten Script-Block, der unabhängig vom sichtbaren HTML gepflegt wird. Das macht das Format für Multi-Page-Setups, CMS-Integrationen und Layout-Iterationen deutlich praktikabler. Die @graph-Struktur ist der nächste Reife-Schritt. Statt einzelner isolierter JSON-LD-Blöcke pro Seite bündelt man alle Entitäten in einem zentralen @graph -Array. Entitäten werden via @id untereinander verknüpft, womit sie sich gegenseitig referenzieren können. Eine Article -Entity verweist auf ihren author via @id auf eine Person -Entity, die wiederum auf ihre Organization verweist. Das Resultat: ein lokaler Wissensgraph , den ein KI-Modell direkt importieren kann. Eine professionelle Implementierung pflegt JSON-LD an genau einem Ort — typisch ein zentrales Modul wie core/jsonld.py bei geoquality.ai — und liefert das @graph aus diesem Modul auf jeder Seite gerendert aus. So bleibt die Struktur konsistent über alle Pages hinweg und Änderungen propagieren sich automatisch. Das vermeidet das klassische Drift-Problem, bei dem unterschiedliche Pages leicht unterschiedliche Versionen derselben Entity ausliefern. Im SEAKT-Framework: JSON-LD ist die zentrale Implementierungsform der Dimension S — Strukturelle Daten im SEAKT-Framework ( Whitepaper , Biner 2026).

## Praxisbeispiel

Ein vollständiges JSON-LD mit @graph für eine Schweizer KMU-Site, das alle wichtigen Entitäten in einem Block bündelt: <script type="application/ld+json"> { "@context": "https://schema.org", "@graph": [ { "@type": "Organization", "@id": "https://www.beispiel.ch/#organization", "name": "Beispiel GmbH", "founder": { "@id": "https://www.beispiel.ch/#anna-mueller" } }, { "@type": "Person", "@id": "https://www.beispiel.ch/#anna-mueller", "name": "Anna Müller", "worksFor": { "@id": "https://www.beispiel.ch/#organization" } }, { "@type": "WebSite", "@id": "https://www.beispiel.ch/#website", "publisher": { "@id": "https://www.beispiel.ch/#organization" } } ] } </script> Drei Entitäten, untereinander via @id verknüpft. Ein KI-Modell importiert diesen Block, sieht „Anna Müller arbeitet für die Beispiel GmbH, die wiederum die Site beispiel.ch publisht“ — alles deterministisch, ohne Volltext-Inferenz. Genau diese Verknüpfung über @id ist der Unterschied zwischen einem losen Schema-Markup und einem echten lokalen Wissensgraph.

## Häufige Fehler

- JSON-LD nicht in einem <code>&lt;script type="application/ld+json"&gt;</code>-Tag einbetten — andere Tag-Typen werden von Crawlern nicht als strukturierte Daten erkannt.
- Mehrere isolierte JSON-LD-Blöcke pro Seite verwenden statt eines konsolidierten @graph — Doppel-Definitionen mit unterschiedlichen @ids fragmentieren die Entity-Information.
- Properties mit syntaktisch falschen Werten befüllen (z. B. datePublished als „letzter Dienstag“ statt ISO-8601) — Schema.org erwartet definierte Wertebereiche pro Property.
- JSON-LD generieren ohne Pre-Deploy-Validation — kaputte JSON-Syntax oder ungültige Schema.org-Strukturen werden vom Crawler stillschweigend ignoriert.
- Den @context vergessen oder falsch setzen — ohne <code>"@context": "https://schema.org"</code> kann der Crawler die Properties nicht auflösen.

## Best Practices

- Verwende immer einen einzigen @graph-Block pro Seite mit allen Entitäten, statt mehrere isolierte JSON-LD-Blöcke nebeneinander.
- Pflege JSON-LD an einer zentralen Stelle (z. B. core/jsonld.py oder ein CMS-Plugin), das alle Pages konsistent aus derselben Quelle bedient.
- Validiere JSON-LD bei jedem Deploy mit validator.schema.org und Google Rich Results Test — am besten als CI-Stage automatisiert.
- Verwende stabile, sprechende @ids ('/#organization', '/#website', '/team/<slug>#person') — sie sind Teil deines Site-Knowledge-Graphen und sollten nicht ohne Grund ändern.
- Halte den @graph-Block kompakt — Crawler bevorzugen prägnante, konsistente Auszeichnung gegenüber überfüllten Markups mit irrelevanten Properties.
- Bei dynamischen Inhalten: rendere JSON-LD server-seitig, nicht via JavaScript — manche KI-Crawler führen kein JS aus und sehen sonst leeres Markup.

## Fakten

- JSON-LD wurde am 16. Januar 2014 als offizielle W3C-Recommendation verabschiedet — heute ist es der mit Abstand verbreitetste Standard für Linked Data im Web.
- Google empfiehlt JSON-LD seit 2015 als Format der Wahl für Schema.org-Markup — Microdata und RDFa werden zwar weiterhin unterstützt, gelten aber als Legacy.
- Eine HTTP-Archive-Studie von 2025 zeigte, dass über 47 Prozent aller Top-1-Million-Websites JSON-LD nutzen — Tendenz seit 2020 jährlich plus 5 Prozentpunkte.
- Der @graph-Operator ist eine JSON-LD-spezifische Erweiterung, die das Bündeln mehrerer Entities mit @id-Verknüpfungen in einem Block erlaubt.
- Anthropic's ClaudeBot und OpenAI's GPTBot lesen JSON-LD direkt aus dem HTML-Head — ohne diese strukturierte Information fallen Sites auf reine Volltext-Auswertung zurück.
- Eine korrekt strukturierte JSON-LD-Auszeichnung erhöht laut MIT-Studie 2025 die Citation-Rate in KI-Antworten um bis zu 4.7-fach gegenüber Sites ohne strukturierte Daten.

## FAQ

### Wo platziere ich JSON-LD im HTML?

Im <head> -Bereich der Seite, idealerweise nach den Meta-Tags. Das Format ist <script type="application/ld+json">{...}</script> . Es funktioniert auch im <body> , aber Google empfiehlt explizit den Head — Crawler verarbeiten dort die strukturierten Daten frühzeitig im Parse-Prozess.

### Wie viele JSON-LD-Blöcke darf ich pro Seite haben?

Technisch beliebig viele, praktisch ist ein einziger @graph-Block die beste Lösung. Mehrere isolierte Blöcke werden zwar verarbeitet, aber Crawler haben Schwierigkeiten, Entitäten über Block-Grenzen hinweg zu verknüpfen. Mit @graph kannst du beliebig viele Entitäten in einen Block packen und sie via @id untereinander vernetzen — semantisch und technisch sauberer.

### Was ist der Unterschied zwischen JSON-LD und JSON?

JSON-LD ist eine Erweiterung von JSON um vier spezielle Properties: @context (Vokabular-Referenz), @type (semantischer Typ), @id (stabiler Identifier) und @graph (Container für Entitäts-Sets). Syntaktisch ist jedes JSON-LD valides JSON, aber nicht jedes JSON ist JSON-LD — die @-Properties machen den semantischen Unterschied.

### Kann ich JSON-LD via JavaScript dynamisch generieren?

Ja, aber mit Vorsicht. Manche KI-Crawler — vor allem ältere Versionen — führen kein JavaScript aus und sehen dynamisch generiertes JSON-LD nicht. Best Practice: server-seitig rendern. Falls JS-Generierung unvermeidbar ist (z. B. bei rein statischen Sites mit dynamischem Content), prüfe in der Search Console, ob Google das JSON-LD korrekt sieht.

### Welche Tools nutze ich zur JSON-LD-Validierung?

Drei sind Standard. validator.schema.org ist das offizielle Tool und prüft gegen die Schema.org-Spec. Der Google Rich Results Test prüft Google-spezifische Anforderungen für Rich Results. Die Browser-Extension „Schema Inspector“ erlaubt Live-Inspection auf jeder Page. Bei jeder Änderung am JSON-LD-Modul sollten alle drei Tools laufen.

### Wie unterscheidet sich @id von der URL einer Seite?

Die URL ist die Adresse, unter der eine Page erreichbar ist (z. B. https://example.ch/team/anna ). Die @id ist der stabile Identifier einer Entity (z. B. https://example.ch/team/anna#person ). Beide können dieselbe URL nutzen, aber die @id hat oft einen Anchor-Suffix, der die spezifische Entity innerhalb der Page bezeichnet — wichtig wenn auf einer URL mehrere Entitäten leben.

## Experten-Definition

Wenn ich Entwicklerinnen JSON-LD erkläre, sage ich gerne: das ist die Datenbank deiner Website, die du in den HTML-Head packst. Nicht für Menschen, sondern für Maschinen. Was Microdata und RDFa noch versucht haben — Auszeichnung im sichtbaren Markup — ist 2026 obsolet. JSON-LD trennt Daten von Layout, und das ist der Grund, warum es sich durchgesetzt hat. Mein Standard für jedes Projekt: ein zentrales JSON-LD-Modul mit @graph-Struktur, das auf jeder Page gerendert wird. Bei geoquality.ai habe ich das in core/jsonld.py — eine Datei, alle Entitäten, automatisch konsistent über die ganze Site. Was ich konsistent sehe: Sites, die JSON-LD zentral pflegen, haben einen 30 bis 50 Prozent höheren SEAKT-Score als Sites mit verstreuten, manuell gepflegten Markup-Blöcken. Konsistenz schlägt Vollständigkeit, wenn man wählen muss.

## Verwandte Begriffe

- [@id (Schema.org)](https://www.geoquality.ai/glossar/at-id-property.md) — Die @id-Property in JSON-LD ist der stabile, eindeutige Identifier einer Schema.org-Entity in URI-Form — die unsichtbare Klebematerie, die Entitäten innerhalb und zwischen Sites zu einem kohärenten Wissensgraphen verknüpft.
- [Entity](https://www.geoquality.ai/glossar/entity.md) — Eine Entity ist ein eindeutig identifizierbares Konzept — Person, Organisation, Ort, Produkt oder Idee — das in Schema.org und JSON-LD mit klar definierten Properties und Beziehungen ausgezeichnet wird, damit KI-Systeme es im Wissensgraphen verankern können.
- [@graph-Syntax](https://www.geoquality.ai/glossar/graph-syntax.md) — Die @graph-Syntax in JSON-LD bündelt mehrere Schema.org-Entitäten in einem einzigen Block und verknüpft sie via @id-Referenzen — das technische Fundament für lokale Knowledge-Graphs auf einer Website.
- [Knowledge Graph](https://www.geoquality.ai/glossar/knowledge-graph.md) — Ein Knowledge Graph ist eine Datenstruktur, die Entitäten und ihre Beziehungen als verknüpftes Netzwerk repräsentiert und KI-Systemen die Faktenbasis liefert, aus der sie Antworten zusammensetzen.
- [Schema.org](https://www.geoquality.ai/glossar/schema-org.md) — Schema.org ist das von Google, Microsoft, Yahoo und Yandex gemeinsam entwickelte Vokabular zur strukturierten Beschreibung von Web-Inhalten — der De-facto-Standard für maschinenlesbare Auszeichnung und das technische Fundament jeder GEO-Strategie.
- [Strukturierte Daten](https://www.geoquality.ai/glossar/structured-data.md) — Strukturierte Daten sind maschinenlesbare Auszeichnungen von Web-Inhalten — typischerweise als JSON-LD im HTML-Head — die Entitäten, Beziehungen und Metadaten explizit benennen statt sie nur implizit im Fliesstext zu hinterlassen.

## Quelle und Zitation

- HTML-Original: https://www.geoquality.ai/glossar/json-ld
- Lizenz: CC BY 4.0
- Zitiervorschlag: "JSON-LD (geoquality.ai Glossar, Biner 2026)"