Was ist JSON-LD?

CEO & Digital Strategist

8 min geprüft am 08.08.2026

Technisches SEO

Definition

JSON-LD (JSON for Linking Data) ist das vom W3C spezifizierte Format für strukturierte Daten, das semantische Informationen über einen eigenen <script type="application/ld+json">-Block einbettet, getrennt vom sichtbaren HTML.

Ein gelochter Papierstreifen aus einem alten Leser, ohne jeden Aufdruck — daneben der Titel JSON-LD — Löcher in einem Band — die Maschine liest, was du nicht liest

Auf dieser Seite 6

Was bedeutet JSON-LD?
JSON-LD im Vergleich zu Microdata und RDFa
Wie es funktioniert
Warum es wichtig ist
Bewährte Praktiken
Häufige Fehler

Kurz gefasst

Wie ein JSON-LD-Block aufgebaut ist, warum Google es gegenüber Microdata und RDFa empfiehlt, und worin sich der Rich-Results-Test wirklich vom Schema.org-Validator unterscheidet.

Was bedeutet JSON-LD?

JSON-LD steht für JSON for Linking Data, ein Format zur Serialisierung verknüpfter Daten, das vom W3C definiert und im Juli 2020 auf Version 1.1 aktualisiert wurde. Es beschreibt den Inhalt einer Seite mit dem Vokabular von Schema.org in der Syntax von JSON, einer Sprache, die jeder Webentwickler bereits kennt.

Anders als andere Methoden steckt JSON-LD in einem eigenen <script type="application/ld+json">-Block, der im <head> oder <body> des Dokuments liegt, ohne sich mit den Tags zu vermischen, die das sichtbare Layout aufbauen. Es ist eine Form von strukturierten Daten, die Suchmaschinen dabei helfen, den Inhalt einer Seite über den reinen Fließtext hinaus zu verstehen.

Google empfiehlt JSON-LD als bevorzugtes Format, weil es laut eigener Search-Central-Dokumentation "die einfachste Lösung ist, um strukturierte Daten skalierbar zu implementieren und zu pflegen". Diese Empfehlung erklärt, warum die meisten SEO-Plugins und CMS-Systeme es standardmäßig erzeugen, selbst für einfache Fälle wie ein Rich Snippet mit Bewertungssternen, sowohl auf kleinen Websites als auch in großen Produktkatalogen.

JSON-LD im Vergleich zu Microdata und RDFa

Format	Wo der Code steht	Wartungsfreundlichkeit
JSON-LD	Eigener <script>-Block, meist im <head>	Hoch: Bearbeitung ohne Eingriff ins sichtbare HTML
Microdata	Attribute itemscope, itemtype und itemprop direkt in den HTML-Tags	Mittel: ein Layout-Wechsel kann das Markup zerstören
RDFa	Attribute vocab, typeof und property, ebenfalls im HTML verwoben	Mittel bis niedrig: umständlichere und weniger verbreitete Syntax

Der technische Kernunterschied ist die Trennung des Codes. Bei technischem SEO auf JSON-LD-Basis lässt sich das Markup erzeugen, ändern oder komplett entfernen, ohne ein einziges Tag des sichtbaren HTML anzufassen. Bei Microdata und RDFa dagegen steckt jedes Attribut im selben Tag, das den Inhalt rendert, weshalb jedes Template-Redesign auch das semantische Markup betrifft.

Wie es funktioniert

Ein JSON-LD-Block besteht aus wenigen reservierten Schlüsseln. @context gibt das verwendete Vokabular an, fast immer https://schema.org, und beseitigt Zweifel darüber, was eine Property bedeutet. @type legt fest, welche Art von Entität beschrieben wird (Article, Product, FAQPage, Organization ...), und darauf folgen die typspezifischen Properties: name, description, datePublished, price oder jede andere, die das Vokabular definiert. Diese Properties können auch verschachtelte Werte enthalten, etwa einen Autor, der als vollständiges Person-Objekt innerhalb desselben Blocks beschrieben wird, ohne dass dafür ein separates Script nötig wäre.

Eine einzelne Seite kann mehrere eigenständige <script type="application/ld+json">-Blöcke enthalten, zum Beispiel einen für den Artikel und einen für die Breadcrumb. Mehrere Entitäten lassen sich auch in einem einzigen Block über den Schlüssel @graph kombinieren, was übersichtlicher ist, wenn zwischen den Entitäten Beziehungen bestehen, etwa ein Artikel, der zu einer Organisation gehört und zugleich eine Liste häufiger Fragen enthält. Diese Variante spart zudem Ladezeit, weil der Browser nur einen Block statt mehrerer parsen muss.

Damit Google zwei Blöcke auf unterschiedlichen Seiten als dieselbe Entität erkennt, etwa das Logo und die Kontaktdaten eines Unternehmens, dient @id: eine eindeutige Kennung, meist eine URL mit Anker wie https://meinedomain.de/#organization, die auf jeder Seite mit dieser Entität wiederholt wird. So werden Duplikate vermieden und die strukturierten Daten der Website bilden ein zusammenhängendes Ganzes.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "Was ist JSON-LD?",
  "url": "https://zds.es/de/was-ist-json-ld/",
  "datePublished": "2026-08-08",
  "author": {
    "@type": "Organization",
    "@id": "https://zds.es/#organization",
    "name": "ZDS",
    "url": "https://zds.es"
  }
}
</script>

Warum es wichtig ist

JSON-LD ist die Voraussetzung dafür, dass Google ein Rich Snippet in den Suchergebnissen anzeigt: Bewertungssterne, Preise, aufklappbare Fragen oder eine visuelle Breadcrumb direkt in der SERP. Ohne korrektes Markup erscheinen diese Zusatzinformationen nicht, selbst wenn der Inhalt für Nutzer auf der Seite deutlich sichtbar ist.

Weil es vom HTML getrennt lebt, fügt sich das Markup gut in Arbeitsabläufe des technischen SEO ein: Es lässt sich dynamisch aus einem Template oder CMS erzeugen, ohne das Layout der Seite zu gefährden, und ein Entwicklungsteam kann es ändern, ohne sich mit der Pflege des sichtbaren HTML abzustimmen.

Zunehmend hilft dasselbe Markup auch generativen KI-Systemen, den Inhalt einer Seite zu verstehen, wenn sie ihn in Konversationsantworten zitieren. Das kommt zur klassischen Nutzung für Rich Results hinzu und macht JSON-LD zu einer ebenso festen technischen Aufgabe wie die Kontrolle der Core Web Vitals oder der Ladezeit einer Seite. Wer diese Pflege vernachlässigt, verliert Rich Results und macht es jedem automatisierten System schwerer, die Seite korrekt einzuordnen.

Bewährte Praktiken

Jeden Block zuerst mit dem Schema.org Validator prüfen, danach mit dem Rich Results Test: Ersterer prüft das gesamte Vokabular, Letzterer nur das, was bei Google Rich Results auslöst.
Eine konsistente @id für organization, logo und sameAs verwenden, damit Google dieselbe Entität über mehrere Seiten hinweg erkennt.
Den Block im <head> oder direkt vor dem schließenden <body> platzieren, nie doppelt innerhalb von Komponenten, die mehrfach auf derselben Seite geladen werden.
Das Markup auf das beschränken, was auf der sichtbaren Seite tatsächlich existiert: keinen Preis, keine Bewertung und keine FAQ beschreiben, die Nutzer nicht sehen können.
Das Markup nach jeder Migration oder jedem Template-Redesign prüfen, denn ein Plattformwechsel kann den <script>-Block entfernen, ohne dass sich am Layout etwas ändert, ein typischer Fehler im technischen SEO, der monatelang unbemerkt bleibt.
Dokumentieren, welchen Schema.org-Typ jedes Template verwendet, damit nicht zwei Entwickler dieselbe Angabe mit unterschiedlichen Properties abbilden.

Häufige Fehler

Einen @type deklarieren, der nicht zum tatsächlichen Seiteninhalt passt, etwa Product auf einer informativen Seite ohne Preis oder Verfügbarkeit.
Den JSON-LD-Block nach einer Content-Aktualisierung mit Daten der alten Seitenversion stehen lassen, wodurch die Angaben nicht mehr zu dem passen, was Nutzer sehen.
Einen anderen @context als https://schema.org verwenden, ohne dass es einen echten Grund dafür gibt, was die Interpretation des Markups durch Suchmaschinen erschwert.
Das Ergebnis des Rich Results Test mit einer vollständigen Validierung verwechseln: Der Test besteht, und trotzdem können Vokabularfehler bestehen, die nur der Schema.org Validator erkennt.
Denselben JSON-LD-Block in mehreren Template-Komponenten wiederholen und am Ende doppelte oder widersprüchliche Daten auf einer einzigen Seite haben.

Manuel Riveiro Rodriguez CEO & Digital Strategist

Eine technische Prüfung sieht sich das und alles Weitere in einem Durchgang an.

Audit anfragen

Häufige Fragen

Beeinflusst JSON-LD das Ranking einer Seite?

Nicht direkt. Google hat mehrfach klargestellt, dass JSON-LD-Markup für sich genommen kein Rankingfaktor ist. Es ermöglicht aber Rich Results und hilft Suchmaschinen, den Inhalt präziser zu verstehen, was die Klickrate verbessern kann, ohne die Position im Ranking direkt zu verändern.

Kann eine Seite mehrere JSON-LD-Blöcke enthalten?

Ja. Üblich ist zum Beispiel ein Block für den Artikel, einer für die Breadcrumb und einer für die Organisation. Mehrere Entitäten lassen sich auch in einem einzigen Block über den Schlüssel @graph bündeln, was übersichtlicher ist, wenn die Entitäten miteinander verknüpft sind.

Was unterscheidet den Rich Results Test vom Schema.org Validator?

Googles Rich Results Test prüft nur die Markup-Typen, die in der eigenen Suche ein Rich Result auslösen können. Der Schema.org Validator dagegen prüft das Markup gegen das gesamte offizielle Vokabular, einschließlich Typen, die Google nicht für Rich Results nutzt.

Ersetzt JSON-LD die klassischen Meta-Tags?

Nein. JSON-LD ergänzt Tags wie title oder meta description, ersetzt sie aber nicht. Suchmaschinen nutzen diese Tags weiterhin für Titel und Snippet in den Ergebnissen; JSON-LD-Markup fügt dem gleichen Inhalt eine zusätzliche semantische Ebene hinzu.

Braucht man Programmierkenntnisse, um JSON-LD einzubauen?

Das hängt vom System ab. Viele CMS und SEO-Plugins erzeugen den JSON-LD-Block automatisch aus Feldern, die ohnehin schon ausgefüllt werden. Für individuelle Fälle muss JSON-Code innerhalb des script-Tags von Hand bearbeitet werden, wobei die Syntax einfacher ist als bei Microdata oder RDFa.