Strukturierte Daten

Scope und erwartetes Verhalten

Strukturierte Daten auf vier Ebenen prüfen: parsebare Syntax, gültiges Schema.org-Modell, konkrete Google-Feature-Anforderungen und Übereinstimmung mit sichtbarem Seiteninhalt. Ein Validator-PASS ist keine Ranking- oder Rich-Result-Garantie.

Dieses rule-Dokument gehört zum Cluster Grundlagen, Tests und Fehler strukturierter Daten. Die Grenze ist bewusst eng: Define the narrow rule or decision boundary for “Structured Data” in Structured Data Fundamentals Testing and Errors; exclude full implementation walkthroughs and issue-specific troubleshooting. Ziel ist eine reproduzierbare technische Entscheidung, die Entwicklung, SEO, Content, QA und normale Website-Betreiber am öffentlichen Output prüfen können.

Vor Änderungen den Sollzustand definieren: Source-Seite oder Entity, Ziel bzw. verknüpfte Entity, Page Class, Locale, gerenderter Zustand, HTTP- oder Validator-Ergebnis, Owner und erwartete Aktion. Zusätzlich einen negativen Kontrollfall festlegen, der ähnlich aussieht, aber absichtlich korrekt ist und nicht repariert werden darf.

Evidenzmodell

Evidenz zeilenorientiert speichern:

url,node_type,property,value,validator,result,visible_content,decision
beispiel,beispiel,beispiel,beispiel,beispiel,beispiel,beispiel

Rohdaten von Interpretation trennen. Bei Links exakte DOM-href-Werte, normalisierte Ziel-URL, Statuskette, Anker oder Accessible Name, Template-Position und Crawl-Zeit erfassen. Bei strukturierten Daten den gerenderten JSON-LD- oder Microdata-Block, Typ und Property, Validator, exakte Meldung und den sichtbaren Wert speichern, den das Markup beschreibt. Screenshots sind Zusatzbelege, aber kein Ersatz für reproduzierbare technische Daten.

Technische Diagnose

Alle application/ld+json-Blöcke aus dem gerenderten öffentlichen HTML extrahieren und zuerst als JSON parsen. Syntax, Schema.org-Vocabulary und Google-Feature-Regeln getrennt prüfen.

Minimaler Diagnoseblock:

{
  "@context": "https://schema.org",
  "@type": "WebPage",
  "@id": "https://example.com/page#webpage",
  "url": "https://example.com/page"
}

Typ und Properties müssen zur echten Seite passen. Wichtige Werte mit sichtbarem Content oder kanonischen Site-Daten vergleichen und den Generator dokumentieren. Theme, Plugin, Tag Manager und Anwendung können gleichzeitig valides, aber widersprüchliches Markup erzeugen. Nach Deployment immer die öffentliche URL validieren.

Für Strukturierte Daten den Fix nicht aus einem einzelnen Tool-Label ableiten. Einen betroffenen Fall, einen korrekten Kontrollfall und einen Edge Case mit identischer Methode reproduzieren. Wiederkehrendes Verhalten zur gemeinsamen Quelle zurückverfolgen: CMS-Feld, Component, Navigation, Routing, Locale-Resolver, Schema-Generator, Produktdaten oder Automation.

Themenspezifischer Abnahmetest

Für Strukturierte Daten einen eigenen Abnahmetest definieren, der dieses Thema klar von benachbarten Dokumenten trennt. Page Class oder Entity, konkrete technische Variable, Shared Source und erwarteten öffentlichen Zustand benennen. Das Ergebnis darf nicht nur aus einem Crawler-Score oder Validator-Label bestehen.

Mindestens Fehlerfall, bereits korrekten Kontrollfall und bewusste Ausnahme speziell für Strukturierte Daten prüfen. PASS ist erreicht, wenn genau dieses Verhalten reproduzierbar korrigiert wurde und die Änderung keine angrenzende Link-, Locale-, Accessibility-, Index- oder Entity-Regel unbeabsichtigt verändert.

Praxisbeispiel

Praxisfall für Strukturierte Daten: JSON-LD aus der öffentlichen Seite extrahieren, als JSON parsen, relevante Nodes und Properties mit sichtbaren Daten vergleichen und danach generische Schema-Validierung sowie den passenden Google-Test ausführen.

Das Beispiel gilt erst dann als belastbar, wenn eine zweite Person die Prüfung wiederholen kann. Vorher- und Nachher-Output speichern und den Abnahmepunkt beobachtbar machen: finaler 200-Status, direktes Ziel, erwarteter Accessible Name, stabiler Graphpfad, valides JSON, korrekte Property oder Übereinstimmung mit sichtbarem Content.

Häufige Fehlmuster

Ein Tool-Label ist nicht automatisch die Ursache. Ein 5xx-Ziel kann ein Serverproblem statt eines Linkfehlers sein; eine Noindex-Seite kann bewusst für Nutzer verlinkt sein; eine Schema-Warnung kann optional sein; mehrere Links zur gleichen URL können eine legitime UI-Funktion haben. Das Label startet die Diagnose, entscheidet aber nicht den Fix.

Auch die Reparaturebene wird oft falsch gewählt: Tausende Seiten werden manuell editiert, obwohl ein gemeinsames Template defekt ist, oder das Ziel wird geändert, obwohl die Routing-Regel die Ursache ist. Occurrences deshalb nach Component, Route, Locale und Page Class gruppieren. Bei Structured Data gilt dasselbe für Theme, Plugin, Tag Manager und Anwendung als mögliche konkurrierende Generatoren.

Counts allein sind schlechte Erfolgskriterien. Weniger Links, Klicktiefe unter drei, null Warnings oder mehr Properties können schädliche Optimierungen fördern. Abnahme an Nutzerpfad, Crawlability, HTTP-Verhalten, semantischer Korrektheit, dokumentierten Feature-Regeln und Wartbarkeit ausrichten.

Edge Cases und Ausnahmen

Navigation, Login oder Account, Legal, Lokalisierung, Archive, Produktvarianten, Pagination, Accessibility und geschützte Ressourcen können absichtlich ungewöhnliche Muster haben. Ausnahmen mit Owner, Grund und Review-Trigger dokumentieren, statt sie dauerhaft unsichtbar aus Reports zu filtern.

Bei unsicherer Evidenz den stabilen Zustand behalten und weiter messen. Redirects, URL-Entfernung, Canonical-Änderung, große Navigationsänderung und Entity-Identität sind schwerer rückgängig zu machen als Ankertext oder eine optionale Property. Ein reversibler Test an repräsentativen Seiten ist sicherer als ein globaler Fix auf Vermutung.

Umsetzung und Handoff

Ticket mit betroffener Page Class, exaktem Vorher-Zustand, erwartetem Nachher-Zustand, Shared Source, Owner, Reviewer, Verifikationsmethode und bei Bedarf Rollback erstellen. Bei Templates repräsentative URLs aus unterschiedlichen Layouts und Locales aufnehmen. Bei Schema mindestens eine Seite testen, auf der die Entity vorhanden sein soll, und eine, auf der sie nicht erscheinen darf.

SEO erledigt ist kein ausreichender Abschluss. Der Implementierungs-Owner muss die geänderte Source of Truth benennen können; QA muss den öffentlichen Zustand ohne lokale Entwicklerumgebung reproduzieren können.

Verifikation

Nach Deployment denselben Crawl oder dieselbe Extraktion erneut ausführen. Linkkanten oder Entity-Nodes vor und nach vergleichen, HTTP-, Redirect- und Indexverhalten bestätigen, gerenderten Output prüfen und angrenzende Page Classes auf Regression testen. Eine technische PASS-Abnahme ist getrennt von späterer Performance in Impressions oder Klicks.

Für skalierbare Releases mindestens Originalfehler, korrekten Kontrollfall, bewusste Ausnahme und eine weitere Seite desselben Generators prüfen. Weicht ein Ergebnis vom Soll ab, Rollout stoppen und Ursache diagnostizieren statt eine weitere Sonderregel hinzuzufügen.

PASS / FAIL Kriterien

| Prüfung | PASS | FAIL | | --- | --- | --- | | Öffentlicher Zustand | Output und Ziel oder Entity sind reproduzierbar | Zustand existiert nur im CMS oder Source Code | | Technische Ebene | Status, href, JSON, Property oder Route sind korrekt | Tool-Label bleibt unerklärt | | Nutzerbedeutung | Link oder Markup beschreibt reale Aufgabe oder sichtbare Entity | Keyword, Score oder Warning-Cleanup treibt die Änderung | | Shared Source | wiederholtes Verhalten wird am Generator korrigiert | manuelle Einzelpatches sammeln sich | | Ausnahmen | Owner und Begründung sind dokumentiert | Ausnahmen werden still ignoriert | | Verifikation | Fehler-, Kontroll- und Edge Case bestehen | nur eine bequeme URL wird geprüft | | Regression | Locale, Accessibility, Navigation und Indexierung bleiben konsistent | der Fix erzeugt neue Fehler |

1. Exakte Page- oder Entity-Class und Nutzeraufgabe für Strukturierte Daten definieren.
2. Öffentlichen gerenderten Source, konkrete Kante oder Entity, HTTP- oder Validator-State, Locale, Datum und Owner erfassen.
3. Einen Fehlerfall mit einem bereits korrekten Kontrollfall und einem absichtlichen Edge Case vergleichen.
4. Verhalten zur kleinsten Shared Source zurückverfolgen: Content, Component, Route, Navigation, Datenmodell oder Schema-Generator.
5. Erwarteten Nachher-Zustand und reversiblen Implementierungsplan vor Production-Änderung festlegen.
6. Minimalen Fix umsetzen und nicht betroffene Links, URLs, Properties und Seitenintention unverändert lassen.
7. Dieselbe Extraktion bzw. denselben Crawl am öffentlichen Output wiederholen und Templates, Locales, Accessibility und Indexsteuerung prüfen.
8. PASS: Ergebnis ist reproduzierbar, für Nutzer sinnvoll, technisch korrekt und einer wartbaren Source of Truth zugeordnet.