Was JSON-LD im Betrieb wirklich bedeutet
JSON-LD steht für JavaScript Object Notation for Linked Data. In der Praxis ist es der Block, den du in den Quelltext einer Seite legst, um Suchmaschinen die Bedeutung deines Inhalts maschinenlesbar mitzuteilen, vollständig getrennt vom sichtbaren HTML. Statt Attribute in deine Überschriften und Absätze zu flechten, beschreibst du die Entität in einem eigenen Skriptblock: ein Artikel, ein Produkt, ein lokales Unternehmen, eine FAQ. Genau diese Trennung von Inhalt und Daten ist der ganze Trick.
Das Format selbst ist gewöhnliches JSON, angereichert um zwei Schlüssel, die alles tragen. @context verweist auf das Vokabular, fast immer schema.org, und legt damit fest, welche Begriffe gültig sind. @type sagt, um welche Art von Ding es geht. Der Rest sind Eigenschaften, also name, author, datePublished oder price. Wer schon einmal eine API-Antwort gelesen hat, liest auch ein JSON-LD-Objekt ohne Anleitung.
Dieses Video erklärt die Grundlagen von JSON-LD und Linked Data und eignet sich als Einstieg.
Der operative Punkt: JSON-LD ist kein Ranking-Hebel im klassischen Sinn. Es bringt dir keine Position, es verändert die Darstellung. Es ist die Voraussetzung für Rich Results, also Sternebewertungen, FAQ-Aufklapper, Rezept-Karten oder erweiterte Artikel-Snippets. Diese Auszeichnung sitzt unter der allgemeinen Kategorie der strukturierten Daten, und JSON-LD ist 2026 schlicht der Standardweg, sie auszuliefern. Alles andere ist heute eine bewusste Ausnahme, kein Default.
Wie Google JSON-LD 2026 verarbeitet
Google liest das JSON-LD-Skript beim Crawlen und Rendern aus. Der Googlebot rendert JavaScript, also funktioniert auch ein Block, der erst per Skript oder über einen Tag-Manager eingefügt wird. Verlasse dich trotzdem nicht darauf. Server-seitig im HTML ausgeliefertes JSON-LD wird verlässlicher und schneller verarbeitet, weil es nicht von einer zweiten Rendering-Welle abhängt. Aus eigener Audit-Erfahrung sind die meisten «verschwundenen» Rich Results in Wahrheit Markup, das nur im gerenderten DOM existiert und beim ersten Crawl fehlt.
Gemessen wird das an zwei Stellen. Der Rich Results Test prüft ein einzelnes Dokument und zeigt, ob ein Typ für ein Rich Result in Frage kommt. Der Bericht zu Verbesserungen in der Search Console liefert die Aggregatsicht über die ganze Property: gültige Elemente, Warnungen, Fehler, getrennt nach Schema-Typ. Google empfiehlt JSON-LD in seiner offiziellen Search-Central-Dokumentation ausdrücklich als bevorzugtes Format. Das ist keine Community-Meinung, sondern dokumentierte Linie, und sie hat sich seit Jahren nicht geändert.
Eine ehrliche Einordnung gehört dazu: Strukturierte Daten garantieren kein Rich Result. Google entscheidet pro Suchanfrage, ob die angereicherte Darstellung ausgespielt wird, und nimmt sie auch wieder weg, wenn die Qualität der Seite nicht stimmt. Du lieferst die Berechtigung, nicht die Garantie. Wer Kunden ein garantiertes Snippet verspricht, verkauft Marketing-Sprech statt Substanz.
JSON-LD vs. Microdata vs. RDFa
Es gibt drei Wege, schema.org-Daten auszuzeichnen, und nur einer ist 2026 noch eine ernsthafte Empfehlung. Microdata und RDFa schreiben die Semantik direkt ins HTML, über itemprop- beziehungsweise property-Attribute an den sichtbaren Elementen. JSON-LD trennt die Daten vom Markup und legt sie in einen eigenen Block. Genau diese Trennung ist der Grund, warum es sich durchgesetzt hat.
Dieses Video hilft, den Unterschied zwischen JSON-LD und anderen Formaten einzuordnen.
Der praktische Unterschied ist Wartbarkeit. Mit Microdata bricht deine Auszeichnung, sobald ein Redakteur das Template umbaut oder ein Plugin die DOM-Struktur ändert. JSON-LD bleibt stabil, weil es nicht an der Darstellung klebt. Für komplexe, stark verschachtelte Beziehungen war RDFa theoretisch ausdrucksstärker, in der Praxis nutzt das kaum jemand, und Google verarbeitet ohnehin alle drei. Wenn du ein neues Projekt aufsetzt, gibt es keinen sachlichen Grund, etwas anderes als JSON-LD zu wählen. Microdata anzufassen lohnt sich nur, wenn du Legacy-Markup wartest, das du nicht migrieren willst.
Implementierung: wo das Script wirklich hingehört
Der JSON-LD-Block steht in einem <script type="application/ld+json">-Tag. Wohin damit? Google sagt klar, dass die Position im Dokument egal ist, <head> oder <body>, beides wird gelesen. In der Praxis legen wir es in den <head>, weil es dort sauber neben den übrigen Metadaten sitzt und beim Server-Rendering sofort vorhanden ist.
Dieses offizielle Google-Video zeigt die korrekte Platzierung des JSON-LD-Scripts auf der Seite.
Das Grundgerüst ist immer dasselbe: @context auf «https://schema.org», dann @type, dann die Eigenschaften. Ein minimaler Artikel sieht so aus:
{
"@context": "https://schema.org",
"@type": "Article",
"headline": "JSON-LD im Betrieb",
"author": { "@type": "Person", "name": "Redaktion" },
"datePublished": "2026-06-14"
}Für ein Produkt tauschst du @type gegen «Product» und ergänzt offers, price, priceCurrency und availability. Für eine FAQ nutzt du den Typ FAQPage mit einer Liste aus Frage und Antwort, ein Muster, das wir im Eintrag zu der zugrunde liegenden schema.org-Spezifikation genauer aufschlüsseln. Der Fehler, den wir am häufigsten sehen, ist nicht die Syntax, sondern fehlende Pflichteigenschaften: ein Product ohne offers wird von Google ignoriert, egal wie sauber der Rest aussieht.
Wo JSON-LD in einer SEO- und Netlinking-Operation zählt
Im Netlinking ist JSON-LD selten der Hauptdarsteller, aber ein verlässlicher Nebeneffekt. Sauber ausgezeichnete Artikel mit Article-Schema, klarem author und datePublished helfen Suchmaschinen, die Entität hinter einem Beitrag zu fassen, und das wird in der Ära der KI-Suche wichtiger, nicht weniger wichtig. Wer auf Sichtbarkeit in KI-Antworten und generativen Ergebnissen spielt, gibt den Maschinen mit strukturierten Daten ein zusätzliches, unmissverständliches Signal über Autor, Thema und Aktualität.
Für ein Mediennetzwerk wie das, das wir intern betreiben, ist konsistentes Article- und Organization-Markup über alle Titel hinweg Teil der Hygiene. Es ersetzt keine Links, aber es sorgt dafür, dass die Seiten, auf die verlinkt wird, technisch sauber lesbar sind. Wenn du planst, Beiträge in deutschsprachigen Medien zu platzieren, ist deren Schema-Qualität ein leiser, aber realer Faktor dafür, wie gut die platzierte Seite indexiert und dargestellt wird. Strukturierte Daten sind so ein stiller Baustein einer über Monate kalibrierten Linkkampagne, nicht der Hebel selbst.
Operativ messbar wird der Nutzen über die Search Console: Steigt die Zahl gültiger Elemente und tauchen Rich Results in den Performance-Daten auf, bleibt die Position oft gleich, aber die Klickrate steigt, weil das Snippet mehr Fläche und mehr Vertrauen erzeugt. Aus eigener Audit-Erfahrung liegt genau dort der Wert, nicht in einem imaginären Ranking-Bonus, den manche Tools suggerieren.
DSGVO, häufige Fehler und was wir in Audits sehen
Ein Thema, das deutschsprachige Seiten betrifft und international gern übersehen wird: Personenbezogene Daten haben im JSON-LD nichts zu suchen, wenn dafür keine Rechtsgrundlage besteht. Bewertungen mit Klarnamen, User-Generated Content, Kontaktdaten von Privatpersonen, all das landet, einmal als strukturierte Daten ausgeliefert, maschinenlesbar im Quelltext und potenziell in Suchergebnissen. Unter der DSGVO ist das ein Risiko, das du mit einer technischen Entscheidung vermeidest: zeichne Organisationen, Produkte und Inhalte aus, nicht identifizierbare Privatpersonen ohne Einwilligung.
Die wiederkehrenden Fehler aus der Audit-Praxis sind überschaubar. Erstens Markup, das eine andere Aussage trifft als die sichtbare Seite, etwa eine Sternebewertung im Schema, die nirgends auf der Seite steht. Das verstößt gegen Googles Richtlinien und kann eine manuelle Maßnahme auslösen. Zweitens fehlende Pflichtfelder, die das ganze Objekt unbrauchbar machen. Drittens mehrere widersprüchliche Blöcke auf einer Seite, oft weil ein SEO-Plugin und ein zweites Tool gleichzeitig Schema ausgeben. Validiere nach jeder Template-Änderung mit dem Rich Results Test, nicht nur einmal beim Launch.
In WordPress liefern Plugins wie Yoast oder Rank Math brauchbares Basis-Schema automatisch, in TYPO3 übernimmt das eine Extension oder eigener Code. Verlasse dich nicht blind darauf: Plugins geben oft generisches WebPage- oder Organization-Markup aus, das du für Artikel oder Produkte gezielt erweitern musst. Der ehrliche Stand 2026 ist, dass das Format trivial ist, der Inhalt der Auszeichnung aber redaktionelle und technische Sorgfalt verlangt. Wer das ernst nimmt, gewinnt saubere Snippets, wer es dem Plugin überlässt, bekommt Durchschnitt.