Analyser maintenant →
Fundamental structured data

JSON-LD

Auch bekannt als: JavaScript Object Notation for Linked Data


Aktualisiert 2026-05-03 · von Marco Biner

1. Kurzdefinition

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.

2. Ausführliche Erklärung

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.

3. 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.

4. Typische Fehler & Missverständnisse

5. Best Practices

6. Fakten


Definition von Marco Biner · Certified GEO Expert

Marco Biner — Founder geoquality.ai, Certified GEO Expert

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.


GEO Importance Rank

Wie wichtig ist dieser Begriff für Generative Engine Optimization?

92 /100
Fundamental Range 90–100

FAQs

Wo platziere ich JSON-LD im HTML?

Im <code>&lt;head&gt;</code>-Bereich der Seite, idealerweise nach den Meta-Tags. Das Format ist <code>&lt;script type="application/ld+json"&gt;{...}&lt;/script&gt;</code>. Es funktioniert auch im <code>&lt;body&gt;</code>, 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. <code>https://example.ch/team/anna</code>). Die @id ist der stabile Identifier einer Entity (z. B. <code>https://example.ch/team/anna#person</code>). 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.


Verwandte Begriffe

Eigene AI-Sichtbarkeit messen

Kostenlose SEAKT-Analyse für jede Website — Score in unter 2 Minuten.

Jetzt analysieren →