Schema.org Product 2026: was Pflicht ist, was empfohlen wird und wo Rückgabe und Versand deklariert gehören

Die Google-Dokumentation zu Produktseiten trennt zwei Dinge, die viele Artikel vermischen: die Eigenschaften, die eine Seite für ein Rich Result überhaupt qualifizieren, und die Eigenschaften, die dieses Ergebnis anreichern, wenn sie vorhanden sind. Rückgabe- und Versandangaben gehören zur zweiten Gruppe. Search Central führt sie ausdrücklich unter den Ergebnis-Erweiterungen, zusammen mit Bewertungen, Verfügbarkeit und Preissenkungen.

Dieser Artikel geht das Product-Markup so durch, wie es dokumentiert ist, Abschnitt für Abschnitt: was Pflicht ist, was nicht, und wo jeder Block auf PrestaShop 8/9 und WooCommerce hingehört.

Die Pflichtbasis besteht aus fünf Eigenschaften

Auf Product:

• name
• image, eine oder mehrere crawlbare und indexierbare URLs
• offers

Auf Offer:

• price oder priceSpecification.price
• priceCurrency oder priceSpecification.priceCurrency

Dazu kommen drei Bedingungen. Merchant-Listing-Darstellungen verlangen ein Offer und kein AggregateOffer, weil Sie selbst der Verkäufer sind. Der Preis muss größer als null sein. Und die Seite muss ein einzelnes Produkt oder dessen Varianten behandeln, keine Liste und keine Kategorie.

Google unterscheidet außerdem zwei Markup-Familien. Das Product Snippet zielt auf Seiten, auf denen man nicht direkt kaufen kann, typischerweise ein redaktioneller Test, mit zusätzlichen Optionen rund um Rezensionen. Das Merchant Listing zielt auf Seiten, auf denen der Besucher bei Ihnen kauft, mit Größenangaben, Versand und Rückgabe. Wer die Pflichteigenschaften des Merchant Listing erfüllt, ist in der Regel auch für Product Snippets qualifiziert.

Alles Weitere ist empfohlen

Die Tabelle der empfohlenen Eigenschaften von Offer enthält availability, itemCondition, url, priceValidUntil, validFrom, validThrough, hasMerchantReturnPolicy und shippingDetails. Auf Product: brand.name, sku, mpn, die gtin-Familie, description, category, color, size, material, pattern, audience, hasCertification, review, aggregateRating, inProductGroupWithID, isVariantOf und subjectOf.

Diese Eigenschaften schalten Darstellungen frei: Durchschnittsbewertung, Versandkosten und Gratisversand, Verfügbarkeit, Rückgabeinformationen, Preissenkung. Google hält fest, dass Erweiterungen nach Ermessen der jeweiligen Darstellung angezeigt werden und sich ändern können, und rät deshalb, so viele Produktinformationen wie vorhanden bereitzustellen, statt auf eine bestimmte Darstellung hinzuarbeiten.

Der Satz, der die Debatte entscheidet: Das Veröffentlichungsverfahren verlangt, die vom Rich Results Test gemeldeten kritischen Fehler zu beheben, und ergänzt, dass nicht kritische Hinweise die Qualität der strukturierten Daten verbessern können, ihre Behebung für die Eignung zu Rich Results aber nicht nötig ist. Und genau als nicht kritisch erscheinen „Missing field hasMerchantReturnPolicy“ und „Missing field shippingDetails“ in der Search Console.

Rückgabe und Versand gehören auf die Organization-Ebene

Für eine Rückgaberichtlinie, die den ganzen oder fast den ganzen Katalog abdeckt, verlangt Google eine einmalige Deklaration auf der Seite, die diese Richtlinie beschreibt, in einer MerchantReturnPolicy unter Organization (oder OnlineStore) über hasMerchantReturnPolicy. Eine Wiederholung auf jeder Seite ist nicht nötig.

Auf dieser Ebene gibt es zwei minimale Markup-Optionen:

• Option A: applicableCountry und returnPolicyCategory. Lautet die Kategorie MerchantReturnFiniteReturnWindow, wird merchantReturnDays zur Pflicht.
• Option B: merchantReturnLink, die URL der Seite, die Kunden die Richtlinie erklärt.

Der Rest ist empfohlen und erlaubt Präzision: returnFees, returnMethod, returnShippingFeesAmount, returnPolicyCountry, refundType, restockingFee, returnLabelSource, itemCondition, die Varianten customerRemorse* und itemDefect* sowie returnPolicySeasonalOverride, um das Zeitfenster im Weihnachtsgeschäft zu verkürzen.

{
  "@context": "https://schema.org",
  "@type": "OnlineStore",
  "name": "Mein Shop",
  "url": "https://example.com",
  "hasMerchantReturnPolicy": {
    "@type": "MerchantReturnPolicy",
    "@id": "https://example.com/rueckgabe#policy",
    "applicableCountry": ["DE", "AT"],
    "returnPolicyCountry": "DE",
    "returnPolicyCategory": "https://schema.org/MerchantReturnFiniteReturnWindow",
    "merchantReturnDays": 30,
    "returnMethod": "https://schema.org/ReturnByMail",
    "returnFees": "https://schema.org/FreeReturn",
    "refundType": "https://schema.org/FullRefund"
  }
}

Die Offer-Ebene dient nur zwei Fällen: der Abweichung von der Standardrichtlinie bei einem bestimmten Produkt, oder dem Fehlen einer Standardrichtlinie. Die dort unterstützten Eigenschaften sind eine Teilmenge derjenigen auf Shop-Ebene. Um die globale Richtlinie eindeutig aus einer Produktseite zu referenzieren, genügt eine @id:

"hasMerchantReturnPolicy": { "@id": "https://example.com/rueckgabe#policy" }

Der Versand folgt derselben Logik. Die Standardrichtlinie wird unter Organization deklariert, mit einem größeren Eigenschaftssatz als auf Produktebene, und eine Produktseite kann über hasShippingService darauf verweisen:

"shippingDetails": {
  "@type": "OfferShippingDetails",
  "hasShippingService": { "@id": "https://example.com/versand#policy" }
}

Wer den Versand direkt auf Offer-Ebene ausschreibt, braucht für die Erweiterung vier Eigenschaften: deliveryTime (mit handlingTime und transitTime), shippingDestination (mit addressCountry nach ISO 3166-1 Alpha-2), shippingRate.currency sowie shippingRate.value oder shippingRate.maxValue. Ein Tarif pro OfferShippingDetails-Block: mehrere Tarife bedeuten mehrere Blöcke.

Markup steht in der Prioritätenreihenfolge ganz hinten

Google dokumentiert eine Rangfolge für Rückgabeinformationen, von der stärksten zur schwächsten Quelle:

1. Content API for Shopping, Rückgabeeinstellungen
2. Einstellungen im Merchant Center oder in der Search Console
3. Markup auf Produktseiten-Ebene
4. Markup auf Organization-Ebene

Zwei praktische Folgen. Sind Ihre Rückgaben bereits in der Search Console oder im Merchant Center konfiguriert, wird diese Konfiguration verwendet und das Markup wird redundant. Und fehlendes Markup auf einer Produktseite bedeutet für Google nicht „keine Rückgaberichtlinie“: Google geht schlicht die Kette weiter, um die Information zu finden. Für einen Katalog mit häufig wechselnden Versandkosten empfiehlt die Dokumentation ohnehin das Merchant Center statt des Markups.

priceValidUntil ist kein jährlich zu erneuerndes Datum

Offizielle Definition: das Datum und die Uhrzeit, ab denen der Preis nicht mehr verfügbar sein wird, im ISO-8601-Format. Die Dokumentation nennt genau eine Warnung, und es ist nicht die überall zitierte: Ihr Eintrag wird womöglich nicht angezeigt, wenn priceValidUntil ein vergangenes Datum enthält. Das Risiko entsteht durch ein abgelaufenes Datum, nicht durch eine fehlende Eigenschaft.

Seit der Überarbeitung des Abschnitts zur Aktionsdauer hat die Eigenschaft eine klare Aufgabe: einen Rabatt zeitlich zu begrenzen. Der Beginn steht in validFrom, das Ende in validThrough oder priceValidUntil. Google empfiehlt, beide Grenzen anzugeben, den Beginn vor dem Ende zu halten und Uhrzeit sowie Zeitzone mitzuliefern.

"offers": {
  "@type": "Offer",
  "price": 10.00,
  "priceCurrency": "EUR",
  "validFrom": "2026-11-20T08:00:00+01:00",
  "priceValidUntil": "2026-11-30T23:59:59+01:00",
  "priceSpecification": {
    "@type": "UnitPriceSpecification",
    "priceType": "https://schema.org/StrikethroughPrice",
    "price": 15.00,
    "priceCurrency": "EUR"
  }
}

Auf die Platzierung achten. Am Offer-Knoten sind priceValidUntil und validThrough austauschbar. An einem PriceSpecification-Knoten funktioniert nur validThrough: priceValidUntil ist dort nicht anwendbar.

Hat Ihr Preis kein echtes Enddatum, lassen Sie priceValidUntil weg. Ein automatisch erzeugtes, rollierendes Ein-Jahres-Datum beschreibt nichts und kündigt ein Aktionsende an, das es nicht gibt.

Streichpreis, Mitgliederpreis, Grundpreis

Drei Preisarten werden erkannt, kodiert in priceSpecification unter Offer:

• Aktiver Preis: weder priceType noch validForMemberTier. Er kann auch auf Angebotsebene in price stehen bleiben.
• Streichpreis: priceType mit dem Wert https://schema.org/StrikethroughPrice. Er löst die Aktionsdarstellung aus, der aktive Preis wird zum Aktionspreis.
• Mitgliederpreis: validForMemberTier mit Verweis auf eine MemberProgramTier, definiert im Merchant Center oder in einem MemberProgram unter Organization.

Die beiden Marker lassen sich nicht kombinieren: eine Preisspezifikation mit priceType und validForMemberTier zugleich wird ignoriert. Füllen Sie für den aktiven Preis sowohl offers.price als auch offers.priceSpecification, verwendet Google offers.price.

Bei Waren, die nach Volumen, Gewicht oder Länge verkauft werden, läuft der Grundpreis über referenceQuantity in einer UnitPriceSpecification. Die Dokumentation weist darauf hin, dass dieses Format besonders in der EU, in Neuseeland und in Australien zählt.

Varianten: ProductGroup und zwei mögliche Strukturen

Auf ProductGroup ist nur eine Eigenschaft Pflicht: name. Die Gruppen-ID wird entweder mit productGroupID am ProductGroup (die übergeordnete SKU) oder mit inProductGroupWithID an jeder Variante deklariert. Geben Sie beides an, müssen die Werte übereinstimmen. variesBy listet die Variationsachsen, mit sechs unterstützten Werten: color, size, material, pattern, suggestedAge und suggestedGender.

Zwei Strukturen sind dokumentiert. Entweder sind die Varianten über hasVariant in die ProductGroup eingebettet, oder sie stehen daneben und verweisen über isVariantOf und eine @id auf das übergeordnete Element. Google empfiehlt die erste und beschreibt sie als kompakteste und natürlichste Darstellung. Die zweite lässt sich aus einem CMS oft leichter erzeugen.

Die technischen Bedingungen wiegen so schwer wie das Markup selbst. Jede Variante braucht eine eindeutige Kennung (sku oder gtin) und eine eigene URL, die sie vorauswählt, mit passendem Bild, Preis und Verfügbarkeit sowie der Möglichkeit, sie in den Warenkorb zu legen. Bei einer Single-Page-Umsetzung repräsentiert genau eine kanonische URL die Gruppe. Bei mehreren Seiten braucht jede Seite ein vollständiges, in sich geschlossenes Markup, mit wiederholter ProductGroup-Definition.

Energielabel: hasCertification

Für Haushaltsgeräte, Leuchtmittel oder Bildschirme, die in der EU verkauft werden, ist hasCertification mit einem Certification-Objekt die richtige Eigenschaft:

• issuedBy.name: EC oder European_Commission für EU-Energielabel, ADEME und BMWK für CO2-Klassen von Fahrzeugen.
• name: EPREL, Vehicle_CO2_Class oder Vehicle_CO2_Class_Discharged_Battery.
• certificationIdentification: der EPREL-Code, für europäische Energielabel erforderlich.
• certificationRating: für Fälle ohne EPREL-Code (Norwegen, Schweiz, Vereinigtes Königreich) oder für CO2-Klassen. ratingValue ist Pflicht, bei der Energieeffizienz zusätzlich bestRating und worstRating.

Bis zu zehn Zertifizierungen pro Produkt. Die ältere Eigenschaft hasEnergyConsumptionDetails wird weiterhin gelesen, die Dokumentation empfiehlt jedoch den Wechsel zu hasCertification.

Und die AI Overviews?

Keine öffentliche Google-Dokumentation macht das Erscheinen in AI Overviews von hasMerchantReturnPolicy, shippingDetails oder einer anderen Product-Eigenschaft abhängig. Diese Eigenschaften sind für Merchant-Listing-Darstellungen dokumentiert: Shopping-Knowledge-Panel, Popular Products, Google Bilder, Google Lens und Product Snippets.

Sauberes Markup hilft den Systemen von Google, die Seite zu verstehen, und das allein rechtfertigt die Sorgfalt. Solange aber weder Dokumentation noch eine reproduzierbare Studie das belegt, gibt es keine Grundlage, Budget auf einen Ursache-Wirkungs-Zusammenhang zwischen diesen Eigenschaften und generativen Antworten zu setzen.

Umsetzung auf PrestaShop 8 und 9

Das Classic-Theme erzeugt Product-JSON-LD mit offers, aber weder die Rückgabe- und Versandrichtlinien noch die ProductGroup-Struktur für Varianten. Zwei getrennte Baustellen, die man auseinanderhalten sollte.

Katalogseite. Entweder überschreiben Sie das Template, das das JSON-LD ausgibt, in Ihrem Child-Theme, mit dem Wartungsaufwand bei jedem Versionssprung, oder Sie setzen ein Modul ein. In beiden Fällen prüfen: pro Seite darf nur ein Product-Block ausgegeben werden. Zwei aktive SEO-Module erzeugen zwei konkurrierende Markups.

Shopseite. Rückgabe- und Versandrichtlinie werden einmal deklariert, auf den zugehörigen CMS-Seiten, in einem Organization-Block. Am einfachsten über ein Feld für eigenen Code, das in den Head dieser beiden Seiten eingefügt wird.

Das Modul DataFirefly All in One SEO deckt die erste Baustelle ab: JSON-LD-Graph mit Organization, WebSite, BreadcrumbList, Product inklusive offers, priceValidUntil und dem AggregateRating aus productcomments, dazu FAQPage und LocalBusiness. Es liefert außerdem Felder für eigenen Code im Head und am Body-Ende, in die die Richtlinien auf Shop-Ebene gehören.

Umsetzung auf WooCommerce

WooCommerce gibt nativ ein Product mit offers aus, änderbar über den Filter woocommerce_structured_data_product. Yoast SEO und Rank Math bauen jeweils einen eigenen Graph und bieten einen eigenen Erweiterungspunkt. Wählen Sie genau eine dieser drei Quellen: alles zu stapeln bedeutet mehrere Product-Blöcke auf derselben URL.

Bei den Richtlinien gilt dieselbe Logik wie bei PrestaShop: ein Organization-Block auf der Rückgabeseite und auf der Versandseite, aus den Produktseiten per @id referenziert, wenn Sie jede Mehrdeutigkeit ausschließen wollen. Das Plugin llms.txt + AEO Schema WooCommerce übernimmt diesen Graph-Teil und die FAQ für Agenten.

Das Ergebnis prüfen

1. Rich Results Test. Kritische Fehler beheben. Nicht kritische Hinweise liegen bei Ihnen: entscheiden Sie nach den Erweiterungen, die Sie erreichen wollen.
2. Schema.org-Validator. JSON-LD-Syntax und Konsistenz der @type, unabhängig von Google-Regeln.
3. Search Console, Bericht Merchant listings. Der reale Produktionsstand, sobald die Seiten neu gecrawlt wurden. Rechnen Sie mit mehreren Tagen nach Veröffentlichung.
4. Merchant Center oder Search Console, Rückgabeeinstellungen. Prüfen, ob eine bestehende Konfiguration Ihr Markup bereits übersteuert.

Womit anfangen

1. Prüfen, ob name, image, offers, price und priceCurrency auf 100 % der Produktseiten vorhanden und korrekt sind. Das ist der einzige echte Blocker.
2. availability, itemCondition, sku, brand.name ergänzen, dazu die GTIN, wo vorhanden.
3. Rückgabe- und Versandrichtlinie einmal auf Organization-Ebene deklarieren, auf den jeweiligen Seiten.
4. priceValidUntil nur bei Preisen mit echtem Enddatum setzen, zusammen mit validFrom.
5. Varianten über ProductGroup abbilden, nachdem sichergestellt ist, dass jede Variante eine eigene URL hat.

Über allem steht eine Regel: Das Markup muss beschreiben, was die Seite zeigt. Eine ausgezeichnete Gratisrückgabe muss auf der Website angekündigt sein, eine ausgezeichnete 30-Tage-Frist muss eine echte 30-Tage-Frist sein. Dieses Prinzip, und nicht die Anzahl der Eigenschaften, steckt hinter den meisten manuellen Maßnahmen zu strukturierten Daten.

Ebenfalls lesenswert: der vollständige E-Commerce-SEO-Leitfaden und FAQ-Schema und Rich Snippets.

Zum Umsetzen: unsere Auswahl an Modulen für bessere Produktseiten.