Ein Schema.org Validator prüft die strukturierten Daten deiner Webseite. Für die Arbeit brauchst du zwei getrennte Antworten: Ist das Markup verständlich aufgebaut, und erfüllt es die Anforderungen einer bestimmten Google-Darstellung? Der Schema Markup Validator beantwortet die erste Frage, der Google Rich Results Test die zweite.
Diese Anleitung führt dich von der URL-Eingabe über einzelne Meldungen bis zur Prüfung einer korrigierten Vorlage. Den übergeordneten Ablauf findest du im Guide zum Testen strukturierter Daten.
Was ist ein Schema.org Validator und was prüft er?
Strukturierte Daten beschreiben den Inhalt einer Seite in maschinenlesbarer Form. Schema.org liefert dafür Begriffe wie Product, Article oder LocalBusiness und die dazugehörigen Eigenschaften. Der Validator liest das Markup aus und zeigt erkannte Objekte, Eigenschaften und Syntaxprobleme an.
Die Auszeichnung kann als JSON-LD in einem Script-Block stehen oder als Microdata beziehungsweise RDFa in HTML-Attribute eingebaut sein. Der Schema Markup Validator verarbeitet diese Formate und kann auch durch JavaScript eingefügte Daten extrahieren. Die pauschale Aussage, er sehe ausschließlich den ursprünglichen HTML-Quelltext, ist falsch. [Quelle: Schema.org, Funktionsumfang des Validators, Abruf 09.10.2026]
Ein grünes Testergebnis bestätigt allerdings weder die Wahrheit einer Preisangabe noch die Qualität eines Artikels. Dafür musst du Markup, sichtbare Seite und zugrunde liegende Daten miteinander vergleichen.
Wann fehlerhaftes Markup die Darstellung einschränkt
Fehlen erforderliche Angaben für einen unterstützten Ergebnistyp, kann Google das betroffene Element nicht als entsprechendes Rich Result berücksichtigen. Ein Rich Result ist beispielsweise ein Suchtreffer mit Produktpreis oder Veranstaltungsdaten. Das bedeutet nicht automatisch, dass die Seite aus den normalen Suchergebnissen verschwindet. [Quelle: Google, Einführung in strukturierte Daten, Abruf 09.10.2026]
Prüfe besonders Widersprüche: Stimmen Preis, Verfügbarkeit und Bewertung mit der sichtbaren Seite überein? Irreführende oder versteckte Angaben können gegen Googles Richtlinien verstoßen und eine manuelle Maßnahme gegen strukturierte Daten auslösen. [Quelle: Google, Richtlinien für strukturierte Daten, Abruf 09.10.2026]
Ein veraltetes Beispiel solltest du aus deiner Prüfliste streichen: FAQ-Rich-Results werden seit Mai 2026 nicht mehr in Google angezeigt. FAQPage bleibt ein Schema.org-Typ, ist aber kein Versprechen auf aufklappbare Fragen in der Suche. [Quelle: Google, Dokumentationsänderungen, Mai und Juni 2026]
Welches Prüfwerkzeug passt zu welcher Aufgabe?
| Frage | Schema Markup Validator | Rich Results Test | Search Console |
|---|---|---|---|
| Was wird geprüft? | Schema.org-Markup und seine Struktur | Von Google unterstützte Rich-Result-Typen | Googles erkannter Bestand und URL-Prüfung |
| Was gibst du ein? | Öffentliche URL oder Code | Öffentliche URL oder Code | URL innerhalb einer zugänglichen Property |
| Was geht vor dem Livegang? | Code aus der Vorschau prüfen | Code aus der Vorschau prüfen | Ein nicht öffentlich abrufbarer Entwurf lässt sich nicht regulär live testen |
| Was ist mit JavaScript? | Dynamisch eingefügtes Markup kann erkannt werden | Gerenderte Seite wird untersucht | Gerenderten Stand der URL-Prüfung kontrollieren |
| Wofür ist das Ergebnis gut? | Typen, Verknüpfungen und Syntax kontrollieren | Eignung eines unterstützten Elements prüfen | Nach dem Deploy Fehler und erfasste Elemente beobachten |
Quellen: Schema.org Validator, Google: strukturierte Daten und Rich-Result-Berichte, Abruf 09.10.2026.
Die Search Console ist keine vollständige Liste sämtlicher Schema.org-Objekte deiner Website. Ihre Berichte decken unterstützte Ergebnistypen ab; nicht für jeden Typ gibt es einen eigenen Bericht.
So prüfst du eine URL Schritt für Schritt
- Inhaltstyp festlegen. Beschreibt die Seite ein Produkt, einen Artikel oder eine Veranstaltung? Wähle den Typ nach dem tatsächlichen Inhalt.
- URL im Schema Markup Validator öffnen. Starte die Prüfung und klappe die erkannten Objekte auf. Kontrolliere zunächst Namen, URLs und die Zuordnung zum Seitentyp.
- Eine Meldung auswählen. Springe zur betroffenen Eigenschaft und lies den zugehörigen Wert. Notiere Objekt, Eigenschaft, Meldung und Fundstelle gemeinsam.
- Mit Schema.org abgleichen. Prüfe, ob der Typ und die Eigenschaft existieren und welcher Wertebereich erwartet wird. Eine Meldung in diesem Werkzeug ist noch keine Aussage über Googles Pflichtfelder.
- Dieselbe URL im Rich Results Test prüfen. Vergleiche die erkannten, von Google unterstützten Elemente. Öffne bei Fehlern die aktuelle Dokumentation genau dieses Ergebnistyps.
- Mit der sichtbaren Seite vergleichen. Stimmt die Produktverfügbarkeit? Verweist die Breadcrumb auf die richtige Sprachversion? Passt der Autor zum Artikel?
- An der Quelle korrigieren. Stammt der Fehler aus einer Vorlage oder einem Plugin, behebe ihn dort. Ein einzelner fehlerhafter Datensatz braucht dagegen eine Korrektur im Datensatz.
- Erneut testen und protokollieren. Prüfe nach dem Deploy die öffentliche URL. Halte Datum, Vorlagentyp, Test und noch offene Warnungen fest.
Bei einer passwortgeschützten Vorschau kopierst du den relevanten Code in die Code-Eingabe. Das prüft den eingefügten Stand, nicht automatisch die später veröffentlichte Seite. Für die Erstellung des Markups gibt es ergänzend die Anleitung zum Schema-Markup-Generator.
Fehler oder Warnung: Was musst du beheben?
Im Rich Results Test unterscheiden sich kritische Probleme von Hinweisen zu empfohlenen Angaben. Ein kritischer Fehler kann das betroffene Element für seine erweiterte Darstellung ungeeignet machen. Eine Warnung ist dagegen ein Anlass, die fehlende Angabe zu prüfen, kein Auftrag zum Erfinden von Daten. Die Bedeutung einer Meldung hängt vom Werkzeug und vom Ergebnistyp ab.
Ergänze eine Bewertung nur, wenn sie tatsächlich existiert und nach den Regeln des Ergebnistyps verwendet werden darf. Lass einen unbekannten Preis offen, statt eine Schätzung als aktuellen Angebotspreis auszugeben. Mehr ausgefüllte Felder ersetzen keine korrekten Angaben.
Typische Fehlerbilder und ihr nächster Prüfschritt
Kontext oder Typ falsch: Prüfe @context und @type. In üblichen Schema.org-JSON-LD-Blöcken bindet "@context": "https://schema.org" das Vokabular ein. Verschachtelte Objekte können diesen Kontext erben; nicht jedes Objekt braucht einen eigenen Kontext.
JSON unlesbar: Ein überzähliges Komma oder ein unmaskiertes Anführungszeichen kann den Block ungültig machen. Erzeuge JSON mit einem Serializer statt mit zusammengesetzten Textfragmenten.
Preis falsch formatiert: Trenne Preis und Währung. Bei price ist auch eine numerische Zeichenfolge wie "49.90" möglich. Verwende kein Währungssymbol im Preisfeld und prüfe zusätzlich die Google-Anforderungen an den konkreten Typ. [Quelle: Schema.org, Eigenschaft price, Abruf 09.10.2026]
Datum unpassend: Verwende das vom Feld erwartete Format. Ein Datum und ein Zeitpunkt mit Zeitzone sind unterschiedliche Angaben. Kopiere deshalb kein einheitliches Datumsformat in sämtliche Eigenschaften.
Doppelte, widersprüchliche Daten: Mehrere Blöcke sind nicht an sich falsch. Problematisch wird es, wenn Plugin und Vorlage dasselbe Objekt mit unterschiedlichen Preisen, Namen oder URLs beschreiben. Lege dafür eine maßgebliche Datenquelle fest.
Platzhalter oder fehlende Verknüpfung: Prüfe auch Seiten mit wenigen Daten. Verknüpfe zusammengehörige Objekte durch Verschachtelung oder stabile @id-Verweise, damit Produkt, Angebot und Bewertung zusammenpassen.
Ein eigener Befund: Valides JSON kann inhaltlich falsch sein
In unserem Selbstaudit vom 22.08.2026 waren auf 11 geprüften Seiten 41 JSON-LD-Blöcke syntaktisch gültig. Trotzdem führte eine Breadcrumb auf der englischen Methodikseite zur deutschen URL. Außerdem waren dort Frage-Antwort-Texte unübersetzt. [Quelle: lavcite, Selbstaudit 22.08.2026, Schema-Anhang; zugänglich über den Beispiel-Report]
Der Befund zeigt eine Grenze der Syntaxprüfung: Ein gültiger Link kann auf das falsche Ziel zeigen. Die Messung beschreibt den damaligen Stand der eigenen Website und belegt weder einen aktuellen Fehler noch einen Rankingeffekt.
Die Prüfung in den Veröffentlichungsprozess übernehmen
Lege pro Vorlage eine Referenzseite und zusätzlich einen Fall mit unvollständigen Angaben fest. Bestimme im Team, wer vor dem Deploy den Inhalt abgleicht und wer nach dem Deploy die öffentliche URL testet.
Beobachte anschließend die passenden Berichte in der Search Console. Deren Stand hängt davon ab, wann Google Änderungen verarbeitet. Eine erneut bestandene Live-Prüfung und ein noch nicht aktualisierter Bericht können deshalb nebeneinander bestehen. [Quelle: Google, Rich-Result-Berichte, Abruf 09.10.2026]
Häufige Fragen
Sind die Prüfwerkzeuge kostenlos?
Schema Markup Validator und Rich Results Test sind öffentlich ohne kostenpflichtiges Konto nutzbar. Für eigene Search-Console-Daten brauchst du Zugriff auf die betreffende Property.
Bedeutet fehlerfreies Markup, dass ein Rich Result erscheint?
Nein. Ein bestandener Test ist eine technische Voraussetzung für unterstützte Darstellungen, keine Zusage von Google. Auch die Inhaltsrichtlinien müssen erfüllt sein. [Quelle: Google, Richtlinien für strukturierte Daten, Abruf 09.10.2026]
Welches Format sollte ich verwenden?
Google unterstützt JSON-LD, Microdata und RDFa. JSON-LD wird für die meisten Fälle empfohlen, weil sich der getrennte Datenblock gut pflegen lässt. Ein Formatwechsel ist kein Selbstzweck, wenn vorhandenes Markup korrekt gepflegt wird. [Quelle: Google, unterstützte Formate, Abruf 09.10.2026]
Warum erkennt ein Test mein Markup nicht?
Prüfe zuerst Abruffehler, ungültiges JSON und blockierte Ressourcen. Vergleiche Quelltext und gerenderten Stand. Da auch der Schema Markup Validator JavaScript-Markup extrahieren kann, ist JavaScript allein keine ausreichende Erklärung.
Braucht jede Seite eigenes Markup?
Setze passende Typen dort ein, wo sie den tatsächlichen Inhalt beschreiben. Erzwinge keinen Produkttyp für eine allgemeine Informationsseite, nur um eine weitere Anzeigeform zu erreichen.
Was du nach dem Test in der Hand haben solltest
Für eine prüfbare Freigabe gehören URL, erkannte Objekte, behobene Fehler, bewusst offene Warnungen und der Inhaltsabgleich zusammen. Beginne mit einer Vorlage. Wenn ihre Angaben stimmen, prüfe weitere Seiten desselben Typs und anschließend den Stand nach Veröffentlichung.