Wenn du Produkte über Google sichtbar machen willst, wird strukturierte Produktinformation wieder ein Stück wichtiger. Die Änderung klingt auf den ersten Blick ziemlich technisch: Google unterstützt bei strukturierten Daten für Händlerangebote nun die Eigenschaft Product.category und ergänzt außerdem eine sauberere Möglichkeit, die Dauer von Sale-Preisen auszuzeichnen. In der Praxis steckt dahinter aber etwas, das viele Shops schon lange beschäftigt: Wie erklärst du Google möglichst eindeutig, was ein Produkt ist, in welche Kategorie es gehört und wie lange ein reduzierter Preis gelten soll?
Gerade bei E-Commerce-Projekten sehe ich immer wieder dasselbe Muster. Produktdaten sind im Shop vorhanden, im Merchant Center liegen sie ebenfalls, aber auf der Website selbst sind sie nur teilweise oder uneinheitlich strukturiert. Mal steht eine Kategorie im Breadcrumb, mal im Produkttitel, mal nur im Feed. Für Menschen ist das oft noch verständlich. Für Suchsysteme wird es schnell grauzonig. Und genau an dieser Stelle setzt die Aktualisierung an: Du kannst Google im Markup jetzt präziser mitteilen, welche Produktkategorie gemeint ist, und du kannst zeitlich begrenzte Angebote sauberer beschreiben.
Das ist keine spektakuläre Änderung im Sinne von „morgen verdoppelt sich dein Traffic“. So etwas wäre unseriös. Aber es ist eine dieser kleinen technischen Anpassungen, die sich im Laufe der Zeit auszahlen können, vor allem wenn du viele Produkte, wechselnde Rabatte oder komplexe Kategorien hast. Aus meiner Erfahrung sind es oft genau diese Details, die später den Unterschied machen zwischen Daten, die Google nur irgendwie verarbeitet, und Daten, die wirklich konsistent genug sind, um in Suche und Shopping-Umgebungen besser verstanden zu werden.
Was sich bei strukturierten Händlerdaten geändert hat
Google hat die Dokumentation für strukturierte Daten rund um Händlerangebote erweitert. Im Zentrum stehen zwei Ergänzungen. Erstens wird nun beschrieben, wie du die Eigenschaft Product.category nutzen kannst. Zweitens gibt es einen neuen Abschnitt dazu, wie sich die Gültigkeitsdauer von Sale-Preisen über schema.org-Eigenschaften ausdrücken lässt.
Das klingt trocken, ich weiß. Aber wenn du einen Shop betreibst oder SEO für einen Shop machst, solltest du bei solchen Änderungen hellhörig werden. Denn strukturierte Daten sind nicht einfach nur „Schema-Code“, den man einmal einbaut und dann vergisst. Sie sind eine Art Übersetzungsschicht zwischen deinem Shop-System und den Suchsystemen. Je klarer diese Schicht ist, desto weniger muss Google raten.
Die neue Unterstützung für Product.category bedeutet, dass du Kategorieinformationen direkt im Produkt-Markup unterbringen kannst. Interessant ist dabei, dass diese Eigenschaft mit zwei unterschiedlichen Typen verwendet werden kann: als einfacher Text und als CategoryCode. Im Grunde geht es also darum, sowohl eigene Kategorien als auch definierte Kategoriesysteme abzubilden.
Der zweite Punkt, die Sale duration, ist besonders relevant für Shops mit zeitlich begrenzten Aktionen. Wenn du zum Beispiel ein Produkt von Montag bis Sonntag reduziert anbietest, willst du nicht, dass Google Tage später noch einen alten Sonderpreis interpretiert oder dass der reduzierte Preis ohne klaren Zeitraum im Markup steht. Dafür werden Eigenschaften wie validFrom, validThrough und priceValidUntil genutzt. Sie geben an, ab wann ein Angebot gilt, bis wann es gilt oder bis wann ein Preis gültig ist.
Manchmal ist es überraschend, wie viel Chaos allein durch unklare Preiszeiträume entsteht. Ein Shop zeigt im Frontend den richtigen Preis, der Feed hat vielleicht ebenfalls aktuelle Werte, aber die strukturierten Daten hinken hinterher. Oder umgekehrt. Dann wird es unschön: Rich Results erscheinen nicht stabil, Produktinformationen wirken widersprüchlich, und in manchen Fällen können Merchant-Daten einfach weniger zuverlässig verarbeitet werden.
Product.category: Warum die Kategorie im Markup wichtiger wird
Die neue Unterstützung für Product.category ist vor allem deshalb spannend, weil Kategorien im E-Commerce oft unterschätzt werden. Viele Shop-Betreiber beschäftigen sich intensiv mit Produkttiteln, Preisen, Verfügbarkeit und Bildern. Das ist natürlich richtig. Aber die Kategorie ist ein starkes Signal dafür, wie ein Produkt verstanden und eingeordnet werden soll.
Ein einfaches Beispiel: Du verkaufst einen „Nike Air Zoom Pegasus“. Für dich ist klar, dass es ein Laufschuh ist. Für einen Nutzer wahrscheinlich auch. Aber maschinell betrachtet kann das Produkt je nach Kontext in mehrere Richtungen gehen: Sportschuhe, Damenlaufschuhe, Herrenschuhe, Sneaker, Outdoor, Fitness, Markenartikel. Eine präzise Kategorie hilft dabei, dieses Produkt sauberer im Gesamtgefüge einzuordnen.
Google zieht Produktinformationen aus verschiedenen Quellen zusammen. Dazu gehören die Website, strukturierte Daten, der Merchant-Center-Feed und weitere Signale. Je konsistenter diese Informationen sind, desto besser. Die Änderung sorgt nun dafür, dass sich Kategorieangaben im schema.org-Markup enger an die bereits bekannten Feed-Attribute anlehnen.
Merchant-definierte und Google-definierte Kategorien
Besonders wichtig ist die Unterscheidung zwischen einer Kategorie, die du selbst definierst, und einer Kategorie, die aus einem Google-Kategoriesystem stammt. In Merchant-Feeds kennst du vermutlich zwei ähnliche, aber nicht identische Felder: product_type und google_product_category.
product_type ist deine eigene Produktklassifikation. Das kann zum Beispiel etwas sein wie „Schuhe > Laufschuhe > Herren > Neutral“. Sie folgt deiner Shop-Logik. Vielleicht ist sie auf deine Navigation abgestimmt, vielleicht auf deine interne Warenwirtschaft. Sie muss nicht zwingend der offiziellen Google-Produkttaxonomie entsprechen.
google_product_category dagegen ist eine von Google definierte Kategorie. Sie dient dazu, Produkte in ein standardisiertes System einzuordnen. Diese Kategorisierung kann für Shopping-Kontexte, Anzeigen, Ausspielung und Produktverständnis relevant sein. Sie ist weniger individuell, dafür besser vergleichbar.
Mit der Unterstützung von Product.category im strukturierten Markup kannst du diese beiden Welten sauberer zusammenbringen. Du kannst Google also nicht nur sagen: „Das ist ein Produkt“, sondern auch: „Dieses Produkt gehört in diese Kategorie, und zwar aus meiner Sicht beziehungsweise anhand eines definierten Codes.“
Das klingt vielleicht nach einem kleinen semantischen Unterschied, aber in großen Shops ist das Gold wert. Stell dir vor, du hast 80.000 Produkte, mehrere Sprachen, saisonale Sortimente und Kategorien, die in der Navigation anders heißen als im Feed. Ohne klare Struktur entstehen schnell Inkonsistenzen. Ein Produkt steht im Feed als „Apparel & Accessories“, im Shop aber unter „Lifestyle“, im Breadcrumb unter „Mode“, und im Markup fehlt die Kategorie komplett. Das ist nicht automatisch ein Drama, aber es ist auch nicht gerade ein Musterbeispiel für saubere Daten.
Wenn du Product.category bewusst einsetzt, kannst du diese Lücke verkleinern. Aus meiner Sicht ist das vor allem für Shops interessant, die ohnehin schon stark mit Merchant Center, Shopping, Produkt-Rich-Results und strukturierten Daten arbeiten. Für einen winzigen Shop mit zehn Produkten ist das vielleicht kein sofortiger Hebel. Für größere Händler dagegen kann es ein weiterer Schritt hin zu konsistenter Produktdatenqualität sein.
Text oder CategoryCode: Was bedeutet das praktisch?
Die Eigenschaft Product.category kann mit Text oder CategoryCode genutzt werden. Das ist technisch relevant, weil du damit zwei Granularitätsstufen bekommst.
Mit Text kannst du eine Kategorie lesbar und frei formuliert angeben. Das passt gut für deine eigene Shop-Kategorie. Zum Beispiel „Herren-Laufschuhe“, „Bluetooth-Kopfhörer“ oder „Gartenmöbel“. Diese Darstellung ist einfach und für viele Implementierungen vermutlich der pragmatische Einstieg.
CategoryCode ist strukturierter. Hier geht es darum, eine Kategorie nicht nur als beliebige Zeichenkette zu liefern, sondern als kodierten Eintrag aus einem Kategoriesystem. Dadurch kann klarer werden, welche Taxonomie gemeint ist. Das ist besonders dann hilfreich, wenn du dich an standardisierte Kategorien anlehnst.
Ich würde an dieser Stelle nicht blind alles umbauen, nur weil eine neue Option verfügbar ist. Erst einmal solltest du prüfen, wie deine Produktdaten heute organisiert sind. Sind deine Kategorien sauber? Gibt es ein einheitliches Mapping zwischen Shop-Kategorien und Merchant-Center-Kategorien? Stimmen Feed und Website überein? Wenn nicht, bringt dir ein neues Schema-Feld nur begrenzt etwas. Strukturierte Daten sind kein Zauberstab. Sie machen gute Daten sichtbarer, aber sie reparieren keine chaotische Produktlogik.
Ein sinnvoller Ansatz wäre, zunächst deine wichtigsten Produktgruppen anzusehen. Produkte mit hohem Umsatz, hoher Sichtbarkeit oder vielen Preisaktionen. Dort lohnt es sich am ehesten, saubere Kategorieangaben im Markup zu testen und zu validieren. Danach kannst du die Implementierung ausweiten.
Sale duration: Warum zeitlich begrenzte Preise sauber ausgezeichnet werden sollten
Der zweite große Punkt ist die neue Erklärung zur Sale duration, also zur Dauer eines Sonderangebots. Hier geht es um die Frage: Wann genau beginnt ein reduzierter Preis, und wann endet er?
Im E-Commerce ist das ein ausgesprochen praktisches Thema. Black Friday, Cyber Week, Sommer-Sale, Flash Deals, Rabattwochen, Gutscheinkampagnen, Lagerabverkauf – fast jeder Shop arbeitet irgendwann mit zeitlich begrenzten Preisen. Das Problem ist nur: Diese Zeiträume müssen überall konsistent sein. Im Frontend, im Feed, im Backend, in Anzeigen und eben auch in strukturierten Daten.
Google beschreibt dafür die Nutzung von Eigenschaften wie validFrom, validThrough und priceValidUntil. Diese Eigenschaften stammen aus schema.org und helfen dabei, den effektiven Zeitraum eines Angebots oder Preises einzugrenzen.
validFrom sagt vereinfacht: Ab diesem Zeitpunkt gilt das Angebot. validThrough sagt: Bis zu diesem Zeitpunkt gilt es. priceValidUntil bezieht sich konkreter auf die Gültigkeit eines Preises. Je nachdem, wie dein Markup aufgebaut ist, können diese Angaben an unterschiedlichen Stellen sitzen, etwa an einem Offer-Knoten oder an einem PriceSpecification-Knoten.
Das klingt nach Entwicklerdetail, und ja, teilweise ist es das auch. Aber die dahinterliegende Frage ist geschäftlich relevant: Wenn du Google einen Sale-Preis zeigst, sollte klar sein, dass es ein temporärer Preis ist und nicht einfach der dauerhaft gültige Normalpreis.
Offer oder PriceSpecification: Wo gehört die Zeitangabe hin?
Eine der hilfreichen Klarstellungen ist, dass Zeitangaben je nach Struktur entweder am Offer oder an der PriceSpecification platziert werden können. Das ist wichtig, weil Produkt-Markup nicht in jedem Shop gleich aufgebaut ist.
Viele einfache Implementierungen arbeiten mit einem Produkt und einem Angebot. Dort finden sich Preis, Währung, Verfügbarkeit und URL direkt im Offer. Wenn du nur einen Preis und ein einfaches Angebot hast, liegt es nahe, auch die Gültigkeitsdauer dort anzugeben.
Komplexere Shops nutzen hingegen detailliertere Preisstrukturen. Vielleicht gibt es verschiedene Preisbestandteile, Varianten, Staffelpreise, Mitgliedspreise oder regionale Unterschiede. Dann kann PriceSpecification sinnvoller sein, um genauer zu beschreiben, welcher Preis unter welchen Bedingungen gilt.
Aus praktischer Sicht ist nicht entscheidend, dass du die eleganteste theoretische Modellierung findest. Entscheidend ist, dass dein Markup eindeutig, konsistent und testbar ist. Wenn Entwickler, SEO-Team und Feed-Verantwortliche nach zwei Monaten nicht mehr erklären können, warum ein Datum an genau dieser Stelle im JSON-LD steht, ist das meistens kein gutes Zeichen.
Ich habe in Projekten häufiger gesehen, dass Sale-Daten technisch zwar vorhanden waren, aber zeitlich versetzt aktualisiert wurden. Der Shop zeigte ab Mitternacht den neuen Preis, der Feed wurde erst am Morgen neu generiert, strukturierte Daten kamen aus einem Cache und waren noch vom Vortag. Dann brauchst du dich nicht wundern, wenn Systeme widersprüchliche Signale sehen. Gerade bei Sales mit kurzer Laufzeit kann so etwas richtig ärgerlich werden.
Die Verbindung zum Merchant Center
Die Ergänzung zur Sale-Dauer orientiert sich an dem Merchant-Center-Attribut sale_price_effective_date. Dieses Attribut kennst du vielleicht aus Feeds: Es legt den Zeitraum fest, in dem ein Sale-Preis wirksam sein soll. Die Neuerung sorgt dafür, dass die Verwendung im schema.org-Markup besser zu dieser Feed-Logik passt.
Das ist eine wichtige Entwicklung, weil Website-Markup und Merchant-Feed lange Zeit in vielen Unternehmen getrennte Welten waren. Das SEO-Team kümmerte sich um strukturierte Daten. Das Performance-Marketing-Team kümmerte sich um den Feed. Die Entwickler bauten beides irgendwie ins System ein. Und wenn etwas nicht passte, suchte jeder an einer anderen Stelle.
Wenn strukturierte Daten und Merchant-Center-Attribute stärker aufeinander abgestimmt werden, reduziert das Reibung. Jedenfalls dann, wenn du es sauber umsetzt. Du solltest also nicht nur fragen: „Wie baue ich validFrom ein?“ Sondern eher: „Sind die Datumswerte im Markup dieselben wie im Feed? Wird dieselbe Zeitzone genutzt? Werden Sale-Preise automatisch entfernt, wenn die Aktion endet? Was passiert bei kurzfristigen Preisänderungen?“
Das klingt pedantisch, aber genau dort passieren in der Realität die Fehler. Ein Datum ohne Zeitzonenverständnis kann reichen, damit ein Sale früher oder später ausläuft als gedacht. Ein gecachter JSON-LD-Block kann alte Preise ausgeben. Ein Template kann bei Varianten den falschen Angebotszeitraum verwenden. Es sind selten die großen strategischen Fehler. Es sind die kleinen technischen Schlampereien, die am Ende Vertrauen kosten.
Was du als Händler oder SEO jetzt konkret daraus machen solltest
Wenn du strukturierte Produktdaten bereits nutzt, solltest du die Änderung nicht ignorieren. Du musst aber auch nicht panisch alles neu schreiben. Ich würde es nüchtern angehen: Prüfe deine aktuelle Implementierung, gleiche sie mit deinen Feed-Daten ab und entscheide dann, wo die neuen Möglichkeiten echten Mehrwert bringen.
Der erste Blick sollte auf deine Produktkategorien gehen. Nutzt du im Feed sowohl eigene Produkttypen als auch Google-Kategorien? Sind diese Kategorien gepflegt oder historisch gewachsen? Stimmen sie mit der Website-Struktur überein? Wenn du dort schon Unordnung findest, beginne nicht beim Schema-Markup, sondern bei der Datenbasis. Sonst zementierst du nur Chaos in maschinenlesbarer Form.
Danach kannst du überlegen, ob du Product.category in dein Produkt-Markup aufnimmst. Bei einfachen Shops kann eine Text-Kategorie ausreichend sein. Bei größeren oder stärker feedgetriebenen Shops kann eine strukturiertere Abbildung mit CategoryCode sinnvoll sein. Wichtig ist, dass die Information nicht beliebig ist, sondern stabil aus deinem Produktdatenmodell kommt.
Der zweite Blick gehört deinen Sale-Preisen. Wenn du regelmäßig Aktionen fährst, solltest du prüfen, ob das Markup klar zwischen Normalpreis und Aktionspreis unterscheidet und ob der Zeitraum der Aktion sauber angegeben wird. Besonders relevant ist das bei kurzen Kampagnen, bei denen ein Preis nur wenige Tage oder Stunden gilt.
Aus meiner Erfahrung lohnt sich hier ein kleiner Testprozess. Nimm ein Produkt mit bevorstehender Aktion, prüfe vor dem Start das Markup, prüfe es während der Aktion und danach noch einmal. Klingt simpel, wird aber erstaunlich selten gemacht. Dabei findest du so sehr schnell heraus, ob dein System alte Preise stehen lässt, ob Datumsfelder korrekt gesetzt werden und ob strukturierte Daten synchron mit dem sichtbaren Frontend laufen.
Auch die Platzierung der Eigenschaften solltest du mit deinem technischen Setup abstimmen. Wenn dein Markup einfach aufgebaut ist, reicht möglicherweise die Auszeichnung direkt auf Offer. Wenn du mit komplexeren Preisangaben arbeitest, kann PriceSpecification passender sein. Es gibt hier nicht für jeden Shop dieselbe perfekte Lösung. Wichtig ist, dass du eine nachvollziehbare Struktur wählst und sie konsequent durchziehst.
Warum diese Änderung mehr ist als ein Dokumentationsdetail
Auf dem Papier ist die Änderung klein. Google ergänzt ein unterstütztes Kategorie-Feld und beschreibt sauberer, wie Sale-Zeiträume in strukturierten Daten angegeben werden können. Fertig. Aber im größeren Kontext zeigt sie, wohin die Reise geht: Produktdaten sollen über Website, Feed und Markup hinweg konsistenter werden.
Für dich bedeutet das: Je professioneller dein Produktdaten-Setup ist, desto besser bist du auf solche Entwicklungen vorbereitet. SEO für Shops wird weniger eine reine Frage von Keywords und Kategorietexten. Es geht immer stärker um Datenqualität, technische Konsistenz und maschinenlesbare Produktinformationen. Das ist nicht besonders romantisch, aber es ist die Realität.
Ich würde die Änderung deshalb als Anlass nehmen, deine Produktdaten einmal mit frischem Blick anzusehen. Nicht hektisch, nicht mit der Erwartung eines sofortigen Ranking-Sprungs, sondern solide. Stimmen Kategorien? Stimmen Sale-Zeiträume? Werden Preise zuverlässig aktualisiert? Gibt es Unterschiede zwischen Feed, Frontend und strukturierten Daten? Wenn du auf diese Fragen gute Antworten hast, bist du den meisten Wettbewerbern wahrscheinlich schon einen Schritt voraus.
Der wichtigste Punkt bleibt: Strukturierte Daten sollen Google nicht etwas vorgaukeln, sondern vorhandene Informationen eindeutig erklären. Wenn du ein Produkt sauber kategorisierst und zeitlich begrenzte Preise klar auszeichnest, hilfst du Suchsystemen dabei, deine Angebote besser zu verstehen. Und genau darum geht es hier im Kern.
Für kleine Shops ist diese Neuerung vielleicht erst einmal ein technisches Detail, das man im nächsten Entwicklungszyklus mitnimmt. Für größere Händler, Marktplätze oder Shops mit häufigen Rabattaktionen ist sie deutlich relevanter. Dort können klarere Kategorien und präzise Sale-Zeiträume dazu beitragen, Produktinformationen in Suche und Shopping-Umfeldern verständlicher und belastbarer zu machen.
Mein Fazit wäre daher recht bodenständig: Product.category und Sale duration sind keine Wundermittel, aber sie sind sinnvolle Bausteine für saubere Händlerdaten. Wenn du ohnehin an deinem Produkt-Markup arbeitest, solltest du diese Ergänzungen einplanen. Und wenn du schon länger den Verdacht hast, dass deine Feed-Daten, Shop-Daten und strukturierten Daten nicht ganz sauber zusammenspielen, dann ist jetzt ein guter Moment, genau dort aufzuräumen.
