Die populärste Empfehlung zum Structured Data Testing lautet oft: Markup einbauen, den Validator öffnen und so lange Fehler beheben, bis der grüne Haken erscheint. Für produktive Websites ist das zu kurz gedacht. Ein grüner Validator bedeutet zunächst nur, dass ein Tool den Code lesen kann. Er bedeutet nicht automatisch, dass Google daraus ein Rich Result erzeugt, dass der Inhalt zur Seite passt oder dass das Markup nach dem Deployment noch unverändert ausgeliefert wird.
Professionelles Testing trennt deshalb drei Fragen: Ist das Markup syntaktisch korrekt? Ist es für eine konkrete Google-Darstellung geeignet? Und bleibt es im laufenden Betrieb fachlich korrekt? Gerade im DACH-Markt mit mehrsprachigen Shops, SaaS-Plattformen und komplexen Templates entscheidet diese Trennung darüber, ob strukturierte Daten ein belastbarer Qualitätsprozess oder nur ein einmaliger Code-Check sind.
Inhaltsverzeichnis
- Warum grünes Licht im Validator nicht für Rich Results reicht
- Der zweistufige Prüfprozess für sauberes JSON-LD-Markup
- Monitoring und Fehlerbehebung nach dem Deployment
- Skalierbares Testing in CI/CD-Pipelines und SaaS-Setups
- Zukunftssichere Strategien jenseits einzelner Rich-Snippet-Features
- Messbare Business-Wirkung durch saubere Datenstrukturen
Warum grünes Licht im Validator nicht für Rich Results reicht
Der wichtigste Denkfehler besteht darin, Schema-Validierung und Rich-Result-Eignung gleichzusetzen. Ein Markup kann technisch gültig sein und trotzdem nicht für eine Google-Darstellung infrage kommen. Der Grund liegt in den unterschiedlichen Prüfregeln: Der allgemeine Schema Markup Validator betrachtet die Lesbarkeit und Struktur des schema.org-Markups, während der Rich-Results-Test Google-spezifische Voraussetzungen bewertet.
Google hat diesen Unterschied historisch deutlich gemacht. Seit dem 15. Dezember 2020 weist Google darauf hin, dass das frühere Testtool für strukturierte Daten nicht mehr prüft, ob Markup zu Rich-Suchergebnissen in der Google-Suche führt. Für die allgemeine Schemavalidierung empfiehlt Google den Schema Markup Validator für schema.org, für die Google-spezifische Prüfung dagegen den Rich-Results-Test. Für deutsche SEO-, E-Commerce- und Entwicklungsteams war das ein klarer Einschnitt: Aus einem scheinbaren Allzweck-Check wurde ein zweistufiger Prüfprozess.
Syntax ist nur die erste Qualitätsstufe
Nehmen wir eine Produktseite mit Produktname, Preis, Verfügbarkeit und Bewertung. Der Code kann gültiges JSON-LD enthalten, aber trotzdem scheitern, wenn der Preis im Markup nicht dem sichtbaren Preis entspricht, die Bewertung auf der Seite nicht nachvollziehbar ist oder der Seitentyp nicht zur tatsächlichen Nutzerhandlung passt.
Der Rich-Results-Test beantwortet deshalb nicht dieselbe Frage wie ein allgemeiner Validator. Er prüft, ob Google bestimmte strukturierte Daten für unterstützte Suchdarstellungen erkennen und bewerten kann. Auch ein positives Ergebnis ist jedoch keine Ausspielungsgarantie. Google entscheidet selbst, ob ein Rich Result für eine konkrete Suchanfrage und Seite angezeigt wird.
Praxisregel: Ein grüner Syntaxcheck ist eine technische Freigabe. Eine Rich-Result-Ausspielung bleibt eine Entscheidung von Google.
Warum isolierte Code-Checks scheitern
Ein isolierter Code-Check arbeitet häufig mit einem Snippet, das im Editor korrekt aussieht. Auf der Live-Seite kann jedoch ein Template andere Werte einsetzen, ein JavaScript-Rendering ausbleiben oder ein CMS-Feld leer bleiben. Der Validator kennt dann möglicherweise eine saubere Testversion, während Google auf der veröffentlichten URL eine andere Ausgabe crawlt.
Für unsere Arbeit in der SEO-Agentur für Münster und NRW ist deshalb die Trennung der Prüfziele entscheidend. Der Code wird zunächst technisch geprüft. Danach folgt die Google-spezifische Eligibility-Prüfung. Erst anschließend wird die Live-URL gegen die tatsächlich ausgelieferte Version kontrolliert.
Das grüne Licht ist also kein Endpunkt. Es ist ein Signal, dass die nächste Prüfung sinnvoll durchgeführt werden kann.
Der zweistufige Prüfprozess für sauberes JSON-LD-Markup
Ein verlässlicher Prüfprozess beginnt mit dem fachlichen Modell der Seite. Vor der Implementierung muss klar sein, welche Entität im Mittelpunkt steht und welche Informationen Nutzer tatsächlich sehen. In einem Online-Shop ist das meist ein einzelnes Produkt, in einem Veranstaltungsportal ein Event und in einem redaktionellen Beitrag ein Artikel. Diese Zuordnung verhindert, dass Markup zwar syntaktisch korrekt ist, aber eine unpassende oder nicht belegbare Entität beschreibt.
Schritt eins prüft die allgemeine Struktur
Für ein E-Commerce-Beispiel wird zunächst ein Produktobjekt definiert. Der Name muss dem sichtbaren Produkttitel entsprechen. Preis, Währung, Verfügbarkeit und gegebenenfalls Bewertung sollten aus denselben fachlichen Quellen stammen wie die Angaben im Frontend. Jede zusätzliche Property braucht einen konkreten Wert und eine nachvollziehbare Entsprechung auf der Seite. Leere Felder oder redaktionell nicht belegte Angaben erhöhen den Pflegeaufwand, ohne die Datenqualität zu verbessern.
Anschließend wird das Markup mit dem Schema Markup Validator auf eine generische schema.org-Struktur geprüft. Der Check erkennt strukturelle Fehler, unpassende Datentypen und fehlerhafte Beziehungen zwischen Entitäten. Seine Prüfung reicht über einzelne Google-Rich-Result-Features hinaus und zeigt deshalb, ob das semantische Modell grundsätzlich schlüssig aufgebaut ist.
Die Implementierung kann als JSON-LD erfolgen. Google unterstützt für den Rich-Results-Test ebenso JSON-LD, RDFa und Microdata. Während der Entwicklung lässt sich entweder eine öffentliche URL oder ein freies Code-Snippet prüfen, wie die Dokumentation zu strukturierten Daten und Validierung beschreibt. Für CI/CD-Prozesse eignet sich das Snippet als schneller, reproduzierbarer Smoke-Test. Die URL-Prüfung bleibt nötig, sobald Templates, Datenfeeds oder Rendering die Ausgabe beeinflussen.
Schritt zwei prüft die Google-Eignung
Nach der allgemeinen Strukturprüfung folgt der Rich-Results-Test von Google. Zuerst wird das Snippet geprüft. So lässt sich vor einem Release klären, ob Google die vorgesehenen Markups erkennt, erforderliche Properties vorhanden sind und kritische Fehler auftreten. Das verkürzt die Fehlersuche, bevor eine Änderung auf eine ganze Seitengruppe ausgerollt wird.
Danach wird mindestens eine reale URL aus dem betroffenen Template getestet. Das Snippet zeigt, ob der geplante Code funktioniert. Die URL zeigt, welche Version die Website tatsächlich ausliefert. Bei serverseitigem Rendering, Caching, Variantenlogik oder nachgelagerten Datenfeeds können beide Ergebnisse voneinander abweichen. In Enterprise-Setups sollte deshalb jede relevante Template-Klasse mit repräsentativen URLs abgedeckt werden.
Der Abnahmeablauf lässt sich so dokumentieren:
- Seitentyp festlegen: Produkt, Artikel, Event oder eine andere passende Entität auswählen.
- Sichtbare Daten abgleichen: Titel, Preis, Verfügbarkeit und weitere Werte mit dem Frontend vergleichen.
- Snippet validieren: Syntax und schema.org-Struktur prüfen.
- Google-Test ausführen: Die mögliche unterstützte Darstellung mit dem Rich-Results-Test bewerten.
- Live-URL kontrollieren: Die veröffentlichte Ausgabe testen, nicht nur den Repository-Code.
- Fehler dokumentieren: Kritische Fehler, Warnungen und betroffene Templates im Release festhalten.
Der Ablauf bleibt auch bei älteren Formaten nutzbar. Verwendet ein Legacy-System Microdata oder RDFa, können die gleichen Prüfziele angewendet werden. Bei neuen Implementierungen ist JSON-LD häufig einfacher zentral zu pflegen, weil die semantische Beschreibung vom sichtbaren HTML getrennt bleibt. Diese Trennung erleichtert Änderungen in Templates, erzeugt aber eine zusätzliche Kontrollstelle zwischen Datenquelle und Auslieferung.
| Prüfziel | Geeignetes Werkzeug | Was der Check beantwortet |
|---|---|---|
| Allgemeine schema.org-Struktur | Schema Markup Validator | Ist das Markup lesbar und strukturell plausibel? |
| Google-Rich-Result-Eignung | Rich-Results-Test | Erkennt Google ein unterstütztes Markup für eine mögliche Suchdarstellung? |
| Live-Auslieferung | URL-Prüfung in der Search Console | Sieht Google die erwartete Version der veröffentlichten URL? |
Nach einem Fix wird der alte Testbericht nicht einfach abgelegt. Snippet und Live-URL werden erneut geprüft, die Änderung wird einer betroffenen Template-Klasse zugeordnet und erst danach technisch abgenommen.
Monitoring und Fehlerbehebung nach dem Deployment
Mit dem Deployment endet das Testing nicht. Es beginnt die Phase, in der Templates, Datenfeeds, Caches und redaktionelle Änderungen das Markup verändern können. Ein Shop kann nach einer Preislogik-Änderung valide JSON-LD-Strukturen ausliefern, aber einen veralteten Preis eintragen. Ein CMS kann bei einem neuen Seitentyp ein Feld nicht mehr befüllen. Ein Frontend-Release kann strukturierte Daten nur noch nach einer clientseitigen Ausführung erzeugen.
Google empfiehlt deshalb einen zweistufigen Ablauf: Während der Entwicklung wird mit dem Rich-Results-Test geprüft. Nach dem Rollout werden die Rich-Result-Statusberichte in der Search Console überwacht. Diese Berichte sind kein Ersatz für den initialen Test, sondern die Betriebskontrolle für reale URLs.
Was Statusberichte tatsächlich zeigen
Ein sinnvoller Monitoringprozess beobachtet nicht nur einzelne Fehler, sondern Veränderungen in Seitengruppen. Wenn gültige Elemente zunehmen und ungültige Elemente nicht gleichzeitig steigen, spricht das für eine stabile Korrektur. Steigen Fehler in einer grossen Gruppe ähnlicher URLs, liegt die Ursache häufig in einem gemeinsamen Template oder einer zentralen Datenquelle.
Bei einem Fehler wird die betroffene URL einzeln untersucht. Die Live-Inspection zeigt, ob Google die veröffentlichte Seite und das erwartete Markup tatsächlich erkennen kann. Nach der Korrektur wird die Validierung erneut angestossen, statt die Behebung nur im Quellcode zu bestätigen.
Google betont zudem, dass strukturierte Daten zum sichtbaren Seiteninhalt passen müssen. Ein syntaktisch korrektes Markup kann fachlich trotzdem falsch sein, wenn es Informationen beschreibt, die Nutzer auf der Seite nicht sehen oder nicht nachvollziehen können. Diese inhaltliche Passung ist im Praxisüberblick zum Testing strukturierter Daten ein zentraler Fehlerpunkt.
Ein Monitoring, das zum Betrieb passt
Für die Organisation hilft eine klare Eskalationslogik:
- Kritische Fehler: Betroffene Seitengruppe priorisieren, Live-URL prüfen und die Ursache im Template oder Datenfeed suchen.
- Inhaltliche Abweichungen: Redaktion, Shop-Management oder Produktdatenverantwortliche einbeziehen.
- Neue Templates: Vor dem Rollout mit repräsentativen URLs und Snippets testen.
- Regelmässige Kontrolle: Search-Console-Berichte nach Releases und bei auffälligen Veränderungen auswerten.
Bei produktionsnahen Setups sollte das Monitoring nicht isoliert im SEO-Team liegen. Wenn strukturierte Daten aus ERP, Shop, CRM oder einem SaaS-Modul stammen, braucht der Prozess klare Verantwortlichkeiten. Für Unternehmen, die Betriebs- und Wartungsinformationen aus technischen Systemen zusammenführen, kann etwa der nova Standzeit Manager als Kontext für die Frage dienen, wie Zustandsdaten in laufenden Systemen nachvollziehbar erfasst und ausgewertet werden.
Der zeitliche Versatz darf ebenfalls nicht ignoriert werden. Google weist darauf hin, dass nach dem Einspielen neuer strukturierter Daten mehrere Wochen vergehen können, bis der neue Seitencode berücksichtigt wird. Nur wenn die Daten gecrawlt, vollständig und fehlerfrei sind, können sie als Rich-Suchergebnisse erscheinen, wie die deutsche Hilfe zur Datenvalidierung erklärt.
Wer eine technische Abnahme, erneutes Crawling und Monitoring organisatorisch verbinden will, sollte Schnittstellen und Migrationsprozesse früh berücksichtigen. Das gilt besonders bei Plattformwechseln und neuen Rendering-Architekturen, etwa im Umfeld von IT-Integrationen und SaaS-Migrationen.
Skalierbares Testing in CI/CD-Pipelines und SaaS-Setups
Manuelles Prüfen einzelner URLs funktioniert bei einem kleinen redaktionellen Projekt. Bei einem mehrsprachigen Enterprise-Shop oder einem SaaS-Portal mit dynamischen Templates wird es schnell zum Engpass. Die entscheidende Frage lautet dann nicht mehr: „Ist diese URL valide?“ Sie lautet: „Verhindert unser Entwicklungsprozess, dass fehlerhaftes Markup überhaupt produktiv ausgerollt wird?“
Die Antwort liegt in einer mehrstufigen Quality-Assurance-Kette, die technische Entwicklung, SEO und Fachbereiche verbindet. Structured Data Testing wird dabei nicht als nachträgliche Kontrolle behandelt, sondern als Release-Kriterium.
Pull Requests brauchen semantische Prüfungen
Im Pull Request sollte mindestens geprüft werden, ob die erwarteten Datentypen erzeugt werden und ob erforderliche Properties aus den jeweiligen Datenmodellen befüllt werden. Ein Linter kann JSON-LD syntaktisch analysieren. Eine Schema-Prüfung kann die Beziehung zwischen Entitäten kontrollieren. Ein Snapshot-Test kann sicherstellen, dass ein Produkt- oder Artikeltemplate weiterhin die erwartete Struktur ausgibt.
Das ist besonders relevant, wenn mehrere Teams an derselben Plattform arbeiten. Ein Frontend-Team verändert das Rendering, das Commerce-Team pflegt Preis- und Bestandsdaten, während SEO die Google-Eignung verantwortet. Ohne gemeinsame Prüfregeln bemerkt jedes Team nur seinen eigenen Ausschnitt.
Von der Einzel-URL zur Seitengruppe
Ein wirtschaftlicher Prozess arbeitet mit repräsentativen URL-Sets. Für einen Shop gehören dazu beispielsweise ein Standardprodukt, ein Produkt mit Varianten, ein nicht verfügbares Produkt und eine redaktionelle Produktbeschreibung. Für ein Portal kommen unterschiedliche Sprachversionen, Regionen und Seitentemplates hinzu.
Jede Seitengruppe braucht einen erwarteten Output:
| Seitengruppe | Fachliche Prüfung | Technische Prüfung |
|---|---|---|
| Produktdetailseite | Preis und Verfügbarkeit entsprechen dem sichtbaren Inhalt | JSON-LD wird auf jeder Variante ausgeliefert |
| Kategorieseite | Markup beschreibt die Seite, nicht unsichtbare Einzelprodukte | Template erzeugt keine leeren oder doppelten Objekte |
| Mehrsprachige Seite | Sprache und Inhalt gehören zur richtigen URL | Sprachwechsel verändert keine falschen Entitätswerte |
| SaaS-Datensatz | Erforderliche Felder sind vollständig und aktuell | API- und Rendering-Ausgabe bleiben konsistent |
Der Rich-Results-Test liefert dabei die Google-spezifische Sicht. Allgemeine Validatoren prüfen die breitere Schema-Abdeckung. Dieser Trend zur Trennung von Syntax und Eligibility wird auch im Google Rich-Results-Test deutlich. Kein einzelnes Tool sollte als vollständiger Qualitätsbeweis für eine grosse Website gelten.
Datenschutz und DACH-Betrieb
In DACH-Setups gehört Datenschutz zur Architekturentscheidung. Code-Snippets können in einer Entwicklungsumgebung geprüft werden, während produktive URLs nur dann automatisiert getestet werden sollten, wenn Crawling, Zugriffsschutz und Datenverarbeitung mit den internen Vorgaben vereinbar sind. Sensible Inhalte gehören nicht unkontrolliert in externe Prüfprozesse.
Für CI/CD bedeutet das: Testdaten anonymisieren, Umgebungen sauber trennen und Ergebnisse revisionssicher dokumentieren. Bei einem EU-orientierten SaaS- oder Cloud-Setup sollten Teams zudem klären, welche Daten an externe Dienste übertragen werden und welche Prüfungen intern laufen können.
Die Pipeline muss nicht jede mögliche schema.org-Entität bei jedem Commit prüfen. Wirtschaftlich sinnvoller ist ein abgestuftes Modell: schnelle Syntax- und Schema-Checks im Pull Request, tiefere URL-Tests vor dem Release und regelmässiges Monitoring nach dem Go-live. Fragen zur belastbaren Umsetzung gehören in eine Beratung zur Software-Architektur, weil die richtige Prüfgrenze von CMS, Shop, Rendering und Datenmodell abhängt.
Zukunftssichere Strategien jenseits einzelner Rich-Snippet-Features
Strukturierte Daten sollten nicht nur für ein einzelnes Suchfeature gebaut werden. Ein Markup, das ausschliesslich auf eine kurzfristige SERP-Darstellung zielt, verliert seinen strategischen Wert, sobald Google die Regeln ändert. Eine belastbare Datenstruktur beschreibt stattdessen die Entitäten der Website sauber, verbindet sie nachvollziehbar und bleibt auch dann fachlich sinnvoll, wenn ein bestimmtes Rich Result nicht mehr angeboten wird.
Der schrittweise Rückbau der FAQ-Rich-Results zeigt dieses Risiko deutlich. Google hat die FAQ-Rich-Results-Unterstützung 2026 schrittweise beendet, mit dem Support im Rich-Results-Test ab Juni 2026 und im Search-Console-API-Zugriff ab August 2026, wie die Google-Dokumentation zu strukturierten Daten beschreibt. Für Teams, die FAQ-Markup nur wegen dieser Darstellung gepflegt haben, bricht damit ein bisheriger Prüf- und Reportingpfad weg.
Semantische Qualität statt Feature-Abhängigkeit
FAQ-Inhalte können weiterhin für Nutzer, interne Suche und Wissensorganisation relevant sein. Entscheidend ist, dass die Fragen und Antworten sichtbar, redaktionell gepflegt und fachlich korrekt bleiben. Das Markup darf nicht als versteckter Ersatz für fehlende Inhalte dienen.
Eine zukunftssichere Strategie prüft deshalb:
- Entitäten: Ist klar, welche Organisation, welches Produkt, welcher Ort oder welches Event beschrieben wird?
- Beziehungen: Sind Autor, Anbieter, Produkt und Seite sinnvoll miteinander verknüpft?
- Datenqualität: Stimmen Werte mit sichtbaren Inhalten und Primärsystemen überein?
- Abhängigkeiten: Würde der Datenbestand auch ohne ein bestimmtes Rich Result noch einen fachlichen Zweck erfüllen?
- Änderbarkeit: Können Templates und Properties angepasst werden, ohne jede Seite manuell zu bearbeiten?
Diese Perspektive ist auch für KI-gestützte Suchsysteme und interne Wissensgraphen sinnvoll, ohne daraus eine garantierte Sichtbarkeit abzuleiten. Strukturierte Daten können Maschinen Informationen explizit und standardisiert anbieten. Sie ersetzen jedoch weder hochwertige Inhalte noch eine korrekte technische Auslieferung.
Ein Feature ist kein Geschäftsmodell
Google kann Darstellungsformen reduzieren, umbenennen oder anders bewerten. Deshalb sollte das Reporting nicht nur „Rich Result vorhanden“ oder „nicht vorhanden“ kennen. Es sollte zusätzlich die fachliche Datenqualität, die Abdeckung wichtiger Seitentypen, die Fehlerentwicklung und die Nutzung der strukturierten Informationen in eigenen Systemen dokumentieren.
Bei einem Marktplatz kann das bedeuten, Produkt-, Marken- und Angebotsbeziehungen konsistent zu halten, selbst wenn eine bestimmte Suchdarstellung entfällt. Bei einem B2B-Portal geht es eher darum, Ansprechpartner, Leistungen, Publikationen und Organisationen eindeutig zu beschreiben. Die langfristige Investition liegt in der Datenarchitektur, nicht in der Jagd nach einem einzelnen Snippet.
Strategische Leitlinie: Baue Markup so, dass ein Feature-Wegfall die Darstellung verändert, nicht die Datenqualität entwertet.
Messbare Business-Wirkung durch saubere Datenstrukturen
Strukturierte Daten leisten nur dann einen geschäftlichen Beitrag, wenn sich ihre Qualität und ihre Auswirkungen über Seitengruppen hinweg prüfen lassen. Eine einzelne URL nach dem Deployment liefert dafür keine belastbare Grundlage. Für die Bewertung eignet sich ein Vorher-Nachher-Test über mehrere Monate, mit nicht saisonalen Seiten und ausreichender Datenbasis in der Search Console. Der Rich-Results-Test mit deutscher Dokumentation ist dabei ein Prüfwerkzeug, ersetzt aber keine Wirkungsanalyse.
Ein realistischer Messplan
Ein belastbarer Vergleich startet mit einer klar abgegrenzten Seitengruppe. Vor der Implementierung werden technische Ausgangslage, organische Impressionen, Klicks, durchschnittliche Position und relevante Conversion-Signale dokumentiert. Nach dem Rollout bleiben Seitentypen und Beobachtungslogik möglichst vergleichbar.
Die Auswertung muss Markup-Änderungen von anderen Einflussfaktoren trennen. Werden gleichzeitig Titel, interne Verlinkung, Preise, Inhalte und Templates angepasst, lässt sich der Beitrag strukturierter Daten nur eingeschränkt bestimmen. Release-Kalender, Crawling-Verzögerungen und saisonale Besonderheiten gehören deshalb in die Dokumentation.
Ein Reporting verbindet mehrere Ebenen:
- Technische Qualität: Gibt es kritische Fehler, ungültige Items oder Ausfälle in Templates?
- Suchdarstellung: Werden unterstützte Rich Results erkannt und über die Zeit stabil verarbeitet?
- Organische Leistung: Verändern sich Klicks, Impressionen und Suchanfragen in der geprüften Seitengruppe?
- Geschäftswirkung: Entwickeln sich qualifizierte Leads, Warenkörbe oder andere primäre Ziele parallel?
- Betriebsqualität: Bleibt das Markup nach Releases, Übersetzungen und Datenänderungen konsistent?
Die Ergebnisse sollten nach Seitentyp, Datenquelle und Release auswertbar sein. So wird sichtbar, ob ein Fehler nur eine Vorlage betrifft oder eine ganze Plattform belastet.
Agenturperspektive aus Münster
In der Praxis entsteht der Wert selten durch möglichst viele Properties. Entscheidend sind ein passendes Datenmodell, der richtige Seitentyp, stabile Auslieferung und ein Reporting, das technische Qualität von Geschäftserfolg trennt.
Küstermann Media GmbH arbeitet als Digitalagentur in Münster unter anderem an technischer SEO, Webentwicklung, E-Commerce, Integrationen und SaaS-Lösungen. In Projekten wird deshalb nicht nur ein Markup-Snippet abgenommen. Zu klären ist auch, aus welchem System die Werte stammen, wie Änderungen in Templates gelangen und wer nach dem Rollout die Statusberichte bewertet.
Ein realistisches Projektergebnis ist keine Zusage für ein Rich Result auf jeder Seite. Belastbar ist ein Prozess, der fachlich passende Daten erzeugt, Fehler früh erkennt, Änderungen nachvollziehbar macht und organische sowie geschäftliche Signale über einen geeigneten Zeitraum prüft.
Für Shops, Portale und SaaS-Systeme empfiehlt sich als nächster Schritt eine Inventur von Seitentypen und Datenquellen. Danach lassen sich repräsentative Live-URLs prüfen, die Ergebnisse aus Schema Markup Validator, Rich-Results-Test und Search Console dokumentieren und erste CI/CD-Prüfregeln für das Team ableiten.
