Eine Entwicklerin öffnet den Page-Source einer gut rankenden Unternehmensseite und stößt im Head-Bereich auf einen Block, der mit <script type="application/ld+json"> beginnt und mit geschweiften Klammern, Namen und URLs gefüllt ist. Kein sichtbarer Inhalt, kein Styling, trotzdem erkennt Google an dieser Stelle die Organisation, den Gründer und das Logo als Entität. Genau diese Notation heißt JSON-LD und beantwortet die Frage was ist JSON-LD direkt am lebenden Beispiel.
Für Teams, die in klassischer Suche und in KI-Antwortsystemen sichtbar sein wollen, ist JSON-LD die zentrale technische Brücke zwischen Content und maschineller Interpretation. Dieser Glossareintrag klärt Definition, Syntax, Abgrenzung zu Microdata und RDFa, die wichtigsten Schema-Typen und die Rolle, die JSON-LD im GEO-Stack einer Marke spielt.
Was bedeutet JSON-LD genau?
JSON-LD steht für JavaScript Object Notation for Linked Data und ist ein vom W3C standardisiertes Format, mit dem Webseiten strukturierte Daten in Form von maschinenlesbaren Entitäten und deren Beziehungen auszeichnen. Der Standard wurde 2014 als W3C Recommendation veröffentlicht und 2020 in Version 1.1 aktualisiert (W3C, 2020). Mehr dazu in unserem was ist ChatGPT Search.
Co-Autor des Standards ist Manu Sporny, der JSON-LD als leichtgewichtige Brücke zwischen klassischem JSON und dem Semantic Web konzipiert hat. Deutsche Fachquellen wie Sistrix und t3n verwenden den Begriff unverändert (Sistrix, 2026).
JSON-LD ist kein Inhaltsformat, sondern ein Metadaten-Format. Es beschreibt nicht, was Nutzer sehen, sondern was die Seite semantisch bedeutet. Für eine Produktseite liefert es Name, Hersteller, Preis und Verfügbarkeit als getypte Datenfelder, die Google, Bing und Sprachmodelle direkt auslesen.
Google empfiehlt JSON-LD seit 2015 als bevorzugtes Format für strukturierte Daten, vor Microdata und RDFa. Diese Empfehlung steht seitdem unverändert in der Google Search Central Dokumentation und ist in der Praxis zum De-facto-Standard geworden (Google Search Central, 2025).
Wie ist ein JSON-LD-Block aufgebaut?
Ein JSON-LD-Block besteht aus drei Grundbausteinen: dem Kontext über @context, dem Typ über @type und den Eigenschaften der Entität. Diese Dreiteilung ist das semantische Gerüst jeder Auszeichnung. Unser was ist Conversational Commerce erklärt die Details.
Der Kontext verweist auf ein Vokabular, in nahezu allen SEO- und GEO-Anwendungen auf https://schema.org. Der Typ benennt die Entität, etwa Organization, Article oder Product. Die Eigenschaften beschreiben die konkreten Attribute, etwa Name, URL, Gründungsdatum oder Autor.
Ein vollständiges Beispiel für eine Organization-Auszeichnung sieht so aus:
Der Block liegt im Head- oder Body-Bereich und wird nicht gerendert. Er ist ausschließlich für Maschinen sichtbar, insbesondere für Suchmaschinen-Crawler und LLM-Trainingsprozesse. Details zu verlinkten Begriffen innerhalb solcher Blöcke vertieft unser Glossareintrag zu DefinedTerm.
Wie grenzt sich JSON-LD von Microdata und RDFa ab?
Für strukturierte Daten existieren drei gängige Notationen, die dasselbe Schema.org-Vokabular abbilden, sich aber stark in Wartbarkeit und Integrationsaufwand unterscheiden. Die Wahl ist keine Detailfrage, sondern prägt die technische Schuldenlast eines Projekts auf Jahre.
Format | Notation | Wartbarkeit | Google-Empfehlung | Typischer Einsatz |
|---|---|---|---|---|
JSON-LD | Separater Script-Block | Hoch, getrennt von Markup | Bevorzugt | Moderne CMS, Headless-Stacks |
Microdata | Inline in HTML-Tags | Mittel, an Layout gekoppelt | Unterstützt | Legacy-Shops, statische Seiten |
RDFa | Inline in HTML-Attributen | Niedrig, schwer lesbar | Unterstützt | Akademische, bibliografische Daten |
Der entscheidende Vorteil von JSON-LD ist die Entkopplung. Während Microdata und RDFa die strukturierten Daten direkt in das sichtbare HTML verweben, liegt JSON-LD als geschlossener Block vor. Änderungen am Layout brechen die Auszeichnung nicht, und Teams aus Marketing und Entwicklung können parallel arbeiten, ohne sich im Template zu blockieren.
Für KI-Crawler ist JSON-LD außerdem robuster auszulesen. Ein einzelner Block mit klaren Schlüssel-Wert-Paaren lässt sich verlässlicher parsen als Inline-Attribute.
Welche Schema-Typen sind im Alltag am wichtigsten?
Schema.org definiert mehrere hundert Typen, im Alltag einer Website dominieren aber etwa zehn davon rund neunzig Prozent der Einsätze. Wer diese Typen sauber setzt, deckt die meisten Rich-Result- und Entity-Signale ab.
Organization. Beschreibt das Unternehmen selbst, mit Name, Logo, Gründer, Kontaktdaten und Social-Profilen. Der Einstiegspunkt jeder Brand-Entity im Knowledge Graph.
Person. Auszeichnung für Autoren, Gründer, Experten. Zentral für E-E-A-T-Signale und für die Verknüpfung von Content mit belegbarer Urheberschaft. Wie sich das in der Praxis zeigt, beschreibt unser Beitrag zu E-E-A-T und KI.
Article. Für Blog- und Magazin-Inhalte, inklusive Headline, Autor, Veröffentlichungsdatum und Cover-Bild. Grundlage für News-Boxen und für die korrekte Zuordnung in generativen Antworten.
Product. Taucht auf Produktseiten auf und liefert Preis, Bewertung und Verfügbarkeit. In Verbindung mit AggregateRating der sichtbarste Rich-Result-Typ im E-Commerce und im B2B-SaaS.
FAQPage. Strukturiert Frage-Antwort-Abschnitte und ist eines der stärksten Signale für AI Overviews und ChatGPT-Zitationen, weil die Frage-Antwort-Paare direkt in das Antwortformat der Modelle passen.
HowTo und Recipe. Für Schritt-für-Schritt-Inhalte mit klar benannten Arbeitsschritten, Zutaten oder benötigten Werkzeugen. Ergänzend zu klassischem Text liefern sie strukturierte Schritte an Assistenten aus.
BreadcrumbList. Gibt die hierarchische Position einer Seite innerhalb der Site-Struktur an. Hilft Suchmaschinen, den Kontext einer URL zu verstehen, ohne die Navigation erraten zu müssen.
Event und LocalBusiness. Zwei spezifische Typen für Veranstalter und für Unternehmen mit physischen Standorten. Beide schalten eigene Karten- und Listen-Features in klassischen Ergebnisseiten frei.
Warum ist JSON-LD für GEO relevant?
JSON-LD ist nicht länger nur ein SEO-Thema, sondern eine zentrale Infrastrukturebene für GEO-Sichtbarkeit. Sprachmodelle nutzen strukturierte Daten in drei distinct Phasen, und jede Phase verändert die Sichtbarkeit einer Marke in generativen Antworten.
In der Trainingsphase fließen Web-Archive wie Common Crawl in die Modelle ein. Seiten mit sauberem JSON-LD liefern dem Modell getypte Entitäten statt unstrukturierten Fließtext. Das erleichtert korrekte Entity-Embeddings und reduziert Verwechslungen mit ähnlich klingenden Marken.
In der Retrieval-Phase greifen Answer-Crawler wie OAI-SearchBot oder PerplexityBot live auf Seiten zu. Strukturierte Daten helfen, schnell zu entscheiden, ob eine Seite zur Nutzerfrage passt, welchen Typ sie hat und welche konkreten Attribute zitierfähig sind. Grundlagen dazu vertieft unser Glossareintrag zu Semantic Search.
In der Antwortphase formatieren Modelle häufig Listen, Produktkarten oder FAQ-Abschnitte direkt aus JSON-LD-Attributen. Wer FAQPage oder Product sauber auszeichnet, sieht seine eigenen Felder öfter wörtlich in Antworten auftauchen.
Für Entity-Based SEO ist JSON-LD das wichtigste technische Signal überhaupt. Ohne strukturierte Daten bleibt eine Marke für Modelle ein Textfragment, mit JSON-LD wird sie zur benannten Entität mit eindeutigen Attributen. Tiefer geht unser Beitrag zu LLMO.
Wie wird JSON-LD praktisch ausgespielt?
JSON-LD lässt sich aus Template-Systemen, Headless-CMS-Feldern oder serverseitigen Funktionen heraus rendern. Die technische Umsetzung ist weniger schwierig als die saubere Datenquelle.
In WordPress übernehmen Plugins wie Yoast oder RankMath die Ausgabe. In Headless-Stacks wird der Script-Block direkt im Layout-Component gerendert, mit Inhalten aus der CMS-API.
Ein Praxispunkt aus unserer eigenen Erfahrung mit Framer. Framer strippt <script>-Tags aus CMS-Textfeldern automatisch, JSON-LD landet dadurch nie im ausgelieferten HTML. Die saubere Lösung ist die Custom-Code-Funktion auf Projekt- oder Seitenebene, in die der Script-Block direkt eingefügt wird. Wer das übersieht, wundert sich über fehlende Rich Results trotz scheinbar korrekter Auszeichnung.
Die Validierung läuft über den Rich Results Test von Google und den Schema Markup Validator von Schema.org. Beide Tools zeigen Parsing-Fehler und Typkonflikte in Sekunden. Jede Änderung gehört durch beide Tools, bevor sie live geht.
Gängige Irrtümer über JSON-LD
Irrtum 1: JSON-LD ersetzt guten Content. Falsch. JSON-LD beschreibt Inhalte, es erzeugt sie nicht. Eine dünne Seite mit perfektem Schema rankt nicht besser als eine dünne Seite ohne Schema. Strukturierte Daten verstärken starken Content, sie retten keinen schwachen.
Irrtum 2: JSON-LD hilft nur für Rich Results. Falsch. Rich Results sind der sichtbarste Effekt, aber nur ein Teil des Nutzens. Entity Recognition, Knowledge-Graph-Einträge, saubere Trainingsdaten für LLMs und bessere Retrieval-Entscheidungen in AI Overviews hängen ebenfalls an strukturierten Daten. Wer nur auf Snippets optimiert, unterschätzt die eigentliche Reichweite.
Irrtum 3: Mehr Schema-Typen sind besser. Falsch. Relevant ist die passende Auszeichnung, nicht die maximale. Falsche oder übertriebene Typen können zu manuellen Penalties führen, wenn Google sie als Spam-Signal wertet. Jeder Typ braucht einen echten Bezug zum Seiteninhalt.
Irrtum 4: JSON-LD kann sichtbar von gerendertem Content abweichen. Falsch. Google bestraft strukturierte Daten, die nicht dem sichtbaren Inhalt entsprechen. Eine Bewertung im Schema, die auf der Seite nicht existiert, ist ein klarer Verstoß gegen die Structured Data Guidelines und wird regelmäßig abgestraft (Google Search Central, 2025).
FAQ: Häufig gestellte Fragen
Was ist JSON-LD in einem Satz?
JSON-LD ist ein W3C-standardisiertes Format, das strukturierte Daten in einem separaten Script-Block auf Webseiten einbettet und Suchmaschinen sowie Sprachmodelle die semantische Bedeutung der Inhalte maschinenlesbar mitteilt (W3C, 2020).
Ist JSON-LD dasselbe wie Schema.org?
Nein. Schema.org ist das Vokabular, also die Sammlung der Typen und Eigenschaften, JSON-LD ist die Notation, in der dieses Vokabular auf der Seite eingebunden wird. Beide arbeiten zusammen und werden in der Praxis oft synonym verwendet, sind technisch aber zwei Ebenen.
Muss ich JSON-LD selbst schreiben oder gibt es Generatoren?
Generatoren wie der Schema Markup Generator von Merkle oder integrierte CMS-Plugins erzeugen Standardblöcke zuverlässig. Für komplexere Typen, etwa verschachtelte Person-Organization-Artikel-Strukturen, empfiehlt sich die manuelle Pflege mit anschließender Validierung über den Rich Results Test.
Hilft JSON-LD beim Ranking in ChatGPT und Perplexity?
Ja, indirekt. Strukturierte Daten erleichtern Entity-Identifikation in Trainingsdaten und Retrieval, was die Chance auf korrekte Zitationen und Markennennungen in generativen Antworten erhöht. Ein direkter Ranking-Faktor wie bei Google existiert nicht, aber die Signalwirkung ist belegbar.
Wo füge ich JSON-LD auf meiner Seite ein?
Der Script-Block gehört klassisch in den Head-Bereich, funktioniert aber auch im Body. Wichtig ist, dass er vollständig im ausgelieferten HTML enthalten ist, bei clientseitigem Rendering also nach der Hydration nicht verloren geht. Für Framer-Projekte ist die Custom-Code-Funktion der richtige Weg.
---
Die Frage was ist JSON-LD lässt sich in einem Satz beantworten, das W3C-standardisierte Format für strukturierte Daten, das als separater Script-Block Entitäten und ihre Beziehungen für Suchmaschinen und Sprachmodelle maschinenlesbar macht. Für Marken heißt das, JSON-LD nicht als technische Pflichtaufgabe zu behandeln, sondern als Infrastrukturebene für klassische Suche und GEO gleichermaßen, mit sauberer Datenquelle, passenden Schema-Typen und konsequenter Validierung. Wir bei rankprompt.de planen, implementieren und auditieren JSON-LD-Setups entlang der kompletten Entity-Strategie einer Marke. Der praktische Einstieg führt über unsere GEO-Content-Anleitung.
