Skip to main content

Structured Data Validator

Validate JSON-LD structured data for correct context, type and required fields.

Geprüft von · Zuletzt geprüft

Den Strukturierte-Daten-Validator verwenden

  1. Füge dein JSON-LD ein - entweder das rohe Objekt oder den vollständigen <script type="application/ld+json">...</script>-Wrapper. Der Validator entfernt das Script-Tag vor dem Parsen automatisch.
  2. Klicke auf "Formatieren", um die Eingabe schön zu formatieren, was fehlgesetzte geschweifte Klammern und nachfolgende Kommas sofort sichtbar macht.
  3. Klicke auf "Validieren" - das Tool führt eine dreistufige Prüfung durch: JSON-Syntax über JSON.parse, schema.org-Form über ein Regelwerk für bekannte Typen und Google-Rich-Result-Hinweise über ein zweites Regelwerk, das aus Googles Dokumentation abgeleitet wurde.
  4. Prüfe die Problemliste - Fehler sind blockierend (ungültiges JSON, fehlendes Pflichtfeld, falscher @context), Warnungen sind nicht blockierend (empfohlenes Feld fehlt, verdächtiges Wertformat).
  5. Korrigiere und validiere erneut - das Tool parst bei jedem Klick neu, sodass du inline iterieren kannst, bis die Fehlerliste leer ist.

Was der Validator tatsächlich prüft

Stufe eins ist das JSON-Parsen: JSON.parse in V8, SpiderMonkey oder JavaScriptCore fängt nachfolgende Kommas, nicht in Anführungszeichen gesetzte Schlüssel, einfache Anführungszeichen und andere Syntaxfehler ab, die den Block für Maschinen nicht lesbar machen. Stufe zwei prüft, ob @context einer der akzeptierten schema.org-URIs ist (https://schema.org, http://schema.org oder ein erweiterter Kontext mit schema.org als Basis). Stufe drei führt ein typspezifisches Regelwerk aus: für Product prüft es name und entweder image oder offers; für Recipe prüft es recipeIngredient, recipeInstructions und image; für Article prüft es headline (mit einem weichen Limit von 110 Zeichen gemäß Google) und author; und so weiter für die rund zwölf häufigsten Typen.

Der Validator emuliert nicht Googles vollständige Parsing-Pipeline - das würde das Replizieren von Googles proprietärem Parser erfordern, der nicht öffentlich spezifiziert ist. Was er tut, ist die Regeln zu kodieren, die Googles Rich Results Test und Schema Markup Validator öffentlich durchsetzen, sodass ein Block, der diesen Validator besteht, fast immer auch diese beiden externen Validatoren bestehen wird.

Typische Anwendungsfälle

  • Debuggen, warum das Rich Result einer Seite nach einem Inhaltsupdate verschwunden ist - oft wurde ein Pflichtfeld versehentlich durch eine Template-Bearbeitung entfernt.
  • Strukturierte Daten validieren, die von einem CMS-Plugin generiert wurden, bevor sie veröffentlicht werden, besonders wenn die Ausgabe des Plugins nicht trivial menschenlesbar ist.
  • JSON-LD, das von einem serverseitig gerenderten Framework (Next.js, Astro, Nuxt) emittiert wird, auf Übereinstimmung mit den tatsächlichen Schema-Regeln vorflug-prüfen.
  • Entwicklern, die mit schema.org nicht vertraut sind, zeigen, was als "gültig" gilt, indem ihnen strukturierte Fehlermeldungen für häufige Fehler gezeigt werden.
  • Strukturierte Daten von Wettbewerbern aus View Source einfügen und prüfen, um zu verstehen, warum deren Rich Results gerendert werden, während die eigenen es nicht tun.

Häufige JSON-LD-Fehler

  • Nachfolgende Kommas - in JavaScript-Objektliteralen seit ES2017 legal, in JSON für immer illegal. Das Kopieren einer Template-Literale aus einer JS-Datei in einen Validator erzeugt dies oft.
  • Nicht escapte Anführungszeichen in Zeichenketten - ein description-Feld mit einem Apostroph, geschrieben als "it's" innerhalb einer durch einfache Anführungszeichen begrenzten Zeichenkette, bricht das JSON.
  • Falsche @type-Großschreibung - schema.org-Typen sind PascalCase (Article, LocalBusiness). article oder ARTICLE schlägt die Validierung in einigen Parsern still fehl.
  • Daten in Nicht-ISO-Format - "datePublished": "April 22, 2026" wird als Zeichenkette geparst, schlägt aber die ISO-8601-Validierung fehl. Verwende "2026-04-22T10:30:00Z".
  • Zahlen als Zeichenketten zitiert - "price": "19.99" ist gemäß schema.org korrekt (Preise sind Zeichenketten zur Beibehaltung der Währungsformatierung), aber "ratingValue": "4.5" funktioniert nur, weil schema.org ausdrücklich Zahl oder Zeichenkette erlaubt. Einige Eigenschaften (wie width auf ImageObject) erfordern streng Zahlen.
  • Verwaiste verschachtelte Objekte ohne @type - "author": {"name": "Alice"} wird geparst, aber Google markiert es als mehrdeutig. Immer "@type": "Person" oder "@type": "Organization" einschließen.
  • Duplizierter @context auf verschachtelten Objekten - die @context-Deklaration sollte nur auf dem äußersten Objekt erscheinen; verschachtelte Objekte erben ihn.

JSON-LD und schema.org Hintergrund

JSON-LD ist eine W3C-Empfehlung (REC-json-ld-1.1), die formalisiert, wie JSON Linked-Data-Graphen mit @context, @type und @id als reservierten Schlüsselwörtern darstellen kann. schema.org ist ein separates Vokabular, das seit 2011 als gemeinsames Projekt von Google, Microsoft, Yahoo und Yandex gepflegt wird, mit vierteljährlichen Releases. Die beiden sind orthogonal: JSON-LD ist ein Serialisierungsformat; schema.org ist ein spezifisches Vokabular, das du in JSON-LD serialisieren kannst. Man könnte schema.org grundsätzlich auch in Microdata oder RDFa verwenden - das Vokabular erfordert kein JSON-LD - aber JSON-LD ist das, was Suchmaschinen am zuverlässigsten parsen. Die kanonische Referenz für jeden Typ und seine Eigenschaften findet sich unter schema.org/<TypeName>; Googles gefilterte Rich-Result-Dokumentation unter developers.google.com/search/docs/appearance/structured-data.

Alternativen und ihre Abwägungen

Googles Rich Results Test (search.google.com/test/rich-results) ist maßgeblich für Google-Rich-Result-Berechtigung - er ruft tatsächlich deine URL ab, führt Googles Parser aus und zeigt eine Vorschau des Rich Results. Der Nachteil ist, dass er eine Live-URL braucht und nur Typen abdeckt, die Google rendert. Der schema.org-Validator unter validator.schema.org führt eine strengere Vokabular-Prüfung durch, nützlich für Bing, Yandex und generische Schema-Korrektheit. Für CI/CD lassen Tools wie schema-dts (TypeScript-Typen für schema.org) strukturelle Fehler zur Kompilierzeit abfangen, bevor irgendetwas in Produktion geht. Dieser Validator gewinnt für schnelles lokales Iterieren auf rohen JSON-LD-Snippets, Validieren von Entwürfen, die noch nicht bereitgestellt sind, und Anzeigen menschenlesbarer Fehlermeldungen ohne Anmeldung bei einem Google-Konto.

Häufig gestellte Fragen

Wie unterscheidet sich das vom Google Rich Results Test?

Googles Rich Results Test ruft eine Live-URL ab, führt Googles Produktions-Parser aus und zeigt eine Vorschau des tatsächlichen Rich Results, das Google in seinen SERP rendern würde. Dieser Validator führt eine lokale Annäherung dieser Prüfungen auf einem JSON-LD-Block durch, den du einfügst - schneller, funktioniert bei Entwürfen, die noch nicht bereitgestellt sind, und erfordert keine Anmeldung. Für maßgebliche Validierung vor dem Start den Rich Results Test danach ausführen; sie ergänzen sich.

Welche schema.org-Typen werden unterstützt?

Das detaillierte Regelwerk umfasst Article, BlogPosting, NewsArticle, FAQPage, Product, Offer, AggregateRating, LocalBusiness, Organization, Person, HowTo, Recipe, Event, BreadcrumbList, WebSite, VideoObject, ImageObject und JobPosting - die Typen, die die meisten Google Rich Results antreiben. Andere schema.org-Typen bestehen grundlegende Syntax- und <code>@context</code>-Prüfungen, erhalten aber keine tiefe Feld-Validierung, da das Vokabular tausende von Typen hat und Google nur eine kleine Teilmenge zeigt.

Was ist der Unterschied zwischen einem Fehler und einer Warnung?

Fehler sind blockierend: ungültiges JSON, fehlende Pflichtfelder gemäß Googles Dokumentation, falscher <code>@context</code>-URI, falsche <code>@type</code>-Großschreibung. Seiten mit Fehlern erhalten keine Rich Results. Warnungen sind nicht blockierend: fehlende empfohlene (aber nicht erforderliche) Felder, suboptimale Formate (Daten ohne Zeitzonen), ungewöhnliche Werte. Seiten mit nur Warnungen erhalten weiterhin Rich Results, möglicherweise mit reduzierter visueller Präsenz.

Kann ich das vollständige <code>&lt;script&gt;</code>-Tag einfügen?

Ja. Der Validator erkennt den <code>&lt;script type="application/ld+json"&gt;</code>-Wrapper und entfernt ihn vor dem Parsen, sodass du direkt aus dem View Source einer anderen Seite oder aus deiner eigenen Template-Ausgabe kopieren und einfügen kannst. Enthält das Script-Tag zusätzliche Attribute (wie <code>id="product-schema"</code>), werden diese ignoriert - nur der JSON-Körper wird geparst.

Prüft das, ob meine strukturierten Daten zum sichtbaren Seiteninhalt passen?

Nein, und kein lokaler Validator kann das. Die Regel "Inhalt muss sichtbar sein" ist Googles Richtlinie und erfordert den Vergleich strukturierter Daten mit dem gerenderten Seiten-DOM, was das tatsächliche Abrufen und Rendern der Live-Seite erfordert. Dieser Validator prüft nur den JSON-Block selbst. Für die Richtlinienprüfung den Google Rich Results Test auf der Live-URL nach dem Bereitstellen verwenden.

Warum besteht mein Block hier die Validierung, schlägt aber bei Google fehl?

Zwei häufige Ursachen: Erstens ist der Block technisch gültiges JSON-LD, aber Googles Parser lehnt ihn wegen eines Richtlinienproblems ab (Inhaltskonflikte, Spam-FAQ, manipulative Bewertungen); zweitens wird der Block zur Laufzeit durch Client-seitiges JavaScript injiziert, und Googlebots Renderer erfasst es nicht. Googlebot führt jetzt JavaScript aus, ist aber langsamer und weniger zuverlässig als statisches HTML. Strukturierte Daten wann immer möglich serverseitig rendern.

Validiert der Validator jeden <code>&lt;script&gt;</code>-Block separat?

Er validiert einen Block pro Ausführung. Wenn deine Seite mehrere JSON-LD-Skripte hat (häufig - eins für Article, eins für BreadcrumbList, eins für Organization), jeden separat einfügen. Jeder Block ist unabhängig gültig oder ungültig, und Google behandelt sie als separate Entitäten, die durch gemeinsame <code>@id</code>-Werte kombiniert werden, wenn du Cross-Referenzen verwendest.

Was gilt als "Pflichtfeld"?

Anforderungen unterscheiden sich zwischen schema.org (Vokabular) und Google (Rich-Result-Berechtigung). schema.org selbst markiert Eigenschaften selten als streng erforderlich - die meisten sind "erwartet", aber optional. Googles Rich-Result-Dokumentation gibt explizite Pflichtfelder pro Feature an: für Article <code>headline</code> und <code>author</code>; für Product <code>name</code> plus entweder <code>offers</code>, <code>review</code> oder <code>aggregateRating</code>; für Recipe <code>name</code>, <code>image</code>, <code>recipeIngredient</code> und <code>recipeInstructions</code>. Dieser Validator folgt Googles Regeln.

Kann ich RDFa oder Microdata hier validieren?

Nein - dieser Validator ist nur für JSON-LD. RDFa verwendet HTML-Attribute (<code>vocab</code>, <code>typeof</code>, <code>property</code>) und Microdata einen ähnlichen Attributsatz (<code>itemscope</code>, <code>itemtype</code>, <code>itemprop</code>). Beide sind parsebar, erfordern aber ein anderes Tool. Für RDFa und Microdata sind der W3C-Destillator und Googles Structured Data Testing Tool (das alle drei Formate abdeckt) geeignet.

Sendet das Tool mein JSON an einen Server?

Nein. Das Parsen läuft in deinem Browser über <code>JSON.parse</code>, und das Regelwerk ist ein clientseitig ausgewertetes JavaScript-Objekt. Während der Validierung wird kein <code>fetch</code> oder <code>XMLHttpRequest</code> ausgelöst. Das ist wichtig für embargierte Produkteinführungen, vertrauliche Veranstaltungen und alles in deinen strukturierten Daten, das keine Drittpartei vor der Veröffentlichung sehen soll.

Warum erscheint eine Warnung für eine <code>@id</code>, die nur eine URL ist?

Eine <code>@id</code>, die der Seiten-URL entspricht, ist technisch gültig, aber oft redundant, wenn du auch <code>url</code> auf denselben Wert setzt. Die Warnung schlägt vor, <code>@id</code> als stabilen Bezeichner zu verwenden (oft eine URL mit einem Fragment wie <code>#article</code>), der sich nicht ändert, selbst wenn sich die Seiten-URL ändert, und <code>url</code> den aktuellen Standort widerspiegeln zu lassen. Nicht blockierend, nur ein Best-Practice-Hinweis.

Laufen Schema-Markierungen ab?

Die Markierung läuft nicht ab, aber die Berechtigung kann sich ändern, wenn Google seine Richtlinien aktualisiert (wie bei FAQ-Rich-Results 2023). Heute gültiges Schema kann morgen kein sichtbares Rich Result erzeugen, wenn Google die Regeln ändert.

Mehr SEO & Web Tools

Google SERP Preview

Preview how your page appears in Google search results with character count indicators.

Open tool

Heading Structure Analyzer

Extract and visualize H1-H6 heading hierarchy with SEO issue detection.

Open tool

Hreflang Tag Generator

Generate hreflang link tags for multilingual websites with x-default support.

Open tool

Keyword Density Checker

Analyze word frequency with single words, bigrams and trigrams with density percentages.

Open tool

Meta Tag Generator

Generate complete HTML meta tags including Open Graph and Twitter Card tags.

Open tool

Open Graph Preview

Preview how your page looks when shared on Facebook and LinkedIn.

Open tool