Produkt-Schema, das KI-Systeme wirklich auslesen: Leitfaden für Produktseiten
Von Robin Laseur
Ein Katalog besteht auf jedem Template den Rich Results Test und trägt trotzdem nichts zu KI-generierten Produktempfehlungen bei. Das kommt so häufig vor, dass es eher die Regel ist als die Ausnahme. Am gewählten Schema-Typ liegt es selten, und ein KI-spezifisches Produkt-Markup, das man installieren könnte, gibt es nicht. Ob Markup genutzt wird oder nur im Code steht, hängt von drei Fragen ab. Erreicht es den Crawler überhaupt? Enthält es die Kennungen und Angebotsdaten, mit denen eine Seite für Produktdarstellungen infrage kommt? Und stimmt es mit der Seite und dem Feed überein?
Dieser Leitfaden geht die vier Zustände durch, in denen sich ein Katalog befinden kann. Sie erfahren, wie Sie feststellen, welcher diese Woche auf Sie zutrifft, und in welcher Reihenfolge Sie vorgehen. Diese Reihenfolge funktioniert bei einem Shop mit fünftausend SKUs, nicht nur bei einem Demoprodukt.
Was „Schema für die KI-Suche“ tatsächlich bedeutet
Streichen Sie zuerst eine ganze Kategorie Arbeit, die es gar nicht gibt. Google stellt in KI-Funktionen und Ihre Website klar, dass keine neuen maschinenlesbaren Dateien, keine KI-Textdateien und keine speziellen strukturierten Daten von schema.org nötig sind, um in diesen Funktionen zu erscheinen. Es gibt keinen Typ AIProduct und keinen eigenen Dialekt für Answer Engines. Außerhalb von Google ist je nach Plattform unterschiedlich gut belegt, wie strukturierte Daten genutzt werden. Ehrlich gesagt: Für manche Oberflächen ist es dokumentiert, für andere nicht bestätigt.
Worauf Sie sich bei strukturierten Daten verlassen können: Mehrdeutigkeit verschwindet. In maschinenlesbarer Form steht fest, was eine Seite verkauft, was es kostet, ob es verfügbar ist, wer es herstellt und welche globale Kennung es trägt. Kein nachgelagertes System muss diese Fakten dann noch aus dem Layout ableiten. Dieser Nutzen gilt unabhängig davon, ob ein Suchindex, eine Shopping-Oberfläche oder ein Modell die Daten liest, das gerade eine Empfehlung zusammenstellt.
Die Dokumentation von Google zu strukturierten Daten für Produkte teilt die Arbeit in zwei Klassen. Die sollten Sie kennen, bevor Sie eine Zeile JSON-LD schreiben. Produkt-Snippets gelten für Seiten, auf denen das Produkt nicht direkt gekauft werden kann, mit mehr Optionen für Bewertungsinformationen. Händlereinträge (Merchant Listings) gelten für Seiten, auf denen Kunden direkt bei Ihnen kaufen können, mit mehr Optionen für Produktdetails wie Größen, Versand und Rücksendungen. Für einen Shopify-Shop sind Händlereinträge Ihre Klasse. Laut Google kommen Seiten, die deren Pflichtangaben erfüllen, in der Regel auch für Produkt-Snippets infrage.
Noch ein Punkt, der die Planung verändert. Google zufolge kommen Sie für die meisten Darstellungen infrage, wenn Sie sowohl strukturierte Daten auf der Seite als auch einen Merchant-Center-Feed liefern. Manche Darstellungen kombinieren beides: Produkt-Snippets können den Preis aus dem Feed ziehen, wenn er im Markup der Seite fehlt. Markup und Feed sind also keine Alternativen. Sie bestätigen sich gegenseitig.
Erst prüfen: In welchem der vier Zustände steckt Ihr Katalog?
Vier Prüfungen in dieser Reihenfolge zeigen Ihnen, welcher Teil der Arbeit für Sie gilt. Jede dauert auf einer einzelnen Produktseite ein paar Minuten und lässt sich danach per Skript auf den ganzen Katalog anwenden.
Die meisten Kataloge mittelgroßer Marken befinden sich in zwei oder drei dieser Zustände gleichzeitig. Arbeiten Sie sie in der obigen Reihenfolge ab. Eine Korrektur weiter unten bringt nichts, solange das Problem weiter oben besteht.
Wenn Ihr Schema den Crawler nie erreicht
Dieser Zustand erzeugt die typische Frustration: gültiges Markup, aber keine Ergebnisse. Und genau ihn übersieht ein Testtool am ehesten, weil es JavaScript rendert, bevor es prüft.
Auf Shopify ist das Muster leicht zu erkennen. Das Basis-Markup für Product steckt im Theme und wird serverseitig gerendert. So weit kein Problem. Dann fügt eine Bewertungs-App aggregateRating und review clientseitig in die Seite ein, eine Personalisierungs- oder Währungs-App schreibt den Preis nach dem Laden um, und eine Schema-App hängt einen zweiten Product-Block an den des Themes an. Die gerenderte Seite sieht vollständig aus. Im rohen Dokument fehlt die Hälfte.
Daraus folgen zwei Dinge. Systeme, die JavaScript ausführen, sehen eine Version Ihres Produkts. Systeme, die das ausgelieferte HTML lesen, sehen eine andere. Und gerade die Kennungen und Bewertungen, die für Produktdarstellungen am meisten zählen, stecken oft in der Hälfte, die ein Skript braucht. Google veröffentlicht Hinweise zum Generieren strukturierter Daten mit JavaScript. Es lohnt sich, sie zu lesen, gerade weil Google das als Fall behandelt, der Sorgfalt verlangt, und nicht als Standard, auf den man sich verlassen kann.
Die Lösung liegt in der Architektur, nicht in einem cleveren Trick. Geben Sie einen einzigen, serverseitig gerenderten Product-Block aus, der jede Eigenschaft enthält, die gelesen werden soll. Dazu gehören auch die Bewertungen, die Sie beim Rendern aus Ihrer Bewertungsplattform ziehen, statt sie nachträglich einzufügen. Entfernen Sie doppelte Blöcke, damit ein einziges Objekt die Seite beschreibt. Testen Sie im Seitenquelltext, nicht im Inspector.
Wenn Ihr Schema gültig, aber dünn ist
Die Validierung bestätigt die Syntax. Ob Sie genug sagen, um nützlich zu sein, bestätigt sie nicht.
Die Pflichtangaben für Händlereinträge drehen sich darum, das Produkt zu identifizieren und ein vollständiges Angebot zu beschreiben: wie es heißt, ein Bild und ein offers-Block mit Preis, Währung und Verfügbarkeit. Damit ist die Mindestanforderung erfüllt. Erst die empfohlenen Eigenschaften erweitern, wofür Sie infrage kommen. Gerade diese Eigenschaften machen ein Produkt auch abgleichbar mit dem, was ein Käufer sucht: globale Kennungen wie gtin, die Marke (brand), die sku, Bewertungsdaten, sofern echte Rezensionen existieren, sowie die Erweiterungen für Versanddetails und Rücksendungen. Google empfiehlt außerdem, Ihre Geschäftsrichtlinien im Organization-Markup anzugeben, darunter Ihre Rückgaberichtlinie und, falls vorhanden, Details zu Ihrem Treueprogramm.
Die praktische Regel für einen großen Katalog: Behandeln Sie Kennungen als Pflicht, auch wenn die Spezifikation sie nur empfiehlt. Ein Produkt ohne gtin und brand lässt sich schwer mit demselben Produkt an anderer Stelle abgleichen. Und genau über diesen Abgleich zwischen Quellen wird ein Produkt als eine eindeutige Einheit erkannt statt als mehrere, bei denen das System unsicher ist.
Blähen Sie nichts auf. Bewertungs-Markup ohne echte Rezensionen dahinter oder Spezifikationswerte, die erfunden sind, um ein Feld zu füllen, erzeugen genau die Widersprüche, um die es als Nächstes geht.
Wenn Ihre Daten sich widersprechen
Jeder Shopify-Shop einer mittelgroßen Marke beschreibt jedes Produkt an mindestens drei Stellen: im Seitentext, im JSON-LD und im Merchant-Center-Feed. Eine vierte kommt hinzu, sobald ein ERP oder PIM eine davon befüllt. Solange nichts die Übereinstimmung erzwingt, laufen sie auseinander.
Die üblichen Abweichungen sind banal und teuer. Währung und Preis unterscheiden sich zwischen Märkten, weil das Schema den Hauptmarkt fest codiert, während die Seite lokalisierte Preise anzeigt. Das Markup meldet „auf Lager“, während die Seite eine ausverkaufte Variante zeigt. Der Produkttitel im Feed trägt einen kanalspezifischen Zusatz, den die Seite nicht verwendet. Eine Kennung steht im Feed und fehlt auf der Seite.
Da manche Darstellungen laut Google Seiten-Markup und Feed-Daten kombinieren, ist die Übereinstimmung zwischen beiden keine Nebensache. Von ihr hängt ab, ob das Gesamtbild stimmig ist. Legen Sie pro Feld ein führendes System fest, meist die Plattform für Preis und Verfügbarkeit und das PIM für Attribute und Kennungen. Alle anderen Kanäle beziehen ihre Daten dann daraus, statt eine eigene Kopie zu pflegen.
Varianten und Skalierung: das Problem mit fünftausend SKUs
Hier trennt sich eine Demo-Implementierung von einer, die funktioniert. Die meisten Leitfäden behandeln das nur am Rande.
Eine einzelne Produktseite mit zehn Größen und vier Farben kann Markup auf drei Arten ausgeben. Ein generisches Product-Objekt, das keine der Optionen beschreibt: verbreitet und für den Abgleich nahezu nutzlos. Vierzig unverbundene Product-Objekte, was nach Duplikaten aussieht. Oder ein deklariertes Elternprodukt mit angehängten Varianten. Genau dafür gibt es die strukturierten Daten für Produktvarianten von Google. Damit legen Sie fest, welche Produkte Varianten desselben Elternprodukts sind, und sowohl Produkt-Snippets als auch Händlereinträge unterstützen das.
Die Struktur sieht ungefähr so aus. Prüfen Sie die genauen Eigenschaften vor dem Livegang anhand der Variantendokumentation von Google, denn die Spezifikation ist detaillierter als jedes Beispiel:
{
“@context”: “https://schema.org/”,
“@type”: “ProductGroup”,
“name”: “Trail Runner Jacket”,
“brand”: { “@type”: “Brand”, “name”: “Example Brand” },
“productGroupID”: “TRJ-001”,
“variesBy”: [“https://schema.org/size”, “https://schema.org/color”],
“hasVariant”: [
{
“@type”: “Product”,
“sku”: “TRJ-001-M-BLK”,
“gtin13”: “0000000000000”,
“size”: “M”,
“color”: “Black”,
“offers”: {
“@type”: “Offer”,
“price”: “189.00”,
“priceCurrency”: “EUR”,
“availability”: “https://schema.org/InStock”
}
}
]
}
Bei einem ganzen Katalog wird aus der Modellierungsfrage eine operative: Wo liegen die Werte Ihrer Variantenattribute heute in Ihrem Shop? Auf Shopify verteilen sie sich meist auf native Variantenoptionen, Metafelder und unstrukturierten Beschreibungstext. Nur die ersten beiden lassen sich zuverlässig per Template in Markup überführen. Jedes Attribut, das nur im Fließtext existiert, muss erst in ein Metafeld wandern, bevor es sich als strukturierte Daten ausdrücken lässt. Bei fünftausend SKUs ist diese Migration das eigentliche Projekt, nicht das JSON-LD.
Deshalb beginnt die Reihenfolge unten bei den Daten und nicht bei den Templates.
Reihenfolge der Umsetzung und die Prüfschleife
Sieben Schritte, in der Reihenfolge, die am wenigsten Nacharbeit verursacht.
Ist-Zustand erfassen, und zwar mit allen vier Prüfungen an einer repräsentativen Stichprobe: ein einfaches Produkt, ein Produkt mit mehreren Varianten, ein Bundle und ein Produkt mit Bewertungen. Vier Seiten sagen Ihnen mehr als vierhundert.
Zuerst das Rendering beheben. Reduzieren Sie auf einen serverseitig gerenderten Product- oder ProductGroup-Block pro Seite und entfernen Sie doppelte oder clientseitig eingefügte Blöcke. Nichts anderes zählt, solange Ihr Markup nicht im rohen Quelltext steht.
Felder den Quellen zuordnen. Legen Sie pro Eigenschaft fest, welches System sie verantwortet. Halten Sie das in einer Tabelle fest, die Entwickler und Merchandiser gleichermaßen lesen.
Attribute aus dem Fließtext in Metafelder verschieben, zuerst die, nach denen Käufer in Ihrer Kategorie tatsächlich filtern. Das ist der langsame Schritt, und zugleich der, der sich in jedem Kanal auszahlt.
Das Markup als Template anlegen, inklusive Varianten, und Kennungen zuerst bei den umsatzstärksten SKUs befüllen statt alphabetisch.
Seite, Markup und Feed abgleichen, für eine Stichprobe je Produkttyp. Beheben Sie Abweichungen an der Quelle, statt die Ausgabe zu flicken.
Den Kreis schließen. Validieren Sie mit dem Rich Results Test auf Template-Ebene und überwachen Sie danach die Berichte zu strukturierten Daten in der Search Console auf Katalogebene. Tests pro Template zeigen nämlich nicht den einen Produkttyp, bei dem ein Feld leer ankommt.
Behandeln Sie Schritt sieben als wiederkehrende Aufgabe. Themes werden aktualisiert, Apps ändern, wie sie Markup einfügen, und ein Merchandiser, der einen neuen Produkttyp anlegt, befüllt Felder, die niemand dokumentiert hat. Strukturierte Daten verfallen still, und der Bericht, der das sichtbar macht, hat keinen Verantwortlichen.
Wenn Sie genauer wissen wollen, wie Google dieses Feld einordnet: Der Leitfaden zur Optimierung für die generative KI-Suche steht neben der Dokumentation zu strukturierten Daten, auf die sich dieser Artikel durchgehend stützt.
Sie sind nicht sicher, ob Ihr Produkt-Markup tatsächlich bei den Systemen ankommt, die es lesen? Flatline ist Shopify Platinum Partner, und Audits strukturierter Daten gehören bei Katalogen dieser Größe zu unseren technischen Projekten. Sprechen Sie uns an, dann gehen wir es gemeinsam mit Ihnen durch.
Häufig gestellte Fragen
Gibt es einen speziellen Schema-Typ für die KI-Suche?
Nein. Laut Google-Dokumentation sind für die KI-Funktionen keine neuen Dateien und keine speziellen strukturierten Daten von schema.org nötig, und einen eigenen Markup-Dialekt für Answer Engines gibt es nicht. Nutzen Sie das Standardvokabular für Product, vollständig und konsistent umgesetzt. Ob Markup genutzt wird oder nicht, entscheiden Rendering, Vollständigkeit und die Übereinstimmung mit Ihren anderen Datenquellen.
Sagt mir der Rich Results Test, ob mein Schema gut genug ist?
Er sagt Ihnen, ob Ihr Markup gültig ist und für welche Rich Results es infrage kommt. Er sagt nicht, ob das Markup den Crawler als ausgeliefertes HTML erreicht hat, ob Ihre Kennungen vollständig sind oder ob die Werte mit Ihrem Feed übereinstimmen. Prüfen Sie den rohen Seitenquelltext separat und gleichen Sie mit dem Merchant Center ab, statt sich allein auf die Validierung zu verlassen.
Brauche ich für jedes Produkt eine GTIN?
Google führt Kennungen unter den empfohlenen, nicht den erforderlichen Eigenschaften. Für einen Katalog, der um Produktempfehlungen konkurriert, sind sie aber praktisch unverzichtbar. Über Kennungen wird dasselbe Produkt aus verschiedenen Quellen zu einer eindeutigen Einheit zusammengeführt. Für Eigenmarken ohne GTIN befüllen Sie stattdessen brand, sku und mpn konsistent.
Gehört das Schema ins Theme oder in eine App?
Ins Theme, serverseitig gerendert, für alles, was zuverlässig gelesen werden soll. Apps sind bequem, fügen Markup aber häufig erst nach dem Laden der Seite ein oder ergänzen einen zweiten, konkurrierenden Product-Block. Ist eine App Ihr einziger praktikabler Weg, prüfen Sie, ob ihre Ausgabe im ausgelieferten HTML steht und ob sie den Block, den Ihr Theme bereits ausgibt, nicht doppelt.
Das Wichtigste in Kürze
Ein KI-spezifisches Produkt-Schema gibt es nicht. Das Standardvokabular für Product, vollständig umgesetzt, ist das ganze Werkzeug. Rendering, Vollständigkeit und Konsistenz entscheiden, ob es genutzt wird.
Markup, das erst nach der Ausführung von JavaScript erscheint, bleibt für Systeme unsichtbar, die keine Skripte ausführen. Reduzieren Sie auf einen serverseitig gerenderten Block pro Seite und prüfen Sie im Quelltext statt im Inspector.
Kennungen sind formal empfohlen und praktisch notwendig. Über Marke, GTIN und SKU wird dasselbe Produkt auf der Seite, im Feed und in Drittquellen zu einer eindeutigen Einheit zusammengeführt.
Bei einem großen Katalog besteht das eigentliche Projekt darin, Attribute aus dem Fließtext in strukturierte Felder zu verschieben. Das JSON-LD-Template ist eine Woche Arbeit. Die Datenmigration darunter ist der Teil, der sich in jedem Kanal auszahlt.
Produkt-Markup belohnt Geduld, nicht Raffinesse. Ein Katalog mit vollständigen, übereinstimmenden, serverseitig gerenderten Daten für seine tausend wichtigsten SKUs steht besser da als einer mit aufwendigem Markup auf allen fünftausend und einem Widerspruch in jedem dritten Feld.
Verwandte Artikel
