So validieren Sie strukturierte Daten ohne Google-Tools

Die Validierung strukturierter Daten ist auf merkwürdige Weise von Google-orientierten Tools abhängig geworden. Das ist verständlich: Viele Teams fügen JSON-LD hinzu, weil sie Rich Results erreichen möchten, und die Testtools von Google sind vertraut. Aber strukturierte Daten sind kein Google-Format. Meist handelt es sich um JSON-LD mit Schema.org-Vokabular, eingebettet in HTML, interpretiert von vielen Konsumenten und gepflegt durch den eigenen Veröffentlichungsworkflow.

Wenn Sie nur durch die Brille einer Suchmaschine validieren, können Sie grundlegende Probleme übersehen: ungültiges JSON, Daten, die nach dem Rendering verschwinden, veraltete Produktpreise, widersprüchliche kanonische URLs oder Markup, das technisch gültig, aber semantisch unsinnig ist.

Ein besserer Workflow ist standardsorientiert. Validieren Sie die Daten zuerst als Daten, dann das Vokabular und anschließend die Seite so, wie sie in Produktion existiert.

Was validieren Sie eigentlich?

„Strukturierte Daten“ sind nicht eine einzige Sache. Auf den meisten Websites haben sie vier Ebenen:

1. JSON-Syntax — ist der Code parsebar?
2. JSON-LD-Modell — wird er zu sinnvollen Linked Data erweitert?
3. Schema.org-Vokabular — sind die Typen und Eigenschaften plausibel?
4. Wahrheit auf Seitenebene — stimmt das Markup mit dem überein, was Nutzer und Crawler sehen können?

Google-Tools konzentrieren sich vor allem auf die vierte Ebene plus Google-spezifische Eignung für Rich Results. Nützlich, ja. Vollständig, nein.

Zum Beispiel kann dies gültiges JSON-LD sein und trotzdem schlechte strukturierte Daten ergeben:

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "Best winter jackets",
  "datePublished": "2026-01-12",
  "author": {
    "@type": "Organization",
    "name": "Editorial Team"
  }
}

Hier ist nichts kaputt. Wenn die sichtbare Seite aber eine andere Überschrift hat, keine Autorenangabe zeigt und ein Datum der letzten Änderung enthält, das dem Markup widerspricht, haben Sie ein Qualitätsproblem und kein Syntaxproblem.

Schritt 1: Parsen Sie das JSON, bevor Sie an SEO denken

Beginnen Sie mit der langweiligen Prüfung: Lässt sich das JSON parsen?

In HTML eingebettetes JSON-LD bricht häufig wegen kleiner Template-Fehler:

• nachgestellte Kommas
• nicht maskierte Anführungszeichen in Produktnamen
• ungültige Zeilenumbrüche innerhalb von Strings
• fehlende geschweifte Klammern nach bedingten Feldern
• doppelte Script-Blöcke durch Layout-Vererbung
• CMS-Plugins, die unvollständige Objekte ausgeben

Für lokale Prüfungen brauchen Sie keine SEO-Plattform. Verwenden Sie die Werkzeuge, die bereits in Ihrem Entwicklungsstack vorhanden sind.

In JavaScript:

const blocks = [...document.querySelectorAll('script[type="application/ld+json"]')];

for (const block of blocks) {
  try {
    JSON.parse(block.textContent);
  } catch (error) {
    console.error('Invalid JSON-LD:', error.message, block);
  }
}

Extrahieren Sie in CI die Script-Inhalte aus dem gerenderten HTML und parsen Sie sie als JSON. So lassen sich viele Probleme erkennen, bevor sie die Produktion erreichen.

Der wichtige Punkt: Tun Sie dies vor jeder Schema.org-Validierung. Ein Vokabular-Validator kann nicht helfen, wenn die Daten kein gültiges JSON sind.

Schritt 2: Prüfen Sie das JSON-LD-Verhalten, nicht nur die JSON-Syntax

Gültiges JSON ist nicht automatisch gültiges JSON-LD. JSON-LD verwendet Konzepte wie @context, @type, @id und Graph-Beziehungen. Wenn diese fehlerhaft sind, können Parser Ihre Daten anders interpretieren, als Sie es beabsichtigt haben.

Bestätigen Sie mindestens:

• jeder Block hat einen passenden @context
• primäre Entitäten haben eindeutige @type-Werte
• wiederholte Entitäten verwenden stabile @id-Werte, wo es sinnvoll ist
• verschachtelte Entitäten sind logisch verbunden
• Arrays werden verwendet, wenn mehrere Werte möglich sind

Für größere Websites sind stabile Identifikatoren besonders hilfreich. Wenn Ihre Organisation in Article-, Product-, BreadcrumbList- und FAQPage-Daten erscheint, hilft dieselbe @id den Konsumenten zu verstehen, dass dies Verweise auf dieselbe Entität sind — und nicht vier voneinander unabhängige Organisationen mit demselben Namen.

Ein typisches Muster sieht so aus:

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://example.com/#organization",
  "name": "Example Ltd",
  "url": "https://example.com/"
}

Sie versuchen hier nicht, einen Validator zu beeindrucken. Sie machen Ihre Daten weniger mehrdeutig.

Schritt 3: Validieren Sie gegen das Schema.org-Vokabular

Sobald JSON und JSON-LD-Struktur solide sind, prüfen Sie das Vokabular.

Der Schema.org-Validator ist nützlich, weil er gegen Schema.org-Begriffe testet und nicht gegen die Rich-Result-Regeln einer einzelnen Suchmaschine. Er kann zeigen, ob Eigenschaften erkannt werden, ob Typen wie erwartet interpretiert werden und ob Ihre verschachtelten Strukturen sinnvoll sind.

Hier finden Sie Fehler wie:

• publishingDate statt datePublished
• imageUrl, wo image erwartet wird
• Product-Markup auf einer Kategorieliste, die kein Produkt ist
• AggregateRating ohne sinnvoll bewertetes Element
• Person, das für ein Markenkonto verwendet wird

Seien Sie vorsichtig mit Warnungen. Schema.org ist absichtlich flexibel. Ein Validator kann eine Eigenschaft erlauben, die für Ihren Anwendungsfall nicht nützlich ist, oder vor etwas warnen, das optional ist. Behandeln Sie Validierung als Hinweis, nicht als Urteil.

Eine praktische Regel: Wenn eine Eigenschaft einer Maschine hilft, die Seite genauer zu verstehen, behalten Sie sie. Wenn sie nur existiert, weil jemand sie aus einem Snippet-Generator kopiert hat, hinterfragen Sie sie.

Schritt 4: Vergleichen Sie Markup mit sichtbarem Inhalt

Suchmaschinen und andere Datenkonsumenten neigen dazu, Markup zu misstrauen, das nicht zur Seite passt. Noch wichtiger: Nutzer verdienen Konsistenz.

Vergleichen Sie für jeden strukturierten Datentyp das Markup mit der sichtbaren Seite:

Article und BlogPosting

Prüfen Sie, ob Überschrift, Autor, Veröffentlichungsdatum, Änderungsdatum, Bild und Herausgeber sichtbar oder vernünftig ableitbar sind. Wenn Sie KI-unterstützte Inhalte veröffentlichen, sollten Ihre strukturierten Daten nicht dazu verwendet werden, unklare Autorenschaft reinzuwaschen. Wir haben separat über ehrliche KI-Kennzeichnung auf einer kleinen Website geschrieben, und dasselbe Prinzip gilt hier: Metadaten sollten klären, nicht verschleiern.

Product

Prüfen Sie Name, Preis, Verfügbarkeit, Währung, Varianten, Bewertungen und Anzahl der Rezensionen. Strukturierte Produktdaten neigen besonders dazu, zu veralten, weil Preise und Lagerstatus außerhalb des CMS geändert werden.

LocalBusiness

Prüfen Sie Name, Adresse, Telefonnummer, Öffnungszeiten und Einzugsgebiet. Wenn Ihr Footer etwas anderes sagt als Ihr JSON-LD, ist das JSON-LD nicht „besser“. Es ist widersprüchlich.

BreadcrumbList

Prüfen Sie, ob Breadcrumb-Positionen mit dem sichtbaren Breadcrumb-Pfad übereinstimmen und ob URLs kanonisch, crawlbar und nicht unnötig weitergeleitet sind.

Das ist keine glamouröse Arbeit. Aber genau hier werden viele Probleme mit strukturierten Daten gefunden.

Schritt 5: Validieren Sie die gerenderte Seite, nicht Ihr Template

Viele Websites erzeugen JSON-LD über JavaScript, Tag-Manager, Personalisierungsschichten oder Komponenten-Hydration. Das bedeutet, dass die Template-Datei möglicherweise nicht das darstellt, was ein Crawler oder Browser tatsächlich sieht.

Validieren Sie das gerenderte HTML in mindestens drei Zuständen:

• lokaler Entwicklungsbuild
• Staging- oder Vorschau-URL
• Produktions-URL

Verwenden Sie die Browser-DevTools, um das finale DOM zu inspizieren. Suchen Sie nach application/ld+json und kopieren Sie den exakten Script-Inhalt, der nach dem Rendering existiert. Wenn serverseitig gerendertes Markup von hydratisiertem Markup abweicht, entscheiden Sie, welche Version Konsumenten Ihrer Erwartung nach lesen sollen.

Prüfen Sie außerdem, ob strukturierte Daten dupliziert werden. Doppelte Article- oder Product-Blöcke kommen häufig vor, wenn ein CMS-Plugin und eine eigene Komponente beide Schema ausgeben. Duplikation ist nicht immer fatal, aber widersprüchliche Duplikation ist ein Problem: zwei Preise, zwei Autoren, zwei Veröffentlichungsdaten oder zwei kanonische URLs.

Das ähnelt dem Lesen von Performance- und Diagnoseberichten: Die erste Aufgabe besteht nicht darin, in Panik zu geraten, sondern Signal von Rauschen zu trennen. Dieselbe Gewohnheit hilft, wenn Sie einen Lighthouse-Bericht lesen, ohne in Panik zu geraten — auch wenn strukturierte Daten selbst nicht auf eine einzelne Punktzahl reduziert werden sollten.

Schritt 6: Prüfen Sie Transportdetails in Produktion

Strukturierte Daten können in Ihrer Quelle perfekt sein und in Produktion trotzdem scheitern, weil die Seite nicht so zugänglich ist, wie Sie annehmen.

Prüfen Sie:

• der finale Statuscode ist 200, kein Soft 404
• die kanonische URL entspricht der Seite, die Sie validieren
• Weiterleitungen sind beabsichtigt und stabil
• Robots-Anweisungen blockieren die Indexierung nicht dort, wo Indexierung erwartet wird
• HTML wird für bestimmte User Agents nicht durch eine Fehlerseite ersetzt
• zwischengespeicherte Seiten liefern kein veraltetes JSON-LD aus

Hier ist HTTP-Inspektion wichtig. Wenn eine Produktseite über drei URLs weiterleitet, bevor sie ein kanonisches Ziel erreicht, validieren Sie die finale Seite, nicht die erste aus dem CMS kopierte URL. Für die rohen Mechaniken ist unser Leitfaden zum Debuggen von Redirects und HTTP-Headern in Produktion eine nützliche Ergänzung.

Strukturierte Daten existieren nicht im luftleeren Raum. Sie reisen mit Headern, Weiterleitungen, Caching, Canonical-Tags und Robots-Anweisungen.

Schritt 7: Fügen Sie Tests für strukturierte Daten zu Ihrem Release-Prozess hinzu

Manuelle Validierung ist für eine Seite in Ordnung. Sie skaliert nicht über Hunderte oder Tausende von URLs.

Eine einfache automatisierte Testsuite kann die teuersten Fehler abfangen:

• repräsentative URLs aus jedem Template-Typ abrufen
• alle JSON-LD-Blöcke extrahieren
• sie mit JSON.parse parsen
• erforderliche Felder für jeden Seitentyp prüfen
• prüfen, ob Datumsangaben gültige ISO-8601-Strings sind
• prüfen, ob URLs absolut und kanonisch sind
• prüfen, ob Preise und Verfügbarkeit für Produktseiten vorhanden sind
• prüfen, ob doppelte Entitäten nicht widersprüchlich sind

Sie können dies in CI für Templates und nach Zeitplan für Produktions-URLs ausführen. Das Ziel ist nicht zu beweisen, dass jedes Rich-Result-Feature erscheinen wird. Niemand außerhalb der Suchmaschine kann das versprechen. Das Ziel ist, Ihre eigenen Daten korrekt, parsebar und konsistent zu halten.

<!-- tool-cta:start -->

💡 Probiere das aus: Bevor du die Schemalogik validierst, lass dein JSON-LD durch den JSON Formatter laufen, um Syntaxfehler zu finden, die sonst jede nachgelagerte Prüfung zum Scheitern bringen würden.

<!-- tool-cta:end -->

Eine standardsorientierte Validierungs-Checkliste

Verwenden Sie diese kurze Checkliste, bevor Sie fragen, ob eine Suchmaschine die Seite mag:

• Ist jeder JSON-LD-Block gültiges JSON?
• Enthält jeder Block den richtigen @context und @type?
• Sind Schema.org-Eigenschaften korrekt geschrieben?
• Stimmt das Markup mit dem sichtbaren Inhalt überein?
• Sind Datumsangaben, Preise, Bewertungen und Verfügbarkeit aktuell?
• Sind URLs absolut, kanonisch und erreichbar?
• Ist die gerenderte Produktionsseite dieselbe Seite, die Sie getestet haben?
• Sind doppelte Entitäten beabsichtigt und widerspruchsfrei?

Wenn Sie diese Fragen mit Ja beantworten können, haben Sie den dauerhaften Teil der Arbeit mit strukturierten Daten erledigt. Suchspezifische Tests können später weiterhin nützlich sein, sollten aber die abschließende Kompatibilitätsprüfung sein — nicht das Fundament Ihres Validierungsprozesses.