Strukturierte Daten für Onlineshops: schema.org, Rich Results und KI-Sichtbarkeit

Eine Produktseite besteht für einen Menschen aus Überschrift, Bild, Preis und Kaufbutton. Für eine Maschine besteht sie aus HTML-Elementen ohne inhaltliche Bedeutung. Strukturierte Daten schließen genau diese Lücke: Sie legen eine zweite, ausdrücklich benannte Ebene über den sichtbaren Inhalt und erklären, welche Rolle jede Angabe spielt. Google beschreibt das als standardisiertes Format, um Informationen über eine Seite bereitzustellen und deren Inhalt zu klassifizieren.

Vokabular und Format sind zwei verschiedene Dinge

Das Vokabular ist schema.org — eine gemeinsam von Google, Microsoft, Yahoo und Yandex getragene Sammlung von Typen und Eigenschaften. Dort ist definiert, dass ein Product einen name, ein image, eine brand und über die Eigenschaft offers ein oder mehrere Offer-Objekte haben kann. schema.org sagt aber nichts darüber, wie dieses Wissen technisch in die Seite kommt.

Dafür gibt es drei Formate: Microdata und RDFa werden als Attribute direkt in das sichtbare HTML geschrieben, JSON-LD dagegen als eigenständiger Datenblock in einem script-Tag mit dem Typ application/ld+json. Google behandelt alle drei gleichwertig, empfiehlt aber ausdrücklich JSON-LD, weil es am einfachsten zu implementieren und zu pflegen ist. Der praktische Grund dahinter ist entscheidend: Bei Microdata hängt dein Markup an der Template-Struktur. Baut jemand das Layout um, verschiebt ein Element oder tauscht das Theme, zerbricht das Markup unbemerkt. JSON-LD ist vom Layout entkoppelt — der Datenblock bleibt intakt, egal wie das Frontend umgebaut wird.

Die eine Regel, die alles andere überlagert

Strukturierte Daten sind keine freie Behauptung. Was im Markup steht, muss auf der Seite auch sichtbar sein. Google formuliert das in den allgemeinen Richtlinien für strukturierte Daten unmissverständlich: Inhalte, die für Leser der Seite nicht sichtbar sind, dürfen nicht ausgezeichnet werden — selbst dann nicht, wenn die Angabe inhaltlich korrekt ist. Verstöße gegen diese Regel sind der häufigste Auslöser für manuelle Maßnahmen im Bereich strukturierter Daten. Die Folge ist kein Ranking-Verlust im klassischen Sinn, aber der vollständige Ausschluss von Rich Results — und damit genau der Sichtbarkeitsvorteil, wegen dem du das Markup überhaupt eingebaut hast.

Zwei Adressaten, ein Datensatz

Der zweite Grund, warum sich der Aufwand heute stärker lohnt als vor drei Jahren: Strukturierte Daten haben inzwischen zwei Empfänger. Der eine ist die klassische Suchergebnisseite mit ihren angereicherten Darstellungen. Der andere sind Systeme, die Seiteninhalte zusammenfassen und zitieren, statt sie nur zu verlinken. Beide lesen denselben Datenblock. Du pflegst also einmal und bedienst zwei Kanäle — dazu im letzten Kapitel mehr, inklusive einer ehrlichen Einordnung, was daran belegt ist und was Arbeitshypothese bleibt.

schema.org umfasst über 800 Typen. Für einen Onlineshop sind davon eine Handvoll relevant — und ein paar prominente, die es bis 2023 waren und heute keinen Nutzen mehr bringen. Der Überblick nach Seitentyp:

Product und Offer — die Produktseite

Product beschreibt den Artikel selbst: Name, Bild, Beschreibung, Marke, Hersteller, GTIN oder SKU. Der eigentliche kommerzielle Kern steckt aber im verschachtelten Offer: Preis, Währung, Verfügbarkeit, Gültigkeitszeitraum, Versand- und Rückgabebedingungen. Google unterscheidet dabei zwei Ausbaustufen — schlichte Produkt-Snippets für Seiten ohne direkte Kaufmöglichkeit und die deutlich prominenteren Merchant Listings für Seiten, auf denen tatsächlich gekauft werden kann. Welche Anforderungen für Merchant Listings gelten und wie das Zusammenspiel mit dem Produktdatenfeed funktioniert, steht im Ratgeber zu Google Shopping. Wie du Varianten in WooCommerce oder Shopify konkret abbildest, behandeln die jeweiligen Plattform-Guides zu WooCommerce SEO und Shopify SEO.

Organization — einmal zentral, für den ganzen Shop

Der unterschätzteste Typ. Organization gehört einmal auf die Startseite oder eine dedizierte Über-uns-Seite und beschreibt das Unternehmen hinter dem Shop: offizieller Name, Logo, Adresse, Kontaktmöglichkeiten und über sameAs die verifizierten Profile bei LinkedIn, Instagram oder in Branchenverzeichnissen. Für Shops ist er inzwischen doppelt wichtig, weil Google Rückgaberichtlinien und Treueprogramme auf Organisationsebene erwartet, statt sie in jedes einzelne Angebot zu schreiben. Praktisch gedacht ist Organization der Entitäts-Anker deiner Marke: Er verknüpft die verstreuten Erwähnungen im Netz mit einem eindeutigen Absender.

BreadcrumbList und LocalBusiness

BreadcrumbList bildet den Navigationspfad ab und ist der Typ mit dem besten Verhältnis von Aufwand zu Wirkung: Er ersetzt die nackte URL im Suchergebnis durch eine lesbare Hierarchie und macht Suchmaschinen wie KI-Systemen gleichzeitig deine Kategoriestruktur explizit. LocalBusiness ist nur relevant, wenn zum Shop ein physischer Standort mit Kundenverkehr gehört — Ladengeschäft, Showroom, Abholstation. Dann ergänzt er Öffnungszeiten, Geokoordinaten und Zahlungsarten. Ohne echten Standort hat er nichts auf der Seite zu suchen; erfundene Standortdaten sind ein Richtlinienverstoß, kein Ranking-Trick.

Review und AggregateRating

Bewertungssterne im Suchergebnis sind der auffälligste Rich-Result-Effekt überhaupt — und zugleich der Bereich mit den strengsten Regeln, insbesondere zur Frage, welche Bewertungen ausgezeichnet werden dürfen und welche nicht. Weil das Thema eigene Tiefe hat, behandeln wir es ausführlich im Ratgeber zu Kundenbewertungen sammeln. Zwei Punkte gehören trotzdem hierher: Das Markup darf nur Bewertungen abbilden, die auf der Seite auch sichtbar sind, und selbst ausgezeichnete Bewertungen der eigenen Leistung ohne unabhängige Quelle sind nicht zulässig.

Was 2026 nicht mehr zählt

Hier trennt sich aktuelle Praxis von veralteten Anleitungen, die noch massenhaft im Netz stehen. FAQPage und HowTo lösen seit den Änderungen ab August 2023 keine Rich Results mehr aus — FAQ war zwischenzeitlich auf behördliche und medizinische Websites beschränkt und ist inzwischen vollständig aus der Google-Dokumentation entfernt worden. Ebenso WebSite mit SearchAction: Die zugehörige Sitelinks-Suchbox wurde im November 2024 abgeschaltet. Das heißt nicht, dass dieses Markup schädlich wäre — es beschreibt weiterhin korrekt, was auf der Seite steht, und andere Systeme lesen es durchaus. Es heißt aber: Erwarte davon keine Darstellungsvorteile bei Google, und investiere die Zeit lieber in vollständiges Product- und Organization-Markup. Welche Typen aktuell überhaupt Rich Results auslösen, listet Google fortlaufend in der Übersicht der unterstützten Funktionen — diese Seite ist die einzige verlässliche Quelle dafür, weil sie sich mehrmals im Jahr ändert.

Es gibt vier gängige Wege, JSON-LD in einen Shop zu bekommen. Sie unterscheiden sich weniger in der Ausgabe als in der Frage, wer die Kontrolle über die Daten behält — und genau daran entscheidet sich, ob das Markup in zwei Jahren noch stimmt.

Weg eins: das Theme

Viele Shop-Themes bringen eigenes Schema-Markup mit. Der Vorteil: Es funktioniert ohne Zutun. Der Nachteil: Du weißt oft nicht, was genau ausgegeben wird, und beim nächsten Theme-Wechsel ist es weg. Der praktische Umgang damit ist nicht, es abzuschalten, sondern zu wissen, dass es existiert — sonst baust du später ein zweites Markup daneben und hast doppelte Daten auf der Seite.

Weg zwei: SEO-Plugin oder App

Der Standardweg für WooCommerce, Shopify und Shopware. Ein SEO-Plugin erzeugt Product, Organization und BreadcrumbList automatisch aus den vorhandenen Shop-Daten und hält sie bei Preis- oder Bestandsänderungen synchron. Das ist der große Vorteil gegenüber jeder Handarbeit: Die Daten kommen aus derselben Quelle wie die sichtbare Seite und können deshalb gar nicht auseinanderlaufen. Die Regel dazu lautet: genau ein Plugin, das Schema erzeugt. Zwei aktive SEO-Plugins liefern zwei konkurrierende Product-Schemas auf derselben Seite aus — die häufigste Ursache für Warnungen zu mehrdeutigen Daten in der Search Console.

Weg drei: Google Tag Manager

Technisch möglich, in der Praxis die schwächste Option. Über den GTM ausgespieltes JSON-LD entsteht erst clientseitig beim Rendern. Google kann das grundsätzlich verarbeiten, aber erst in einem zweiten Schritt und nicht garantiert — und andere Crawler, die kein JavaScript ausführen, sehen es nie. Für einen Shop mit tausenden Produktseiten ist das ein unnötiges Risiko. Vertretbar ist der Weg als kurzfristiger Notbehelf, wenn du am Template gerade nicht arbeiten kannst; als Dauerlösung nicht.

Weg vier: eigene Komponente

Bei Headless-Setups und individuell entwickelten Frontends der sauberste Weg: eine zentrale Komponente, die aus den Produkt- oder Kategoriedaten ein typisiertes JSON-LD-Objekt baut und serverseitig rendert. Der entscheidende Gewinn ist nicht die Kontrolle, sondern die Testbarkeit — Schema wird damit zu Code, den du wie jeden anderen Code prüfen und versionieren kannst. Aufwand: überschaubar. Voraussetzung: dass die Daten wirklich aus einer Quelle kommen und nicht parallel gepflegt werden.

Die Verknüpfung nicht vergessen

Unabhängig vom Weg gilt: Die einzelnen Blöcke sollten aufeinander verweisen, statt isoliert nebeneinanderzustehen. Über @id lassen sich Entitäten eindeutig referenzieren — die Produktseite verweist auf dieselbe Organisation, die auf der Startseite definiert ist, statt sie erneut zu beschreiben. Aus einer Sammlung einzelner Angaben wird so ein zusammenhängender Graph, in dem klar ist, dass alle Produkte zum selben Absender gehören.

Strukturierte Daten sind stiller Code. Bricht das Markup, sieht die Seite völlig normal aus — nur die Rich Results verschwinden, oft mit Wochen Verzögerung und ohne dass jemand den Zusammenhang zum Deploy vor drei Wochen herstellt. Deshalb gehören zwei Dinge dazu: eine Prüfung vor dem Ausrollen und eine laufende Beobachtung danach.

Die drei Werkzeuge und ihre Rollen

Der Rich-Results-Test von Google beantwortet die Frage, ob eine bestimmte URL für ein bestimmtes Rich Result infrage kommt, und zeigt eine Vorschau. Er prüft nur die Typen, die Google für Darstellungen nutzt — was er ignoriert, ist deshalb nicht falsch, sondern für Google nur irrelevant.

Der Schema Markup Validator auf schema.org prüft dagegen gegen das vollständige Vokabular, ohne Google-Filter. Ihn brauchst du immer dann, wenn du wissen willst, ob dein Markup insgesamt sauber ist — auch die Teile, die keine Rich Results auslösen.

Die Search Console ist das einzige der drei Werkzeuge, das dir sagt, was auf dem gesamten Shop passiert statt auf einer einzelnen URL. Sie führt pro erkanntem Typ einen eigenen Bericht mit Fehlern, Warnungen und gültigen Seiten. Die Unterscheidung ist wichtig: Ein Fehler bedeutet, dass eine Pflichtangabe fehlt und die Seite deshalb nicht für das Rich Result infrage kommt. Eine Warnung betrifft empfohlene Angaben — die Seite bleibt gültig, die Darstellung fällt aber weniger reichhaltig aus. Fehler zuerst, Warnungen danach.

Was ein sinnvoller Rhythmus ist

Prüfe je einen Vertreter pro Seitentyp — Produkt, Kategorie, Startseite, Ratgeberartikel — mit dem Rich-Results-Test, statt hundert Produktseiten einzeln durchzugehen. Kommen alle aus demselben Template, hast du mit vier Prüfungen den ganzen Shop abgedeckt. Danach reicht ein monatlicher Blick in die Search-Console-Berichte, plus eine Prüfung nach jedem größeren Eingriff: Theme-Update, Plugin-Wechsel, Template-Umbau, Migration. Genau dort entstehen die Regressionen. Ein zusätzlicher Frühwarnindikator kostet nichts: Wenn ein Berichtstyp in der Search Console plötzlich hunderte Seiten weniger als gültig ausweist, ist meist nicht Google schuld, sondern ein Deploy.

Aus unseren technischen Audits wiederholen sich sechs Fehlerbilder so regelmäßig, dass sich eine Checkliste daraus ableiten lässt. Sie sind nach Häufigkeit sortiert, nicht nach Schwere.

1. Doppeltes Markup. Theme und SEO-Plugin liefern beide ein Product-Schema aus, oder eine Bewertungs-App baut ein drittes daneben. Google meldet dann mehrdeutige Daten und wählt im Zweifel keine Variante. Prüfen lässt sich das in einer Minute: Seitenquelltext öffnen und zählen, wie oft application/ld+json vorkommt und welche Typen darin stehen.
2. Markup ohne sichtbaren Inhalt. Bewertungen im Schema, die auf der Seite nirgends stehen. Verfügbarkeiten, die das Frontend anders anzeigt. Das ist der klare Richtlinienverstoß aus Kapitel eins und der Weg zur manuellen Maßnahme.
3. Abweichende Preise. Preis und Währung müssen auf der Seite, im Schema, im Warenkorb und gegebenenfalls im Merchant Center identisch sein. Klassische Ursache: Das Schema zeigt den Bruttopreis, die Seite den Nettopreis — oder eine Rabattaktion greift nur im Frontend.
4. Veraltete Typen im Einsatz. FAQPage, HowTo und WebSite mit SearchAction werden weiterhin eingebaut, weil ältere Anleitungen sie empfehlen. Sie schaden nicht, liefern bei Google aber keinen Darstellungsvorteil mehr.
5. Markup nur auf der kanonischen Version. Bei Seiten mit identischem Inhalt unter mehreren URLs gehört dasselbe Markup auf alle Varianten, nicht nur auf die kanonische.
6. Nicht crawlbare Bild-URLs. Bilder im Schema, die per robots.txt gesperrt sind oder hinter einer Zugriffsbeschränkung liegen. Damit fällt die Pflichtangabe faktisch aus.

Warum strukturierte Daten für KI-Suchsysteme zählen

Ein wachsender Teil der Produktrecherche beginnt nicht mehr in der klassischen Suche, sondern in Systemen, die Antworten zusammenfassen und Quellen zitieren. Diese Systeme müssen aus einer Seite in kurzer Zeit belastbare Fakten ziehen. Ein Datenblock, in dem Preis, Verfügbarkeit, Marke und Anbieter ausdrücklich benannt sind, ist dafür naheliegend hilfreicher als derselbe Inhalt, der nur im Fließtext und in Layout-Elementen steckt.

Wichtig ist die ehrliche Einordnung: Anders als bei Rich Results, wo die Anforderungen dokumentiert und die Auswirkungen messbar sind, gibt es für die Zitierhäufigkeit in KI-Systemen keine offizielle Spezifikation und keine breit angelegte, belastbare Studie. Was wir aus unserer Projektarbeit sehen, ist ein konsistentes Muster: Seiten mit vollständigem, fehlerfreiem Markup tauchen häufiger als Quelle auf als vergleichbare Seiten ohne. Wir behandeln das als gut begründete Arbeitshypothese, nicht als bewiesene Kennzahl — und empfehlen strukturierte Daten deshalb nicht primär als KI-Maßnahme, sondern weil sie sich schon über Rich Results rechnen. Der mögliche Zusatznutzen kommt ohne weiteren Aufwand obendrauf. Welche Maßnahmen darüber hinaus auf Sichtbarkeit in KI-Systemen einzahlen, behandeln wir im Ratgeber zur Generative Engine Optimization.

Einordnung: Schema ist Verstärker, kein Fundament

Zum Schluss die nüchterne Perspektive: Strukturierte Daten sind kein Ranking-Faktor im engeren Sinn. Sie machen eine schlechte Seite nicht sichtbar und ersetzen weder eigenständige Inhalte noch eine saubere technische Basis. Was sie tun, ist die vorhandene Substanz maschinenlesbar machen und damit besser darstellbar. Bei Kiwabo war sauberes Product- und Organization-Markup einer von mehreren Bausteinen im Zusammenspiel aus Migration, SEO, SEA und Serverside-Tracking, die zusammen über 210 Prozent mehr organischen Traffic gebracht haben — nicht die Ursache allein, aber ein Teil davon. Genau so gehört das Thema eingeordnet: als Verstärker für das, was inhaltlich ohnehin trägt.