Technik
JSON-LD
Kurz gesagt: JSON-LD (JavaScript Object Notation for Linked Data) ist ein W3C-Format, mit dem sich strukturierte Daten als eigener JSON-Block in eine Webseite einbetten lassen, getrennt vom sichtbaren HTML.
Was ist mit JSON-LD gemeint?
JSON-LD ist eine Serialisierung für verknüpfte Daten auf Basis von JSON. Das W3C hat Version 1.0 im Jahr 2014 und Version 1.1 am 16. Juli 2020 als Empfehlung verabschiedet. Im SEO-Alltag trägt JSON-LD fast immer das Vokabular von schema.org. Damit ist die Abgrenzung klar: JSON-LD ist das Format, schema.org das Vokabular, strukturierte Daten das Konzept. Google unterstützt daneben Microdata und RDFa, empfiehlt aber JSON-LD als in den meisten Fällen am einfachsten umzusetzendes und zu pflegendes Format.
Was du dazu wissen solltest
Ein JSON-LD-Block steht in einem Script-Element vom Typ application/ld+json, im head oder im body. Drei Schlüsselwörter tragen das System. @context legt fest, welches Vokabular gilt, meist https://schema.org. @type sagt, was beschrieben wird, etwa Organization oder Article. @id gibt einem Knoten eine eindeutige Kennung. Ein Minimalbeispiel: {"@context":"https://schema.org","@type":"Organization","@id":"https://www.example.de/#organisation","name":"Beispiel GmbH"} (eingebettet in ein Script-Element vom Typ application/ld+json).
Der eigentliche Mehrwert liegt in @id und @graph, und genau das übersehen viele Umsetzungen. Eine @id ist ein Bezeichner, keine Adresse, die aufrufbar sein muss; sie muss nur auf allen Seiten gleich bleiben. Dann kann ein Artikel auf jeder Seite per "publisher":{"@id":"https://www.example.de/#organisation"} auf dieselbe Organisation verweisen, statt sie jedes Mal neu und womöglich abweichend zu beschreiben. Mit @graph fasst du mehrere Knoten in einem Block zusammen: Website, Webseite, Organisation, Autor, Inhalt. So entsteht ein kleiner, in sich konsistenter Wissensgraph statt einer Sammlung loser Behauptungen.
Die häufigsten Fehler sind banal. Ein Komma zu viel nach dem letzten Element macht den ganzen Block ungültig. Typografische Anführungszeichen, die ein CMS beim Einfügen erzeugt, brechen die Syntax. Zwei Plugins geben parallel je eine Organization mit unterschiedlichem Namen aus. Und Angaben im Markup stimmen nicht mit der Seite überein, etwa eine Bewertung, die nirgends sichtbar ist – das werten Googles Richtlinien als Verstoß. Prüfen lässt sich all das im Schema Markup Validator, Googles Unterstützung für Rich Results im Rich Results Test.
Google kann JSON-LD auch lesen, wenn es per JavaScript nachträglich eingefügt wird. Für Crawler ohne Rendering gilt das nicht: Wer Markup nur clientseitig erzeugt, liefert es an einen Teil der KI-Crawler gar nicht aus. Serverseitige Ausgabe ist deshalb die robustere Wahl.
Aus GEO-Sicht sollte man JSON-LD weder über- noch unterschätzen. Google schreibt in seinem Leitfaden zu generativen Suchfunktionen, dass strukturierte Daten dafür nicht erforderlich sind. Der Nutzen liegt in der Eindeutigkeit: Ein Block, der Organisation, Personen und Inhalte über @id verknüpft und per sameAs auf Wikidata oder LinkedIn verweist, macht eine Entität für jede Maschine, die ihn liest, schwer verwechselbar.
Ein Beispiel aus der Praxis
Eine Zahnarztpraxis mit drei Standorten hat auf jeder Seite einen anderen JSON-LD-Block: mal Dentist, mal LocalBusiness, mal Organization, mit abweichenden Telefonnummern. Das Team legt einen zentralen @graph an, in dem die Praxisgruppe als Organization mit fester @id steht und jeder Standort als Dentist mit eigener @id und parentOrganization darauf verweist. Die Artikel des Ratgebers nennen die Gruppe als publisher über dieselbe @id.
Wenn du das nicht selbst aufbauen willst: Technik für KI-Sichtbarkeit: Crawler, Schema, llms.txt →
Was oft gefragt wird
Was ist besser, JSON-LD oder Microdata?
Für Google sind alle drei Formate gleichwertig, solange sie korrekt umgesetzt sind. JSON-LD ist in den meisten Fällen einfacher zu pflegen, weil es vom sichtbaren HTML getrennt steht und Templates nicht verändert. Google empfiehlt es deshalb als Standard.
Gehört JSON-LD in den head oder den body?
Beides funktioniert. Google liest JSON-LD im head und im body. Entscheidend ist, dass der Block im ausgelieferten HTML steht und nicht erst per JavaScript nachgeladen wird, wenn auch Crawler ohne Rendering ihn sehen sollen.
Darf eine Seite mehrere JSON-LD-Blöcke haben?
Ja, das ist zulässig. Übersichtlicher und widerspruchsfreier ist aber ein einziger Block mit @graph, in dem sich die Knoten über @id aufeinander beziehen. Mehrere Blöcke aus verschiedenen Plugins beschreiben dieselbe Organisation oft unterschiedlich.
Muss die @id eine erreichbare URL sein?
Nein. Die @id ist ein Bezeichner, der einen Knoten eindeutig macht. Üblich ist eine URL mit Fragment wie https://www.example.de/#organisation, die gar nicht aufrufbar sein muss. Wichtig ist, dass sie auf allen Seiten identisch verwendet wird.
Das hängt damit zusammen
Quellen: W3C: JSON-LD 1.1 Recommendation (Stand September 2026) · Google Search Central: Einführung in strukturierte Daten (Stand September 2026) · Google Search Central: Optimizing for generative AI features (Stand September 2026)
Wo Anbieter einen Begriff unterschiedlich verwenden, nennen wir beide Lesarten. Einen Fehler gefunden? Schreib uns, wir korrigieren ihn. Zurück zum Glossar
Wirst du in KI-Antworten genannt?30 Minuten, kostenlos, mit ehrlicher Einschätzung.
Reden wir 30 Minuten darüber
Kostenlos, unverbindlich und mit einer ehrlichen Einschätzung, ob sich GEO bei dir gerade lohnt.