Strukturierte Daten für KMU: Schema.org, Rich Results und Validierung

Schema.org, strukturierte Daten und Rich Results auseinanderhalten

Ein Vokabular beschreibt Bedeutung, eine Suchfunktion definiert ihre eigenen Regeln

Schema.org stellt ein gemeinsames Vokabular bereit: Typen wie Organization oder Article und Eigenschaften wie name, author oder dateModified. Strukturierte Daten sind die konkrete Auszeichnung einer Seite mit diesem Vokabular. JSON-LD, Microdata und RDFa sind mögliche Formate. Google unterstützt alle drei und empfiehlt meist JSON-LD, weil es sich getrennt vom sichtbaren HTML pflegen lässt. Die Google-Einführung in strukturierte Daten beschreibt diese Auszeichnung als standardisierte Hinweise zum Seiteninhalt.

Davon getrennt gelten die allgemeinen Google-Richtlinien für strukturierte Daten. Sie verbinden die technische Auszeichnung mit Qualitätsanforderungen: Das Markup muss zum Hauptinhalt passen, Nutzer dürfen nicht getäuscht werden, und eine Seite muss für den jeweiligen Anwendungsfall zugänglich sein. Diese Leitplanken werden schon bei der Modellwahl geprüft, nicht erst nach einer Fehlermeldung.

Ein Rich Result ist dagegen eine konkrete Darstellung in Google Search. Sie besitzt eigene technische, inhaltliche und qualitative Voraussetzungen. Eine Eigenschaft kann deshalb im Schema.org-Vokabular korrekt sein, ohne für eine Google-Suchfunktion ausgewertet zu werden. Umgekehrt reicht ein von Google unterstützter Typ nicht aus, wenn Pflichtangaben fehlen, der Inhalt nicht sichtbar ist oder die Seite gegen eine Richtlinie verstößt.

Fünf Prüfzustände verhindern falsche Erfolgsmeldungen

Ein grüner Test bestätigt daher nur den geprüften Zustand. Er ist kein Beleg dafür, dass Google die URL indexiert, die Auszeichnung auswählt oder das Suchergebnis dauerhaft erweitert. Diese begriffliche Trennung gehört in jedes Ticket und jeden Bericht.

Vor dem Markup Seitentyp, Faktenquelle und Ziel festlegen

Die Modellierung beginnt mit der freigegebenen Seite, nicht mit einem Generator

Definieren Sie zuerst die einzelne URL oder ein homogenes Template, den sichtbaren Hauptinhalt und den gewünschten Suchanwendungsfall. Eine Leistungsseite ist nicht automatisch ein Produkt, ein Firmenblog nicht automatisch eine Nachrichtenorganisation und eine Kontaktseite ohne bedienten Standort kein LocalBusiness. Der Typ muss die Hauptaussage der konkreten Seite beschreiben, nicht eine erhoffte Darstellung imitieren.

Prüfen Sie anschließend, welche Systeme für Name, Logo, Adresse, Autor, Preise, Verfügbarkeit, Veröffentlichungsdatum und weitere Aussagen verbindlich sind. CMS, Warenwirtschaft, Standortverwaltung und Theme können dieselbe Information unterschiedlich führen. Solange unklar ist, welcher Wert gilt, darf die strukturierte Ausgabe diesen Konflikt nicht verdecken. Erst die sichtbare Seite und die maßgebliche Datenquelle werden korrigiert, danach folgt das Markup.

Title-Element, Überschriften, sichtbarer Text und Bildangaben sollten bereits redaktionell abgestimmt sein. Dafür dient der vorgelagerte Leitfaden zu On-Page SEO für KMU. Strukturierte Daten reparieren keine unklare Seitenrolle und ersetzen keine sichtbare Information.

Ein Structured Data Release Ledger als gemeinsame Wahrheit führen

Jede veröffentlichte Aussage braucht Herkunft, Regel, Owner und Retest

Das Release Ledger verbindet eine URL oder Templategruppe mit dem beabsichtigten Entitätsmodell, der sichtbaren Quelle und den Validierungsbelegen. Es verhindert, dass ein Plugin-Status als vollständige Freigabe gilt oder eine Änderung ohne Verantwortlichen live geht. Ein Eintrag wird erst geschlossen, wenn die veröffentlichte URL erneut geprüft wurde.

Ergänzen Sie je Befund Zeitstempel, Sprache, Gerät oder User-Agent, erwarteten Zustand, beobachteten Zustand und Link zum Ticket. Bei dynamischen Daten gehören auch Cache-Zeit und Datenalter dazu. So lässt sich unterscheiden, ob ein Fehler in der Quelle, im Mapping, in der Template-Logik, beim Rendering oder erst nach der Veröffentlichung entsteht.

Sichtbare Aussagen zuerst in Entitäten und Beziehungen übersetzen

Eine kleine konsistente Graphstruktur ist wertvoller als viele isolierte Blöcke

Markieren Sie auf der Seite zunächst reale Dinge: das Unternehmen, den Standort, die Website, den Artikel, die Person, das Produkt, das Angebot und die Breadcrumb-Navigation. Entscheiden Sie anschließend, welches Ding die Hauptentität der URL ist und welche weiteren Entitäten nur Kontext liefern. Auf einer Artikelseite ist der Beitrag gewöhnlich die Hauptentität; Organisation, Autor und Website stehen in Beziehung dazu, werden aber nicht zu konkurrierenden Hauptobjekten.

Ein Feld wird nicht befüllt, nur weil der Generator es anbietet. Es wird aufgenommen, wenn der Wert für den gewählten Typ sinnvoll, aktuell und sichtbar oder für Nutzer eindeutig nachvollziehbar ist. Fehlt die Information auf der Seite, wird sie entweder redaktionell ergänzt oder aus dem Markup entfernt. Eine strukturierte Behauptung darf nicht weiter reichen als der belegte Hauptinhalt.

Notieren Sie auch absichtliche Auslassungen. Ein KMU ohne öffentlich kommunizierte Öffnungszeiten braucht keine erfundenen Werte. Ein Artikel ohne fachlich ausgewiesenen Autor sollte keine Person aus einer globalen Standardeinstellung übernehmen. Lücken im Modell sind oft ein hilfreicher Hinweis auf fehlende Content-Governance, kein Anlass zum Erfinden.

Schema.org-Vokabular und Google-Eignung getrennt entscheiden

Die Suchgalerie ist die Freigabegrenze für Google-Funktionen

Prüfen Sie in der Google Search Gallery, ob für die gewünschte Suchfunktion eine aktuelle Dokumentation existiert. Der dort verknüpfte Funktionsleitfaden bildet die Grundlage der Eignungsprüfung; der Google-Einstieg zur Prüfung strukturierter Daten ordnet den Rich Results Test in diesen Ablauf ein. Suchfunktionen ändern sich: Die Google Search Updates dokumentieren relevante Erweiterungen und Einstellungen. Eine Freigabe muss deshalb die zum Prüfzeitpunkt aktuelle Dokumentation festhalten.

Das Vokabular ist breiter. Die Schema.org-Dokumentation der Schemata enthält mehr Typen und Eigenschaften, als Google für Rich Results verwendet. Schema.org Version 30.0 wurde am 19. März 2026 veröffentlicht; eine gültige Eigenschaft aus diesem Vokabular ist dennoch kein Beleg für eine Google-Suchfunktion. Prüfen Sie erst, ob das Modell das reale Objekt korrekt beschreibt, und danach getrennt seine Google-Eignung.

Diese Trennung schützt vor zwei Fehlern: Teams entfernen nützliche semantische Angaben, nur weil sie kein Rich Result erzeugen, oder sie versprechen eine Darstellung, weil ein Typ im Vokabular existiert. Das Release Ledger kann beides dokumentieren: semantischer Zweck und Google-Anwendungsfall erhalten getrennte Felder.

Die technische Erreichbarkeit und Indexierbarkeit der URL bleibt Voraussetzung außerhalb dieses Markups. Wenn Response, Canonical, robots-Regeln oder Rendering ungeklärt sind, folgt zuerst der Leitfaden zu Technical SEO für KMU.

Stabile Entitätskennungen und eindeutige Beziehungen verwenden

Dieselbe Organisation sollte nicht auf jeder Seite neu erfunden werden

Eine stabile, absolute Kennung mit @id kann wiederkehrende Entitäten über Seiten und Blöcke hinweg verbinden. Beispielsweise kann die Organisation auf der Startseite definiert und in Artikeln als Herausgeber referenziert werden. Die Kennung ist kein öffentliches Profil und muss keine erreichbare Seite sein; als dauerhaftes internes Identitätsversprechen sollte sie aber nicht bei jedem Theme-Update wechseln.

Legen Sie eine kleine Registry für wiederverwendete Entitäten an: Organization, WebSite, öffentliche Personenrollen, reale Standorte und gegebenenfalls Produktfamilien. Dokumentieren Sie je Eintrag kanonische URL, Kennung, zuständiges System und erlaubte Eigenschaften. Verschiedene Sprachversionen dürfen lokalisierte Namen oder Beschreibungen tragen, sollten aber dieselbe reale Organisation oder Person nicht als voneinander unabhängige Identitäten ausgeben.

Vermeiden Sie zirkuläre oder widersprüchliche Modelle. Ein Produktangebot darf nicht auf eine andere Produktidentität zeigen, eine Autor-Person nicht zugleich als Unternehmen typisiert werden und ein Standort nicht wechselweise LocalBusiness und bloße Postadresse sein. Bei Zweifeln ist ein kleinerer, klarer Graph sicherer als viele automatisch ergänzte Knoten.

JSON-LD aus einer verantwortlichen Quelle erzeugen

Ein Seitentyp braucht einen kontrollierten Erzeuger statt konkurrierender Plugins

JSON-LD lässt sich zentral aus Template-Daten erzeugen und verändert die sichtbare Gestaltung nicht. Das macht es wartbar, aber nicht automatisch korrekt: Ein sauberer Block kann falsche Standardwerte, veraltete Stammdaten oder leere Variablen transportieren. Definieren Sie deshalb pro Entität und Seitentyp genau einen technischen Owner. Theme, SEO-App, Bewertungsdienst und Shop-System dürfen nicht unabhängig denselben Product-, Organization- oder Breadcrumb-Knoten veröffentlichen.

Das Mapping wird wie eine Datenschnittstelle spezifiziert. Für jede Eigenschaft stehen Quelle, Datentyp, Pflichtlogik, Fallback, Locale-Verhalten und Ausschlussbedingung fest. Ein Fallback darf nur einen gleichwertigen bestätigten Wert liefern. Er darf keine Adresse, Bewertung, Autorenrolle, Verfügbarkeit oder Preisangabe erfinden, wenn die fachliche Quelle leer ist.

Versionieren Sie Mapping und Template gemeinsam. Bei jeder Änderung an Feldern, Apps oder Lokalisierung wird eine repräsentative URL-Stichprobe neu getestet. Ein manuell eingefügter Block ohne Verbindung zur Datenquelle kann für eine einzelne Seite funktionieren, altert bei Preis-, Autoren- oder Adressänderungen jedoch schnell.

Markup auf sichtbare, relevante und aktuelle Inhalte begrenzen

Technische Gültigkeit heilt keine irreführende Aussage

Die allgemeinen Google-Richtlinien verlangen, dass die Auszeichnung den Hauptinhalt der Seite wahrheitsgemäß wiedergibt und für Nutzer sichtbar beziehungsweise relevant ist. Markieren Sie daher keine Leistung, die das Unternehmen nicht anbietet, keine Bewertung, die auf der Seite fehlt, und keinen Preis, der nur in einem anderen Markt oder nach zusätzlichen Bedingungen gilt.

Qualität wird auf drei Ebenen geprüft. Erstens muss der Wert fachlich stimmen. Zweitens muss die sichtbare Darstellung dieselbe Bedeutung tragen. Drittens muss die technische Ausgabe zum aktuellen Zustand der konkreten URL passen. Ein Angebot mit korrekt formatierter Zahl bleibt falsch, wenn die sichtbare Produktseite bereits einen anderen Preis zeigt. Eine alte dateModified-Angabe bleibt syntaktisch gültig, kann aber einen unzutreffenden Aktualitätszustand vermitteln.

Ein Richtlinienverstoß kann die Eignung für Rich Results beeinträchtigen. Daraus folgt nicht automatisch, dass die Seite aus den normalen Suchergebnissen entfernt wird. Bericht und Kommunikation sollten diese Folgen präzise benennen und keine allgemeine Ranking-Strafe aus einem strukturierten-Daten-Fehler behaupten.

Für Organisation, Standort, Artikel und Produkt eigene Verträge definieren

Organization und LocalBusiness beschreiben unterschiedliche Ebenen

Organization bündelt die öffentliche Identität des Unternehmens. Die Google-Dokumentation zu Organization empfiehlt die Auszeichnung auf der Startseite oder einer zentralen Unternehmensseite und nennt keine Pflichtfelder. Tragen Sie nur relevante öffentliche Daten ein: rechtlich und kommunikativ bestätigter Name, URL, Logo sowie verifizierte Kontakt- oder Profilbeziehungen.

LocalBusiness beschreibt einen real bedienten physischen Standort. Nach der Dokumentation zu LocalBusiness sind Name und physische Adresse erforderlich; möglichst wird der spezifischste passende Untertyp gewählt. Modellieren Sie mehrere Standorte als getrennte Entitäten mit eigenen Seiten und Daten. Eine virtuelle Präsenz, ein Postfach oder ein gewünschtes Einzugsgebiet rechtfertigt keine erfundene Straßenadresse.

Article und Merchant Listing brauchen genaue redaktionelle oder kommerzielle Daten

Für Blog- und Ratgeberseiten nennt die Google-Dokumentation zu Article empfohlene Angaben wie headline, author, datePublished, dateModified und image. Die Autorenidentität muss der sichtbaren Byline entsprechen; dateModified wird nur bei einer echten, nachvollziehbaren Inhaltsänderung aktualisiert. Ein automatisches Build-Datum ist kein Ersatz für redaktionelle Pflege.

Die Merchant-Listing-Dokumentation richtet sich an Seiten, auf denen ein konkretes Produkt oder eine Variante tatsächlich gekauft werden kann. Preis, Währung, Verfügbarkeit, Variante und Angebotszeitraum müssen zum sichtbaren Kaufzustand passen. Bei schnell wechselnden Werten sollte die zuverlässige initiale HTML-Ausgabe bevorzugt und mit Feed- oder Backend-Daten abgestimmt werden.

Bewertungen, Angebote und Zeitangaben besonders streng kontrollieren

Ein überzeugendes Snippet darf nicht durch unbelegte Aussagen erkauft werden

Bewertungen sind kein dekoratives Feld. Die Google-Richtlinien für Review Snippets schließen unter anderem selbstbezogene Bewertungen für LocalBusiness und Organization von Sternen aus. Übernehmen Sie keine zusammengefassten Ratings fremder Plattformen als eigene Bewertungsgrundlage und kennzeichnen Sie Anreize oder redaktionelle Beziehungen transparent, wenn Bewertungen erhoben werden.

Für Deutschland enthält der amtliche Anhang zum Gesetz gegen den unlauteren Wettbewerb besondere Regeln zu Verbraucherbewertungen: Echtheitsbehauptungen benötigen angemessene Prüfmaßnahmen; gefälschte Bewertungen und falsche Darstellungen zu Verkaufsförderungszwecken sind unzulässig. Diese Einordnung ist keine individuelle Rechtsberatung. Bei Unsicherheit werden Rechts- und Compliance-Verantwortliche eingebunden.

Für diese Felder ist eine Fail-closed-Logik sinnvoll: Fehlt ein belastbarer Wert oder widersprechen sich Systeme, wird das betroffene Objekt nicht veröffentlicht, statt einen Standardwert einzusetzen. Der sichtbare Nutzerweg und die fachliche Quelle werden zuerst korrigiert.

DE, EN, RU und UK lokalisieren, ohne reale Entitäten zu vervielfachen

Übersetzbare Texte und gemeinsame Stammdaten brauchen getrennte Regeln

Mehrsprachige Seiten dürfen Name, Beschreibung, Artikelüberschrift und andere sprachabhängige Werte lokalisieren. Rechtlicher Unternehmensname, unveränderte Markenidentität, Produktkennung oder reale Adresse bleiben dagegen gemeinsame Fakten, sofern der Zielmarkt keine legitime abweichende Darstellung erfordert. Definieren Sie pro Eigenschaft, ob sie übersetzt, formatiert, gemeinsam referenziert oder lokal aus einem Markt-System bezogen wird.

Prüfen Sie jede Sprach-URL einzeln. Ein globaler JSON-LD-Block kann die deutsche Überschrift auf allen Varianten ausgeben, ein Shop-System kann Währung oder Verfügbarkeit nach Markt ändern, und ein Cache kann alte locale-Werte halten. Die DOM-Parität der Templates ist hilfreich, ersetzt aber nicht den sprachlichen und fachlichen Abgleich.

Entity-IDs dürfen dieselbe reale Organisation oder Person über Sprachpfade hinweg verbinden. Artikel oder Produktseiten besitzen dagegen ihre eigenen kanonischen URLs und lokalisierten Seitenaussagen. Canonical und hreflang werden im technischen SEO geprüft; das Structured-Data-Ledger dokumentiert nur, welche URL und Sprache der jeweilige Knoten tatsächlich beschreibt.

Doppelte und widersprüchliche Ausgaben von Theme, Apps und CMS entfernen

Mehrere gültige Blöcke können zusammen ein falsches Gesamtbild ergeben

Viele Plattformen veröffentlichen bereits strukturierte Daten: das Theme eine Organization und BreadcrumbList, die SEO-App einen zweiten Organization-Knoten, die Review-App AggregateRating und das Commerce-Modul Product mit Offer. Jeder Block kann einzeln syntaktisch gültig sein, während Name, @id, Preis, Bild oder Verfügbarkeit im Gesamtgraphen widersprechen.

Inventarisieren Sie deshalb alle Erzeuger im ursprünglichen HTML und im gerenderten DOM. Ordnen Sie jeden Knoten einem Owner zu und entscheiden Sie, welcher Erzeuger bestehen bleibt. Deaktivieren Sie nur nach Test, weil eine App neben Markup auch sichtbare Funktionen oder Datenfeeds steuern kann. Wo ein Entfernen nicht möglich ist, müssen IDs, Quellen und Aktualisierungslogik bewusst abgestimmt werden.

Typische Konflikte sind eine siteweite AggregateRating-Ausgabe, ein Product auf Kategorieseiten, mehrere Preise für unterschiedliche Varianten, ein alter Logo-Pfad oder eine Organization mit wechselnden Kennungen. Beheben Sie die erzeugende Regel und testen Sie eine Stichprobe, statt einzelne Seiten manuell zu überkleben.

Syntax, Google-Eignung und veröffentlichte Realität getrennt testen

Ein Validator beantwortet immer nur eine bestimmte Frage

Der Schema Markup Validator hilft bei Syntax, Typen, Eigenschaften und dem extrahierten Schema.org-Graphen. Der Google Rich Results Test prüft dagegen, ob Google auf der getesteten Ausgabe unterstützte Rich-Result-Typen erkennt und welche Fehler oder Warnungen für diese Funktionen bestehen. Ein Schema.org-gültiger Knoten kann dort bewusst ohne unterstützte Funktion bleiben.

Testen Sie während der Entwicklung zunächst reproduzierbare Beispiele. Vor der Freigabe wird jedoch die reale URL geprüft, weil nur sie Weiterleitungen, robots-Regeln, JavaScript, Ressourcen, Consent, Marktlogik und Cache abbildet. Legen Sie Screenshot oder Export, Zeitpunkt, getestete URL und Toolstatus im Ledger ab. Ein bloßer Link auf ein vergängliches Testergebnis reicht für spätere Ursachenanalyse nicht.

Erfassen Sie Fehler und Warnungen mit der betroffenen Eigenschaft sowie dem tatsächlich extrahierten Wert. Ein Fehler in einer Testkopie kann bereits behoben sein, während der Live-Cache noch den alten Block liefert; umgekehrt kann ein Codebeispiel bestehen, obwohl reale Produktdaten leere oder falsch formatierte Werte erzeugen. Die Teststufe wird deshalb nie ohne URL, Umgebung und Datenzustand berichtet.

Source, gerenderter DOM und Live-URL müssen dasselbe Modell tragen

Vergleichen Sie die initiale HTML-Antwort mit dem gerenderten Dokument. Google kann JavaScript-veränderte Ausgaben verarbeiten, doch späte Daten erhöhen das Risiko von Verzögerungen und Abweichungen. Besonders Preis und Verfügbarkeit sollten nicht nur nach Interaktion oder aus einer instabilen Drittquelle erscheinen. Prüfen Sie auch Smartphone-Ausgabe, Locale, eingeloggten und anonymen Zustand sowie mindestens eine URL je Template-Randfall.

Für die veröffentlichte Beobachtung folgt danach die Arbeit mit der Google Search Console für KMU. URL-Prüfung und Rich-Result-Statusberichte zeigen, was Google für bekannte URLs erkennt. Sie ersetzen weder den Faktenabgleich noch den kontrollierten Live-Retest.

Die Änderung mit Stichprobe, Rückweg und klarer Entscheidung ausrollen

Freigabe bedeutet belegte Übereinstimmung, nicht lediglich grünen Code

Beginnen Sie mit einer kleinen repräsentativen Gruppe: je Seitentyp eine normale URL, eine sprachliche Variante, eine dynamische Seite und ein bekannter Randfall. Prüfen Sie vor und nach der Änderung dieselben Ebenen. Der Rollout erhält Owner, Zeitfenster, Cache-Plan, Monitoring und einen Rückweg, falls Preise, Sichtbarkeit oder Templates unerwartet reagieren.

Warnungen werden nicht pauschal als Fehler oder bedeutungslos behandelt. Das Team dokumentiert, ob die empfohlene Angabe fachlich verfügbar und für den Anwendungsfall sinnvoll ist. Fehlt sie absichtlich, bleibt die Entscheidung im Ledger. Bei kritischen Widersprüchen wird der Rollout gestoppt oder auf die letzte bekannte Version zurückgesetzt.

Nach der Veröffentlichung Erkennung und Suchdarstellung ohne Scheinkausalität messen

Search Console kann für unterstützte Typen gültige, ungültige und von Warnungen betroffene Elemente gruppieren. „Gültig“ bedeutet, dass die erkannte Ausgabe grundsätzlich für die Funktion geeignet ist; es bedeutet nicht, dass jede URL ein Rich Result erhält. Veränderungen werden deshalb zusammen mit Indexierungszustand, Release-Datum, Seitentyp und Suchanfragen betrachtet.

Definieren Sie vor dem Rollout eine kleine Vergleichsbasis: betroffene URLs, Zeitraum, Geräte, Länder, Suchdarstellung und weitere gleichzeitig geplante Änderungen. Beobachten Sie zunächst technische Fehler und Erkennungsabdeckung. Für Impressionen, Klicks oder Klickrate benötigen Sie längere Zeiträume und ausreichend Daten. Saison, Rankings, Snippet-Umschreibungen, Nachfrage und andere Releases können dieselben Kennzahlen verändern.

Ein Rückgang nach einem Feature-Update ist nicht automatisch ein Implementierungsfehler. Google kann Darstellungen ändern oder einstellen. Prüfen Sie aktuelle Dokumentation, Release-Historie und Testergebnis, bevor Sie funktionierendes Markup entfernen. Semantisch nützliche Daten dürfen bestehen bleiben, auch wenn eine konkrete Suchdarstellung entfällt.

Häufige Fragen zu strukturierten Daten