JSON-LD-Validator für strukturierte Daten
HTML oder rohes JSON-LD einfügen, um strukturierte Daten vom Typ FAQPage, BreadcrumbList und Article zu validieren. Fehlende Pflichteigenschaften und typische Fehler bei Google Rich Results werden sofort angezeigt.
Was ist der JSON-LD-Validator für strukturierte Daten
JSON-LD ist ein Markup-Format, das Google maschinenlesbar mitteilt, worum es sich bei einem Seiteninhalt tatsächlich handelt – etwa um eine FAQ, einen Artikel oder eine Breadcrumb-Navigation. Es wird als JSON innerhalb eines <script type="application/ld+json">-Tags geschrieben, sodass strukturierte Daten hinzugefügt werden, ohne das sichtbare HTML überhaupt zu berühren. Bei korrekter Umsetzung können dadurch Rich Results in der Suche freigeschaltet werden, etwa aufklappbare FAQ-Snippets oder Breadcrumb-Pfade, die die Klickrate meist auch ohne Rankingänderung verbessern.
Dieses Tool extrahiert automatisch <script>-Blöcke aus eingefügtem HTML (oder akzeptiert direkt rohes JSON-LD) und prüft jede erkannte FAQPage-, BreadcrumbList- und Article-ähnliche Entität (Article / NewsArticle / BlogPosting) gegen die von Schema.org geforderten Pflichteigenschaften. Außerdem markiert es die klassischen Fehler, die Googles Rich Results still und leise zunichtemachen – etwa wenn acceptedAnswer.text ein Objekt statt einer reinen Zeichenkette ist oder die position-Werte nicht fortlaufend sind. Wer diese Prüfung vor der Veröffentlichung oder direkt nach einer Korrektur durchführt, entdeckt solche Probleme früher, als erst später in der Search Console darauf zu stoßen.
So verwenden Sie den JSON-LD-Validator für strukturierte Daten
- HTML-Quelltext oder JSON-LD der Seite besorgen Sowohl der vollständige HTML-Quelltext (über „Seitenquelltext anzeigen") als auch nur der Inhalt eines <script>-Tags funktionieren als Eingabe.
- In das Eingabefeld einfügen oder von einer URL abrufen Sie können den Text direkt einfügen oder – bei einer bereits veröffentlichten Seite – deren URL eingeben und automatisch abrufen lassen.
- Erkannte Entitäten und deren Ergebnisse prüfen Enthält die Eingabe mehrere <script>-Blöcke oder mehrere @type-Entitäten, wird jede einzeln aufgelistet und validiert.
- Als „Fehlt" oder „Warnung" markierte Eigenschaften korrigieren Jede Eigenschaft wird mit OK, Warnung oder Fehlt gekennzeichnet, sodass Sie direkt zur entsprechenden Stelle im ursprünglichen JSON-LD springen und sie korrigieren können.
- Nach der Korrektur erneut validieren, bevor Sie veröffentlichen Fügen Sie das korrigierte JSON-LD erneut ein und bestätigen Sie, dass alle Eigenschaften OK anzeigen, bevor Sie die Änderung live schalten.
Tipps für die Nutzung
- Bei FAQPage muss acceptedAnswer.text immer eine reine Zeichenkette sein. Wird dort ein Objekt oder Array eingesetzt, kann Google Rich Results den Inhalt nicht auslesen.
- Bei BreadcrumbList sollte position eine bei 1 beginnende fortlaufende Reihe bilden. Lücken oder Duplikate verhindern, dass die Breadcrumb-Navigation korrekt erkannt wird.
- Die headline eines Article sollte etwa 110 Zeichen nicht überschreiten – das ist Googles Richtwert. Längere Überschriften können in den Suchergebnissen abgeschnitten werden.
- Sie können eine komplette HTML-Seite einfügen: Das Tool extrahiert automatisch den Inhalt jedes <script type="application/ld+json">-Blocks. Auch das reine JSON allein einzufügen funktioniert.
- Enthält eine Seite mehrere strukturierte Datenblöcke, erleichtert es die Wartung, jeden davon in einem eigenen <script>-Tag zu belassen.
Wann dieses Tool nützlich ist
FAQPage-Markup vor der Veröffentlichung prüfen
Entdecken Sie klassische Fehler wie ein falsch strukturiertes acceptedAnswer.text, die das FAQ-Rich-Snippet sonst stillschweigend verhindern, bevor Sie veröffentlichen.
Breadcrumbs nach einer Umstrukturierung der Website prüfen
Wenn sich Kategorien oder URLs ändern, bestätigen Sie in einem Durchgang, dass die position-Werte des BreadcrumbList noch in der richtigen Reihenfolge stehen.
Article-Schema eines Blogbeitrags kontrollieren
Prüfen Sie schnell, ob die headline zu lang ist oder ob author, datePublished bzw. image fehlen – die von Google für Artikel-Seiten empfohlenen Eigenschaften.
Ursache eines vom Rich-Results-Test gemeldeten Fehlers finden
Meldet Googles offizielles Tool einen Fehler, grenzen Sie hier zunächst genau ein, welche Eigenschaft betroffen ist, bevor Sie die Quelle korrigieren.
Glossar
- JSON-LD
- Eine Spezifikation zum Schreiben strukturierter Daten als JSON. Es wird als eigenständiger Block innerhalb eines <script type="application/ld+json">-Tags eingebettet, sodass an Suchmaschinen gerichtete Informationen hinzugefügt werden können, ohne das bestehende HTML-Layout zu ändern.
- Schema.org
- Ein gemeinsames Vokabular für strukturierte Daten, das gemeinsam von Google, Microsoft, Yahoo und anderen gepflegt wird. Es definiert Typen (@type) wie FAQPage oder Article sowie die jeweils unterstützten Eigenschaften.
- FAQPage
- Ein Schema.org-Typ, um Google eine Liste von Fragen und Antworten mitzuteilen. Sein mainEntity enthält ein Array von Question-Entitäten, von denen jede einen name (den Fragetext) und acceptedAnswer.text (den Antworttext) benötigt.
- BreadcrumbList
- Ein Schema.org-Typ, der eine Breadcrumb-Navigation darstellt – die Position der Seite innerhalb der Hierarchie einer Website. Sein itemListElement enthält ein Array von ListItem-Entitäten, von denen jede position, name und item benötigt.
- Rich Results
- Erweiterte Suchergebnisse, die mehr als nur einen einfachen Titel und eine Beschreibung anzeigen – etwa ein aufklappbares FAQ-Snippet oder einen Breadcrumb-Pfad – und dafür korrekt implementierte strukturierte Daten voraussetzen.
- Pflichteigenschaft
- Eine Eigenschaft, die Google benötigt, um ein bestimmtes Rich Result überhaupt anzuzeigen; fehlt sie, erscheint das Rich Result gar nicht erst. Eine empfohlene Eigenschaft ist dagegen nicht zwingend erforderlich, verbessert aber die Darstellung des Ergebnisses.
- Google Search Console
- Googles offizielles Tool zur Überwachung der Suchleistung und des Indexierungsstatus einer Website. Die Berichte „Verbesserungen" zeigen, wie Google die strukturierten Daten Ihrer veröffentlichten Seiten tatsächlich interpretiert.
Häufig gestellte Fragen
Übrigens – warum JSON-LD Microdata und RDFa abgelöst hat
JSON-LD (JSON for Linking Data) entstand Anfang der 2010er-Jahre als Linked-Data-Format, das von einer W3C-Community-Gruppe standardisiert wurde. Anders als die älteren Notationen für strukturierte Daten, Microdata und RDFa, die Markup direkt in HTML-Attribute einbetten, liegt JSON-LD vollständig innerhalb eines <script>-Tags als eigenständiger JSON-Block vor. Dadurch lassen sich strukturierte Daten hinzufügen, bearbeiten oder entfernen, ohne das umgebende HTML-Layout überhaupt anzutasten. Google begann etwa 2015, JSON-LD als empfohlenes Format zu bevorzugen, und die aktuelle Dokumentation zu Rich Results ist fast ausschließlich um die JSON-LD-Syntax herum geschrieben.
Die FAQ-Bereiche dieser Website funktionieren nach demselben Prinzip: Die Autoren schreiben jede Frage und Antwort nur einmal, und im Hintergrund wird automatisch ein passender FAQPage-JSON-LD-Block erzeugt. Der gleiche Inhalt muss also nicht zweimal von Hand gepflegt werden – einmal für das für Menschen lesbare Akkordeon und einmal für das maschinenlesbare Schema –, sodass beide nie auseinanderlaufen, wie es bei manuell doppelt gepflegtem Markup leicht passiert.
Selbst syntaktisch gültiges JSON kann bei Rich Results scheitern, wenn eine von Schema.org geforderte Eigenschaft fehlt oder eine von Google empfohlene Eigenschaft nicht gesetzt ist. Tief verschachtelte Felder wie acceptedAnswer.text sind ein klassisches Beispiel für strukturelle Fehler. Eine solche Prüfung vor der Veröffentlichung durchzuführen, deckt diese Fehler früher auf, als erst später im Bericht „Verbesserungen" der Search Console darauf zu stoßen.