by Michael Kienzler

Veröffentlicht:

Aktualisiert:

JSON-LD implementieren und validieren

JSON-LD gehört als Datenblock in den HTML-Quelltext der beschriebenen Seite. Die Implementierung startet mit den Daten, die Nutzende auf der Seite sehen: Titel, Autor, Bild, Preis, Verfügbarkeit, Adresse oder Fakten zur Seite. Aus diesen Quellen erzeugt das Template den JSON-Block und liefert ihn aus. Danach prüfen Validatoren Syntax, Schema.org-Struktur und die Eignung für Google-Funktionen.

Google empfiehlt JSON-LD für strukturierte Daten. Das Format liegt getrennt vom sichtbaren HTML in einem script-Element. Templates und Content-Management-Systeme pflegen den Datenblock zentral. Das Markup muss den Inhalt der Seite exakt abbilden.

Ziel, Voraussetzung und Grenze

Die technische Aufgabe überführt Seiteninformationen in eine maschinenlesbare Form. JSON-LD ergänzt Inhalt und HTML. Es ersetzt weder ein lesbares Dokument noch die fachliche Auswahl eines Seitentyps. Das Markup garantiert keine erweiterte Darstellung in den Suchergebnissen. Google entscheidet über Ausspielung und Rich Results nach Suchanfrage und Signalen der Seite.

Die Implementierung leistetDie Implementierung leistet nicht
Ordnet sichtbare Fakten einem Schema.org-Typ und dessen Eigenschaften zu.Erzeugt keine Inhalte, Bewertungen, Preise oder Verfügbarkeiten, die auf der Seite fehlen.
Macht die Daten im ausgelieferten HTML testbar.Garantiert weder Rich Results noch bestimmte Suchpositionen.
Vermeidet abweichende Angaben in Template, CMS und Skript.Ersetzt keine Informationsarchitektur, redaktionelle Prüfung oder On-Page-Arbeit.
Schafft eine wiederholbare Prüfkette für Änderungen am Template.Erzeugt aus einem Schema.org-Typ nicht automatisch eine Suchfunktion.

Der Beitrag Was ist Suchmaschinenoptimierung (SEO)? ordnet strukturierte Daten in die Website-Qualität ein. Die SEO-Strategie mit Audit, Roadmap und Umsetzung legt fest, welche Seitengruppen Vorrang haben.

1. Seitentyp und Ziel-Funktion festlegen

Du wählst den Typ anhand des Hauptinhalts der URL. Eine Detailseite für ein Produkt braucht andere Eigenschaften als ein Rezept, eine Veranstaltung oder ein Fachbeitrag. Prüfe zuerst in der Google Search Gallery, ob Google für den geplanten Seitentyp eine Suchfunktion unterstützt. Dort stehen die geforderten und empfohlenen Eigenschaften.

Schema.org bildet keine Liste zum pauschalen Ausfüllen. Du markierst nur Informationen, die zum Gegenstand und Zweck der Seite gehören. Google fordert, dass strukturierte Daten den sichtbaren Inhalt wahrheitsgemäß wiedergeben. Versteckte oder irreführende Angaben schließen eine Seite von Rich Results aus.

Halte die Entscheidung in einem Datenvertrag fest. Für eine Artikelseite sieht er so aus:

Feld im JSON-LDVerbindliche QuellePrüfung vor Ausgabe
headlinesichtbare H1 aus dem CMSInhalt stimmt mit der Überschrift überein
descriptionfreigegebene ZusammenfassungAussage passt zur Einleitung und zum Seitenzweck
imagefreigegebenes Artikelbildabrufbare HTTPS-URL; Bild gehört zum Beitrag
datePublished / dateModifiedVeröffentlichungs- und Änderungsdatum im CMSISO-8601-Format; Änderungsdatum nur bei inhaltlicher Überarbeitung
authorsichtbare Autorenzeile oder AutorenprofilName stimmt mit der Seite überein
mainEntityOfPagekanonische URL aus dem Routingexakt die ausgelieferte kanonische URL

Das Mapping gehört in die Template-Dokumentation oder den Code des Content-Modells. Die Redaktion benötigt für jedes Feld eine feste Datenquelle. Der Leitfaden Content Marketing und SEO-Redaktion strukturiert diese Quelldaten. Der Human-in-the-Loop-Prozess regelt die fachliche Freigabe. Das JSON-LD darf keinen abweichenden Datenstand erzeugen.

2. JSON-LD aus einer Datenquelle erzeugen

Das Seiten-Template gibt den Datenblock aus. Statische Systeme erzeugen das Markup beim Build, dynamische Systeme bei der Serverantwort. Beide Wege halten Inhalt und Markup zusammen.

Das folgende Beispiel modelliert einen Artikel. Die Platzhalter stehen für Werte aus einem geprüften Content-Modell und bilden kein Pflichtfeld-Set für jeden Seitentyp:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "@id": "https://www.beispiel.de/magazin/json-ld-implementieren/#article",
  "mainEntityOfPage": {
    "@type": "WebPage",
    "@id": "https://www.beispiel.de/magazin/json-ld-implementieren/"
  },
  "headline": "JSON-LD implementieren und validieren",
  "description": "Technische Anleitung für Ausgabe und Prüfung von JSON-LD.",
  "image": [
    "https://www.beispiel.de/media/json-ld-implementierung.jpg"
  ],
  "datePublished": "2026-09-10",
  "dateModified": "2026-09-10",
  "author": {
    "@type": "Person",
    "name": "Name der Autorin oder des Autors"
  },
  "publisher": {
    "@type": "Organization",
    "name": "Name des Unternehmens",
    "logo": {
      "@type": "ImageObject",
      "url": "https://www.beispiel.de/media/logo.png"
    }
  }
}
</script>

Unklare Werte erhalten keine leeren Zeichenketten oder erfundenen Standards. Fehlt ein gefordertes Feld, ergänzt das Team zuerst den sichtbaren Inhalt im CMS oder verzichtet auf die Suchfunktion. Korrekte Daten wiegen schwerer als viele lückenhafte Felder.

Ausgabe im Komponenten- oder Template-Code

Erzeuge das Objekt zuerst als Datenstruktur und serialisiere es genau einmal. Das verhindert Syntaxfehler, sichert korrektes Escaping und erlaubt automatisierte Tests. In einer React- oder Next.js-Komponente sieht das Muster so aus:

const articleSchema = {
  "@context": "https://schema.org",
  "@type": "Article",
  "@id": `${canonicalUrl}#article`,
  mainEntityOfPage: { "@type": "WebPage", "@id": canonicalUrl },
  headline: article.title,
  description: article.summary,
  image: article.heroImageUrl ? [article.heroImageUrl] : undefined,
  datePublished: article.publishedAt,
  dateModified: article.updatedAt,
  author: { "@type": "Person", name: article.author.name },
};

const jsonLd = JSON.stringify(articleSchema).replace(/</g, "\u003c");

export function ArticleJsonLd() {
  return (
    <script
      type="application/ld+json"
      dangerouslySetInnerHTML={{ __html: jsonLd }}
    />
  );
}

Vor der Serialisierung entfallen Eigenschaften mit dem Wert undefined. Prüfe Zeitzone und Datumsformat am CMS-Übergang. Google verarbeitet auch per JavaScript eingefügtes JSON-LD; Tests prüfen jedoch stets das gerenderte HTML. Ein im Build oder auf dem Server erzeugter Block vereinfacht die Prüfung und vermeidet Abhängigkeiten von externen Tag-Managern.

Eine @id mit kanonischer URL und Fragment kennzeichnet ein Objekt wiedererkennbar. Der Beitrag Fortgeschrittene Schema.org-Implementierung mit @graph und @id vertieft die Modellierung verknüpfter Entitätsgraphen.

3. Vor dem Deployment automatisch prüfen

Die erste Prüfung läuft im Build oder in der Testumgebung. Der Schritt stoppt fehlerhafte Sonderzeichen oder fehlende Werte vor dem Deployment.

PrüfstufeKonkrete PrüfungAbbruchkriterium
JSON-SyntaxJSON-Inhalt der application/ld+json-Blöcke parsenParser meldet Syntaxfehler
DatenvertragPflichtfelder, URL-Formate, Datum und sichtbare Quelldaten abgleichenWert fehlt, hat ein falsches Format oder weicht von der Quelle ab
Template-RenderingVorschau-URL abrufen und HTML-Quelltext auf den Datenblock prüfenSkript fehlt, erscheint doppelt oder enthält Platzhalter
SeitentypJe URL nur den Typ ausgeben, den der Hauptinhalt begründetTyp passt nicht zur sichtbaren Seite

Richte Testfälle für lange Überschriften, Anführungszeichen, fehlende Bilder, mehrere Autoren und unveröffentlichte Entwürfe ein. Diese Randfälle belegen, ob das Template sauber serialisiert.

4. Mit zwei Validatoren und der ausgelieferten URL testen

Syntax, Schema.org-Struktur und Google-Eignung bilden getrennte Prüfungen. Du nutzt den Rich Results Test und den Schema Markup Validator gegen Vorschau- und Produktions-URLs.

WerkzeugTestfrageGrenze der Aussage
Rich Results TestWelche unterstützten Rich Results leitet Google ab?Zeigt nicht, ob das gesamte Schema.org-Vokabular modelliert ist
Schema Markup ValidatorIst das Markup syntaktisch extrahierbar und wie sieht der Graph aus?Belegt nicht, ob Google die Daten für eine Suchfunktion akzeptiert
URL-Prüfung in Search ConsoleKann Google die veröffentlichte URL abrufen und parsen?Prüft keine lokalen oder noch nicht erreichbaren Deployments

Der Rich Results Test prüft Google-Funktionen. Der Schema Markup Validator liest den Daten-Graphen und findet Syntaxfehler. Beide Werkzeuge zusammen trennen allgemeine Auszeichnungsfehler von fehlenden Google-Anforderungen.

Arbeite Meldungen in dieser Reihenfolge ab:

  1. →Parsing-Fehler beheben: Ungültiges JSON, defekte URLs und falsche Datentypen korrigieren.
  2. →Pflichtangaben prüfen: Meldungen mit der Dokumentation der Google-Funktion abgleichen. Nur Angaben ergänzen, die auf der Seite sichtbar vorliegen.
  3. →Warnungen auswerten: Empfohlene Eigenschaften ergänzen, wenn eine sichtbare Quelle existiert. Warnungen rechtfertigen keine erfundenen Daten.
  4. →Abweichungen korrigieren: Content-Modell oder Template anpassen. Das Skript darf nicht von Überschrift, Bild, Preis, Autor oder Datum der Seite abweichen.

Ein bestandener Test ist das Freigabekriterium für die technische Auslieferung, kein Beleg für spätere Rich Results. Dokumentiere URL, Seitentyp, Testdatum, Befund und Ticket.

5. Nach dem Deployment überwachen und messen

Nach dem Deploy prüfst du die kanonische URL im Rich Results Test und in der URL-Prüfung der Search Console. Statusberichte in der Search Console zeigen, ob Änderungen an CDN, Template oder CMS Fehler erzeugen.

Messe die Wirkung getrennt nach Seitentyp. Dokumentiere, welche URLs wann Markup erhielten, ob der Test fehlerfrei blieb und wie sich Impressionen, Klicks und Suchanfragen entwickeln.

Technische Checkliste für den Release

  • →Der Seitentyp entspricht dem sichtbaren Hauptinhalt und einer unterstützten Google-Funktion.
  • →Jedes JSON-LD-Feld besitzt eine sichtbare oder geprüfte Datenquelle im CMS.
  • →Das Template erzeugt den Datenblock automatisch; keine manuelle JSON-Kopie im Textfeld.
  • →Das ausgelieferte HTML enthält gültiges JSON-LD ohne Platzhalter oder doppelte Knoten.
  • →Rich Results Test und Schema Markup Validator wurden für eine reale URL ausgeführt.
  • →Nach der Veröffentlichung wurden URL-Prüfung und Search Console kontrolliert.
  • →Das Skript SEO-Prüfungen mit Python automatisieren überwacht wiederkehrende Aufrufe.
  • →Änderungen an Content-Modell oder Template lösen die Tests erneut aus.

Der Hub Technisches SEO: Infrastruktur, Architektur und Jamstack ordnet strukturierte Daten in die Webarchitektur ein.

Nächster Schritt

OLDSCHOOLSEO prüft strukturierte Daten, sichtbare Inhalte und technische Ausgabe im Rahmen einer nachhaltigen Betreuung. Die Übersicht aller Leistungen steht unter Suchmaschinenoptimierung Stuttgart.

Projektanfrage per E-Mail senden · Erstgespräch mit Sandra buchen


Sandra Krone und Michael Kienzler | Seriöse Suchmaschinenoptimierung aus Stuttgart | Seit 2018

▋
Porträt von Michael Kienzler
Über den Autor: Michael Kienzler

Michael Kienzler ist Partner und Gründer von OLDSCHOOLSEO. Seine Arbeit beginnt bei der Analyse der technischen Architektur und der Daten, um daraus die Potenziale für die redaktionelle und strategische Weiterentwicklung abzuleiten.

JSON-LD implementieren und validieren | OLDSCHOOLSEO