Product-Schema

TL;DR — Produktschema ist Code, den Sie einer Produktseite hinzufügen und der die Produktdetails für Suchmaschinen kennzeichnet – „das ist der Name“, „das ist der Preis“, „das ist auf Lager“, „das sind die Bewertungssterne“. Wenn Sie es korrekt hinzufügen, wird die Seite berechtigt für die umfangreicheren Suchergebnisse, die Sie bei Shopping-Ergebnissen sehen (Preis, Verfügbarkeit, Sternebewertungen). Es garantiert nicht, dass diese Extras angezeigt werden, und es ist nicht dasselbe wie das Hochladen eines Produkt-Feeds zu Google Merchant Center.

Was Produktschema ist

Wenn Sie sich eine Produktseite ansehen, können Sie den Preis vom Produktnamen vom „Auf Lager“-Label allein durch Lesen unterscheiden. Eine Suchmaschine sieht reinen Text und muss raten. Produktschema erklärt es in Code, unter Verwendung des gemeinsamen schema.org – Vokabulars – es taggt jedes Stück der Seite mit dem, was es tatsächlich ist: den name, ein image, den price und die Währung, ob es InStock ist, und alle Bewertungen.

Es wird fast immer als JSON-LD geschrieben – ein kleiner Codeblock, der in der Seite sitzt, ohne das Aussehen der Seite zu verändern.

Warum es sich lohnt

Der Vorteil sind Rich Results: die erweiterten Suchergebnisse bei Produktanfragen. Zwei Arten:

• ⭐ Produkt-Snippets – Sternebewertungen und ein Preis unter einer normalen Produktseite.
• 🛒 Merchant Listings – das umfangreichere, Shopping-artige Ergebnis (Preis, Verfügbarkeit, manchmal Versand und Rückgabe) auf Seiten, auf denen der Artikel direkt dort gekauft werden kann. Evidence for this claim Google uses Product structured data for product snippets and merchant listing experiences when applicable requirements are met. Scope: Google Search Product documentation; eligibility does not guarantee display. Confidence: high · Verified: 2026-07-14 Google: Product structured data

Ein auffälligeres Listing kann mehr Klicks bringen. Es gibt auch eine wachsende Praktiker-Theorie – nicht von Google dokumentiert –, dass KI-Shopping-Tools dieses Markup lesen, um Ihre Produkte zu verstehen. Es ist unbewiesen, aber das Markup korrekt zu setzen kostet nichts extra, also lohnt es sich trotzdem.

Die vier Dinge, die Sie fast immer brauchen

Um für das leichtere Produkt-Snippet-Erlebnis berechtigt zu sein, benötigen Sie den Namen des Produkts und mindestens eines dieser drei: ein Angebot (Preisinformationen), eine Bewertung oder eine aggregierte Bewertung (eine durchschnittliche Sternebewertung). Das strengere Merchant Listing-Erlebnis benötigt immer ein Angebot – es ist dort nicht optional, wie es bei einem Snippet der Fall ist. In der Praxis nehmen die meisten Geschäfte alle vier auf:

• name – der Name des Produkts.
• image – ein gutes Produktfoto (erforderlich für das Shopping-artige Listing).
• offers – mit einem price und priceCurrency (wie USD) und einer availability (wie InStock oder OutOfStock).
• review / aggregateRating – wenn Sie echte Kundenbewertungen haben.

Das, was die meisten falsch verstehen

Produktschema und ein Google Merchant Center-Feed sind nicht dasselbe. Das Schema geht auf Ihre Seite. Ein Merchant Center-Feed ist eine separate Datei, die Sie an Google übermitteln. Sie beeinflussen sich überschneidende Shopping-Ergebnisse, und Google prüft sie gegenseitig – aber sie werden separat validiert, und das Beheben des einen behebt nicht das andere. Mehr dazu im Tab „Erweitert“.

Zwei weitere Anfängerfallen:

• Gültiges Markup ≠ garantiertes Rich Result. Es macht Sie berechtigt; Google entscheidet weiterhin, ob es angezeigt wird.
• Markieren Sie nur, was wirklich auf der Seite steht, und halten Sie Preis und Lagerbestand in Ihrem Markup passend zu dem, was ein Käufer tatsächlich sieht. Abweichungen werden gekennzeichnet.

Möchten Sie die vollständige Version – die Aufteilung Snippet vs. Merchant Listing, die Verfügbarkeitswerte, die Feed-Beziehung und wie Sie Search Console-Fehler beheben? Wechseln Sie zum Tab Erweitert.

TL;DR — schema.org/Product-Markup (normalerweise JSON-LD) macht eine Produktseite für zwei verschiedene Google-Erlebnisse geeignet: Produkt-Snippets (Preis/Bewertungen auf jeder Produktseite – priceCurrency nur empfohlen, price: 0 erlaubt) und Merchant Listings (transaktionale Seiten – erfordern image, offers und einen price > 0 mit priceCurrency). Minimum für ein Produkt-Snippet: name plus mindestens eines von offers/review/aggregateRating – ein Merchant Listing benötigt offers direkt, nicht als eine Option unter drei. Die größte Falle ist, dieses On-Page-Markup mit einem Google Merchant Center Feed zu verwechseln – separates System, separater Validator; Google gleicht sie ab, und Preis/Verfügbarkeit müssen über Markup, Feed und Checkout übereinstimmen, sonst markiert Google eine Diskrepanz. Gültiges Markup verdient nur Berechtigung; die Systeme von Google entscheiden weiterhin, ob sie das Ergebnis anzeigen. Ob Sie für den Implementierungsansatz dieses Artikels oder den breiteren Ecommerce-SEO-Ansatz hier sind, beides befindet sich am selben Ort – dieses Thema ist aus genau diesem Grund unter strukturierte Daten und unter Ecommerce-SEO kreuzgelistet.

Was Product-Schema bewirkt – zwei Erlebnisse, nicht eines

Die meisten Anleitungen reduzieren „Product-Schema“ auf eine einzige Anforderungsliste. Google unterteilt es tatsächlich in zwei Rich-Result-Erlebnisse mit unterschiedlicher Strenge, und zu wissen, auf welches Sie abzielen, ist die halbe Miete:

• Produkt-Snippets – für nicht-transaktionale oder allgemeine Produktseiten, mit Schwerpunkt auf Bewertungen und Preis. Geringere Anforderungen.
• Merchant Listings – für Seiten, auf denen das Produkt direkt gekauft werden kann, mit Schwerpunkt auf vollständigen Einkaufsdetails (Preis, Verfügbarkeit, Versand, Rückgabe). Strengere Anforderungen. Evidence for this claim Google documents separate product snippet and merchant listing experiences with different property requirements. Scope: Google Search Product documentation; validate against the intended experience. Confidence: high · Verified: 2026-07-14 Google: Product structured data

Googles eigene Darstellung: „Zwei Markup-Typen existieren: Produkt-Snippets für Nicht-Kaufseiten, mit Schwerpunkt auf Bewertungen, und Merchant Listings für Kaufseiten, die Produktdetails wie Größe und Versand hervorheben.“ Dieselbe schema.org/Product-Vokabular zugrunde liegend – der Unterschied liegt darin, welche Eigenschaften Google für jede verlangt.

Erforderliche vs. empfohlene Eigenschaften

Das Minimum für ein Produkt-Snippet – das leichtere der beiden Erlebnisse von Google: Product.name, plus mindestens eines von offers, review oder aggregateRating. Diese „eins von drei“-Flexibilität ist spezifisch für Produkt-Snippets. Ein Merchant Listing benötigt immer offers – Googles eigene Tabelle der erforderlichen Eigenschaften listet name, image und offers als erforderlich auf, Punkt, ohne Entweder-Oder. Und eine Abgrenzungsregel, die man verinnerlichen sollte – Google: „Produkt-Rich-Results unterstützen nur Seiten, die sich auf ein einzelnes Produkt konzentrieren (oder mehrere Varianten desselben Produkts).“ Eine Kategorieseite („Schuhe in unserem Shop“) ist kein Produkt; für eine Reihe von Varianten greifen Sie stattdessen zu ProductGroup-Markup (ein direktes Schwesterthema).

ProductGroup sollte echte Varianten im Katalog beschreiben, nicht jede theoretische Konfiguration, die ein Selektor berechnen könnte. Eine Variante sollte eine stabile Identität, echte Attribute, einen erreichbaren oder auswählbaren Zustand und ein Angebot haben, welches das Commerce-System aktuell halten kann. Das kartesische Produkt jeder Option auszugeben, kann gültig aussehendes Markup erzeugen, das Produkte erfindet, die Käufer nicht auswählen oder kaufen können. Die detaillierten Aufnahmeregeln finden Sie in Product Variant SEO.

Produktebene

Angebotsebene (offers, ein Offer-Objekt)

Die zwei Regeln, welche die meisten übersehen: Für Händlerlistings gilt: “merchant listing experiences require a price greater than zero” (Übersetzung) „Händlerlisting-Erlebnisse erfordern einen Preis größer als null“ (Produkt-Snippets tolerieren 0), und priceCurrency ist für Händlerlistings erforderlich, für einfache Produkt-Snippets jedoch nur “currently recommended” (Übersetzung) „derzeit von Google empfohlen“.

Die availability-Eigenschaft und ihre Enum-Werte

availability ist für die Eignung nicht strikt erforderlich, behandeln Sie diese aber als wesentlich – sie steuert das Label „Auf Lager“ / „Nicht auf Lager“, das Nutzer sehen, und sie ist ein zentrales Feld, das Google mit Ihrem Merchant-Center-Feed abgleicht. Sie verwendet ein schema.org-Enum, und die Übergabe eines einfachen Strings wie "in stock" anstelle des URL-/Enum-Werts ist einer der häufigsten Validierungsfehler.

Der vollständige Satz, den Google für Product dokumentiert:

Für die SEO-Behandlung von nicht vorrätigen und eingestellten Artikeln – ob sie behalten, weiterleiten oder mit noindex versehen werden sollen – geht der Artikel out-of-stock products im E-Commerce- Cluster tiefer als das Markup allein.

Der E-Commerce-Verfügbarkeitsvertrag

availability ist keine direkte Kopie einer Lagerbestandsmenge. Ein Produkt kann physisch existieren, aber in einem Markt unverkäuflich sein, für eine ausgewählte Variante nicht verfügbar sein, auf Abholung beschränkt sein, eine Postleitzahl nicht erreichen können oder an der Kasse vorübergehend blockiert sein. Gleichen Sie die gesamte Entscheidungskette ab:

Wählen Sie einen maßgeblichen Commerce-Dienst für die zugrunde liegende Entscheidung und bilden Sie dessen Zustände dann bewusst auf die kleineren Vokabulare ab, die von schema.org, Google- oder Microsoft-Feeds sowie agentischen Commerce-Integrationen gefordert werden. Lassen Sie nicht zu, dass jede Vorlage und jeder Feed eine eigene Übersetzung von available, backorderable, pickup-only oder discontinued erfindet. Evidence for this claim Google treats on-page Product structured data and Merchant Center feeds as separate, complementary ways to provide product data. Scope: Google Search ecommerce guidance; the systems can be reconciled but are validated separately. Confidence: high · Verified: 2026-07-14 Google: Share product data

Die vom Postleitzahlbereich abhängige Auftragsabwicklung erfordert zwei Ebenen der Wahrheit. Die Landingpage, das Markup und der Feed sollten das allgemein veröffentlichte Angebot korrekt angeben; nachdem ein Kunde einen Standort angegeben hat, können die Seite und der Checkout das spezifischere Erfüllungsergebnis anzeigen. Veröffentlichen Sie InStock nicht nur deshalb, weil ein Lager eine Einheit hat, wenn der dargestellte Markt sie nicht kaufen kann, und markieren Sie nicht das gesamte übergeordnete Produkt als OutOfStock, nur weil eine Größe, ein Geschäft oder eine Liefermethode nicht verfügbar ist. Der Product Variant SEO-URL-Vertrag gilt, wenn sich die Verfügbarkeit mit der ausgewählten SKU ändert.

Validieren Sie nach Katalog-, Vorlagen-, Feed- oder Auftragsabwicklungsänderungen mindestens diese repräsentativen Zustände:

• eine normale, auf Lager befindliche SKU;
• eine vorübergehend nicht verfügbare oder nachbestellbare SKU;
• eine nicht verfügbare Variante innerhalb einer ansonsten verfügbaren Produktgruppe;
• eine auf Postleitzahl beschränkte Lieferung mit verfügbarer Abhol- oder Filialoption;
• ein eingestellter Artikel;
• ein kürzlich wieder aufgefüllter Artikel vor und nach der Feed-Aktualisierung.

Erfassen Sie für jeden Zustand die sichtbare Auswahl, das rohe und gerenderte Markup, die Feed-Zeile, die Warenkorbzeile und das Checkout-Ergebnis. Ein bestandener Rich Results Test beweist die Markup-Berechtigung; er beweist nicht die Aktualität des Feeds, die personalisierte Auftragsabwicklung oder den Kaufabschluss.

Produktschema vs. Google Merchant Center-Feeds – separat validiert

Das ist die Verwirrung, die ich am liebsten beseitigen möchte. Produktschema-Markup und ein Merchant Center-Produktfeed sind zwei getrennte Systeme. Google gleicht sie ab, aber sie sind keine einzige Übermittlung und werden nicht gemeinsam validiert.

Google nennt die drei Optionen: “To provide rich product data to Google Search you can add Product structured data to your web pages, upload data feeds with Google Merchant Center and opt into free listings within the Merchant Center console, or both.” (Übersetzung) „Um der Google-Suche umfangreiche Produktdaten bereitzustellen, können Sie Product-Strukturdaten auf Ihren Webseiten ergänzen, Datenfeeds über Google Merchant Center hochladen und dort kostenlose Einträge aktivieren oder beide Wege kombinieren.“ Evidence for this claim Google treats on-page Product structured data and Merchant Center feeds as separate, complementary ways to provide product data. Scope: Google Search ecommerce guidance; the systems can be reconciled but are validated separately. Confidence: high · Verified: 2026-07-14 Google: Share product data Und dazu, warum Sie beides tun könnten: “Providing both structured data on web pages and a Merchant Center feed maximizes your eligibility to experiences and helps Google correctly understand and verify your data. Some experiences combine data from structured data and Google Merchant Center feeds if both are available. For example, product snippets may use pricing data from your merchant feed if it’s not present in the structured data on the page.” (Übersetzung) „Strukturierte Daten auf Webseiten zusammen mit einem Merchant-Center-Feed maximieren Ihre Berechtigung für Darstellungen und helfen Google, Ihre Daten richtig zu verstehen und zu überprüfen. Einige Darstellungen kombinieren beide Datenquellen; Produkt-Snippets können beispielsweise Preisdaten aus dem Feed verwenden, wenn sie in den strukturierten Daten der Seite fehlen.“

Lesen Sie das genau: Sie werden kombiniert, wenn verfügbar, genau das ist der Grund, warum die Leute annehmen, es sei dasselbe System. Die praktischen Konsequenzen:

• Zwei Validatoren. Das Markup wird mit dem Rich Results Test geprüft und in der Search Console überwacht; der Feed wird mit den Merchant Center-Diagnosen geprüft. Ein bestandener Rich Results Test sagt nichts darüber aus, ob Ihr Feed gültig ist, und umgekehrt.
• Sie benötigen keinen Feed, um einen Händlereintrag zu erhalten. Allein On-Page-Structured-Data können Rich Results für Händlereinträge erzeugen. Wie John Mueller es formulierte, gibt es auch “the possibility to submit a feed to your merchant center account, to show products there.” (Übersetzung) „die Möglichkeit, einen Feed an Ihr Merchant-Center-Konto zu übermitteln, um dort Produkte anzuzeigen.“ Der Feed ist ein additiver Weg, keine Voraussetzung.

Halten Sie Preis und Verfügbarkeit in Markup, Feed und Checkout konsistent

Die Merchant-Center-Spezifikation ist eindeutig: Händler müssen “den Preis und die Währung des Produkts genau angeben und mit dem Preis auf Ihrer Landingpage, den strukturierten Daten und beim Checkout übereinstimmen.” Preis und Verfügbarkeit müssen also an drei Stellen übereinstimmen: in Ihrem Offer auf der Seite, in Ihrem Merchant-Center-Feed und beim tatsächlichen Checkout. Wenn sie voneinander abweichen, kann Google eine Diskrepanz kennzeichnen oder den Artikel sperren, selbst wenn Ihr JSON-LD sauber validiert. Sauberes Markup ist notwendig; Konsistenz hält den Eintrag aktiv. Wenn Sie auch bei Bing verkaufen, gilt dieselbe Disziplin für das Microsoft Merchant Center – dessen Feed-System ist das Bing-Pendant zu Googles System. Gleichen Sie bei Varianten das gesamte ausgewählte Angebot ab – nicht nur Preis und Bestand. Produktidentität, SKU, Gruppen-ID, ausgewählte Attribute, Preis, Währung und Verfügbarkeit sollten sich auf dasselbe verkäufliche Produkt auf der sichtbaren PDP, im gerenderten JSON-LD, im Feed sowie im Warenkorb und beim Checkout beziehen.

Bewertungen und Rezensionen – und der Mythos der eigennützigen Rezensionen

review und aggregateRating bleiben dokumentierte, berechtigte Product-Eigenschaften für Sternebewertungen – daran hat sich nichts geändert. Zwei Regeln müssen Sie beachten:

• Rezensentennamen müssen eine Person oder ein Team sein, kein Werbetext. Googles Beispiele: “Nicht empfohlen: ‘50 % Rabatt am Black Friday’. Empfohlen: ‘James Smith’ oder ‘CNET Reviewers’.”
• Vor- und Nachteile-Strukturierte Daten sind nur für redaktionelle Inhalte. Google: “Nur redaktionelle Produktrezensionsseiten sind für die Darstellung von Vor- und Nachteilen in den Suchergebnissen berechtigt.” Ein Händler, der sein eigenes Produkt beschreibt, kann sie nicht verwenden.

Nun zu dem Mythos, den ich präzise korrigieren möchte, weil er ständig verfälscht wird:

“Google hat die Sternebewertungen für Produktseiten abgeschafft, genauso wie bei Unternehmensbewertungen.” – Falsch, und der Unterschied ist wichtig.

Die Beschränkung für eigennützige Rezensionen gilt für LocalBusiness / Organization-Markup, nicht für Product. Googles Wortlaut: “Wenn die bewertete Entität die Bewertungen über sich selbst kontrolliert, sind ihre Seiten, die LocalBusiness oder eine andere Art von Organization-Strukturierten Daten verwenden, nicht für das Sternebewertungs-Feature berechtigt.” Diese Richtlinie stammt aus September 2019 und zielt auf eine Unternehmensbewertung selbst. Product review/aggregateRating sind weiterhin berechtigt.

Was sich verschärft hat, ist die breitere Durchsetzung echter Bewertungen – Googles Reviews-System, die Product-Reviews-Updates und die Richtlinie gegen Site-Reputation-Missbrauch werten manipulierte oder incentivierte Bewertungen zunehmend ab, selbst wenn das Markup validiert. Die korrekte Aussage lautet also: Produkt-Sternebewertungen sind weiterhin berechtigt, aber die Bewertungen müssen echt, nutzergeneriert und über das Produkt sein – kein pauschales Verbot strukturierter Daten. Aggregieren Sie außerdem keine Bewertungen von anderen Websites in Ihr eigenes Markup; Googles Anleitung ist ein klares “Aggregieren Sie keine Rezensionen oder Bewertungen von anderen Websites.” Die tiefergehende Diskussion zur Berechtigung findet sich in den Geschwisterartikeln Review-Schema und AggregateRating-Schema und nicht hier.

Identifikatoren und Vertrauenssignale: sku, gtin, mpn, brand

Diese sind in der eigenen Spezifikation von Search als “empfohlen”, nicht “erforderlich” gekennzeichnet – aber sie haben echtes Gewicht auf der Merchant-Center-/Shopping-Seite, wo der Produktabgleich mit dem globalen Katalog davon abhängt:

• gtin – der globale Identifikator (UPC/EAN/ISBN). Das stärkste Abgleichsignal; geben Sie ihn an, wann immer das Produkt einen hat.
• mpn – Herstellernummer, für Produkte ohne GTIN.
• brand – der Hersteller-/Markenname (brand.name).
• sku – Ihre eigene interne Kennung.

Füllen Sie diese aus, auch wenn Search sie als optional bezeichnet; unvollständige Identifikatoren sind ein häufiger Grund, warum ein Produkt technisch berechtigt ist, aber in Shopping-Oberflächen, wo der Abgleich davon abhängt, unterdurchschnittlich abschneidet.

Rückgaberichtlinie und Versand

Für Händlerlisten sind hasMerchantReturnPolicy und shippingDetails empfohlen. Googles Leitlinie: Definieren Sie die Rückgaberichtlinie einmal auf Organisationsebene, nicht pro Angebot – “We recommend you provide a global return policy for your business under Organization markup instead… Only if some of your products have specific return policies… use this property under Offer.” (Übersetzung) „Wir empfehlen, eine globale Rückgaberichtlinie für Ihr Unternehmen im Organization-Markup anzugeben. Nur wenn einzelne Produkte besondere Rückgaberichtlinien haben, verwenden Sie diese Eigenschaft unter Offer.“ Genau hier kommt das Organization-Schema ins Spiel – die seitenweite Rückgaberichtlinie gehört dorthin, mit Überschreibungen pro Offer nur für Ausnahmen.

Zu Bildern empfiehlt Google “multiple high-resolution images (minimum of 50K pixels when multiplying width and height) with the following aspect ratios: 16x9, 4x3, and 1x1.” (Übersetzung) „mehrere hochauflösende Bilder mit mindestens 50.000 Pixeln aus Breite mal Höhe in den Seitenverhältnissen 16:9, 4:3 und 1:1.“

Warum Ihr gültiges Markup trotzdem kein Rich Result zeigt

Berechtigung ist nicht Anzeige. Mueller listete auf, was es braucht: “It requires that the page be indexed, that the page has valid structured data on it, and that our systems have determined that it’s worth showing this structured data.” (Übersetzung) „Die Seite muss indexiert sein, gültige strukturierte Daten enthalten, und unsere Systeme müssen entschieden haben, dass die Anzeige dieser strukturierten Daten sinnvoll ist.“ Dieser letzte Satzteil ist der, den man vergisst – Sie können alles richtig machen und Google kann trotzdem entscheiden, die Verbesserung nicht anzuzeigen. Das korrekte Markup zu haben, bringt Sie nur ins Rennen.

JSON-LD und der KI-Shopping-Aspekt

Verwenden Sie JSON-LD – es ist Googles empfohlenes Format und bei weitem das wartbarste im E-Commerce-Maßstab (es ist nicht mit Ihrem HTML verschachtelt und kann von Ihrer Plattform injiziert werden). Über klassische Rich Results hinaus gibt es eine wachsende Praktiker-Theorie, dass vollständiges Product-Schema auch KI-Shopping-Tools dabei hilft, Produkte zu lesen und zu empfehlen – es lohnt sich, dies als offenen, unverifizierten Aspekt zu kennzeichnen, statt als etwas, das Googles Dokumentation zu strukturierten Daten für Produkte etabliert oder verspricht. Das korrekte Markup kostet in beiden Fällen nichts extra, also behandeln Sie es als vernünftige Wette, nicht als garantierte Auszahlung.

Wo das Product-Schema im größeren Bild strukturierter Daten steht, finden Sie in den breiteren Schema-Markup- und Strukturierte-Daten-Hubs, unter denen dieser Artikel verschachtelt ist; für die vollständige Produktseite siehe die Produktseiten-SEO-Arbeit im E-Commerce-Cluster.

KI-Zusammenfassung

Eine komprimierte Darstellung der erweiterten Version:

• Was es ist: schema.org/Product-Markup (normalerweise JSON-LD), das Name, Bild, Preis, Verfügbarkeit, Kennungen und Bewertungen einer Produktseite auszeichnet, damit Suchmaschinen Shopping-ähnliche Rich Results erzeugen können.
• Zwei Erfahrungen, unterschiedliche Strenge: Produkt-Snippets (beliebige Produktseiten; Bewertungen/Preis; priceCurrency nur empfohlen; price: 0 erlaubt) vs. Merchant Listings (transaktionale Seiten; erfordern image, offers und price > 0 mit priceCurrency).
• Minimum für ein Produkt-Snippet: name + mindestens eines von offers/review/aggregateRating. Das ist snippet-spezifisch – ein Merchant Listing erfordert offers direkt, nicht als eine von drei Optionen. Nur Einzelproduktseiten (oder Varianten eines Produkts) kommen infrage; verwenden Sie ProductGroup für eine Variantenlinie.
• Feed vs. Markup (die zentrale Verwirrung): Produkt-Schema (auf der Seite, validiert über Rich Results Test / Search Console) ist ein separates System von einem Google Merchant Center Feed (eingereicht, validiert über Merchant-Center-Diagnosen). Google gleicht sie ab und kann Feed-Preise übernehmen; ein Feed ist additiv, nicht erforderlich. Preis/Verfügbarkeit müssen über Markup, Feed und Checkout übereinstimmen, sonst meldet Google eine Abweichung, selbst wenn das JSON-LD gültig ist.
• availability-Enum: InStock, OutOfStock, PreOrder, PreSale, BackOrder, OnlineOnly, InStoreOnly, LimitedAvailability, Discontinued, SoldOut. Ein einfacher String statt des Enums ist ein häufiger Fehler.
• Bewertungen: review/aggregateRating weiterhin bei Product zulässig; Bewerternamen müssen eine Person/ein Team sein, Pro-und-Kontra ist nur redaktionell. Mythos korrigiert: Das Verbot eigennütziger Bewertungen gilt nur für LocalBusiness/Organization, nicht für Product – aber die Durchsetzung echter Bewertungen (Reviews System, Product Reviews Updates) wertet manipulierte Bewertungen unabhängig von der Markup-Gültigkeit ab.
• Kennungen: gtin (stärkste Übereinstimmung) > mpn > brand > sku – „empfohlen“ in der Suche, aber tragend für Shopping/Merchant-Center-Abgleich.
• Rückgaberecht: Standardmäßig hasMerchantReturnPolicy auf Organization-Ebene; pro Offer nur für Ausnahmen.
• Berechtigung ≠ Anzeige: gültiges Markup + indexierte Seite + Google entscheidet, dass es „zeigenswert“ ist. Sauberes Markup macht Sie nur berechtigt.
• KI-Winkel (unverifiziert): Einige Praktiker glauben, dass vollständiges Product-Schema KI-Shopping-Tools hilft, Produkte zu lesen und zu empfehlen – Googles eigene Dokumentation belegt das nicht, also behandeln Sie es als offene Frage, nicht als dokumentierten Mechanismus.

Offizielle Dokumentation

Primärquellen-Dokumentation der Suchmaschinen.

Google – strukturierte Daten (die Markup-Seite)

• Einführung in Product-Strukturierte-Daten – die zwei Erfahrungen (Produkt-Snippets vs. Merchant Listings) und die Beziehung „strukturierte Daten, Feed oder beides“.
• Produkt-Snippet (Review, AggregateRating, Offer) strukturierte Daten – erforderliche/empfohlene Eigenschaften für die leichtere Produkt-Snippet-Erfahrung.
• Merchant-Listing-Strukturierte-Daten – strengere Anforderungen, die Preis-größer-null-Regel, Rückgaberecht- und Bildhinweise.
• Review-Snippet (Review, AggregateRating) strukturierte Daten – der Geltungsbereich eigennütziger Bewertungen (LocalBusiness/Organization) und die „nicht aggregieren“-Regel.
• Rich Results Test – validieren Sie das Markup und prüfen Sie die Rich-Results-Berechtigung.

Google – die Feed-Seite (Merchant Center)

• Produktdatenspezifikation – erforderliche Feed-Attribute und die Anforderung an die Konsistenz von Preis/Währung über Landingpage, strukturierte Daten und Checkout hinweg.
• Strukturierte Daten für Merchant Center einrichten – wie strukturierte Daten und der Feed auf der Merchant-Center-Seite zusammenhängen.

Bing / Microsoft

• Ihre Website mit strukturierten Daten auszeichnen – Bings allgemeine Unterstützung für strukturierte Daten (schema.org, JSON-LD empfohlen).

Zitate aus der Quelle

Öffentliche Aussagen von Google. Wenn eine Quellseite den Text anzeigt, ist der Link ein Deep-Link, der direkt zum zitierten Abschnitt springt.

Google-Dokumente – die beiden Erfahrungen

• “Two markup types exist: Product snippets for non-purchase pages, emphasizing reviews, and Merchant listings for purchase pages, highlighting product details like sizing and shipping.” (Übersetzung) „Es gibt zwei Arten von Auszeichnungen: Produkt-Snippets für Nicht-Kaufseiten, die Bewertungen hervorheben, und Merchant-Listings für Kaufseiten, die Produktdetails wie Größe und Versand hervorheben.“ Zum Zitat springen
• “Currently, product rich results only support pages that focus on a single product (or multiple variants of the same product).” (Übersetzung) „Derzeit unterstützen Produkt-Rich-Results nur Seiten, die sich auf ein einzelnes Produkt (oder mehrere Varianten desselben Produkts) konzentrieren.“ Zum Zitat springen

Google-Dokumente – strukturierte Daten vs. Merchant Center-Feed

• “To provide rich product data to Google Search you can add Product structured data to your web pages, upload data feeds with Google Merchant Center and opt into free listings within the Merchant Center console, or both.” (Übersetzung) „Um der Google-Suche umfangreiche Produktdaten bereitzustellen, können Sie Product-Strukturdaten auf Ihren Webseiten ergänzen, Datenfeeds über Google Merchant Center hochladen und dort kostenlose Einträge aktivieren oder beide Wege kombinieren.“ Zum Zitat springen
• “Providing both structured data on web pages and a Merchant Center feed maximizes your eligibility to experiences and helps Google correctly understand and verify your data… product snippets may use pricing data from your merchant feed if it’s not present in the structured data on the page.” (Übersetzung) „Die Bereitstellung sowohl strukturierter Daten auf Webseiten als auch eines Merchant Center-Feeds maximiert Ihre Berechtigung für Erfahrungen und hilft Google, Ihre Daten korrekt zu verstehen und zu verifizieren … Produkt-Snippets können Preisdaten aus Ihrem Merchant-Feed verwenden, wenn diese nicht in den strukturierten Daten auf der Seite vorhanden sind.“ Zum Zitat springen

Google-Dokumente – Regeln für Merchant-Listings

• “Unlike product snippets, merchant listing experiences require a price greater than zero.” (Übersetzung) „Im Gegensatz zu Produkt-Snippets erfordern Merchant-Listing-Erfahrungen einen Preis größer als null.“ Zum Zitat springen
• “We recommend you provide a global return policy for your business under Organization markup instead… Only if some of your products have specific return policies… use this property under Offer.” (Übersetzung) „Wir empfehlen, stattdessen eine globale Rückgaberichtlinie für Ihr Unternehmen unter der Organization-Auszeichnung bereitzustellen … Nur wenn einige Ihrer Produkte spezifische Rückgaberichtlinien haben … verwenden Sie diese Eigenschaft unter Offer.“ Zum Zitat springen
• “For best results, we recommend providing multiple high-resolution images (minimum of 50K pixels when multiplying width and height) with the following aspect ratios: 16x9, 4x3, and 1x1.” (Übersetzung) „Für beste Ergebnisse empfehlen wir, mehrere hochauflösende Bilder (mindestens 50.000 Pixel bei Multiplikation von Breite und Höhe) mit den folgenden Seitenverhältnissen bereitzustellen: 16x9, 4x3 und 1x1.“ Zum Zitat springen

Google-Dokumente – Bewertungen

• Zu Rezensentennamen: “Not recommended: ‘50% off on Black Friday’. Recommended: ‘James Smith’ or ‘CNET Reviewers’.” (Übersetzung) „Nicht empfohlen: ‚50 % Rabatt am Black Friday’. Empfohlen: ‚James Smith’ oder ‚CNET Reviewers’.” Zum Zitat springen
• Zu Vor- und Nachteilen: “Only editorial product review pages are eligible for the pros and cons appearance in Search results.” (Übersetzung) „Nur redaktionelle Produktbewertungsseiten sind für die Darstellung von Vor- und Nachteilen in den Suchergebnissen berechtigt.” Zum Zitat springen
• Zu selbstbezogenen Bewertungen (beschränkt auf LocalBusiness/Organization): “If the entity that’s being reviewed controls the reviews about itself, their pages that use LocalBusiness or any other type of Organization structured data are ineligible for star review feature.” (Übersetzung) „Wenn die bewertete Entität die Bewertungen über sich selbst kontrolliert, sind ihre Seiten, die LocalBusiness oder eine andere Art von Organization-Structured-Data verwenden, für die Sternbewertungsfunktion nicht berechtigt.” Review-Snippet-Dokumentation
• “Don’t aggregate reviews or ratings from other websites.” (Übersetzung) „Fassen Sie keine Bewertungen oder Bewertungen von anderen Websites zusammen.” Review-Snippet-Dokumentation

Google – Merchant Center-Konsistenz

• Händler müssen “accurately submit the product’s price and currency, and match with the price from your landing page, structured data, and at checkout.” (Übersetzung) „den Preis und die Währung des Produkts genau übermitteln und mit dem Preis auf Ihrer Landingpage, in den strukturierten Daten und beim Checkout abgleichen.” Produktdatenspezifikation

John Mueller, Google (laut Search Engine Journal)

• “It requires that the page be indexed, that the page has valid structured data on it, and that our systems have determined that it’s worth showing this structured data.” (Übersetzung) „Es erfordert, dass die Seite indexiert ist, dass die Seite gültige strukturierte Daten enthält und dass unsere Systeme festgestellt haben, dass es sich lohnt, diese strukturierten Daten anzuzeigen.” SEJ-Berichterstattung
• “There’s also the possibility to submit a feed to your merchant center account, to show products there.” (Übersetzung) „Es besteht auch die Möglichkeit, einen Feed an Ihr Merchant Center-Konto zu übermitteln, um dort Produkte anzuzeigen.” SEJ-Berichterstattung

Produkt-Schema-Spickzettel

Das Minimum für ein Produkt-Snippet

Product.name + mindestens eines von offers / review / aggregateRating. Ein Merchant Listing benötigt immer offers – diese Flexibilität gilt dort nicht. Nur für Einzelproduktseiten (verwenden Sie ProductGroup für eine Variantenlinie).

Snippet vs. Merchant Listing – wo sie sich unterscheiden

availability-Enum-Werte

InStock · OutOfStock · PreOrder · PreSale · BackOrder · OnlineOnly · InStoreOnly · LimitedAvailability · Discontinued · SoldOut

Markup vs. Merchant Center-Feed

Kennungen, nach Übereinstimmungsstärke: gtin > mpn > brand > sku.

Schnelle Fakten

• Format: JSON-LD (empfohlen, am wartbarsten in großem Maßstab).
• Gültiges Markup = berechtigt, nicht garantiert angezeigt zu werden.
• Rückgaberecht: Standard auf Organization-Ebene; nur für Ausnahmen pro Offer.
• Verbot selbstbezogener Bewertungen = nur LocalBusiness/Organization, nicht Product.
• Bilder: mehrere, mindestens 50K px (B×H), Seitenverhältnisse 16x9 / 4x3 / 1x1.

Brauche ich Produkt-Schema, einen Merchant Center-Feed oder beides?

Gehen Sie die Fragen durch:

1. Ist die Seite ein einzelnes Produkt (oder die Varianten eines Produkts)?

• Nein – es ist eine Kategorie-/Sammlungsseite → Product-Schema ist nicht zulässig. Erwägen Sie ProductGroup für eine Variantenlinie oder Breadcrumb-/Sammlungs-Markup stattdessen.
• Ja → weiter.

2. Kann das Produkt direkt auf dieser Seite gekauft werden?

• Nein (es ist eine informative oder redaktionelle Produktseite) → zielen Sie auf ein Produkt- Snippet: name + offers und/oder review/aggregateRating. priceCurrency empfohlen; price: 0 ist für kostenlose Artikel zulässig.
• Ja → zielen Sie auf einen Händler-Eintrag: fügen Sie image, offers mit price > 0 und priceCurrency (erforderlich) hinzu, plus availability, itemCondition und idealerweise shippingDetails.

3. Möchten Sie Ihre Produkte in Google Shopping / kostenlosen Listings und die Eignung maximieren?

• Fügen Sie einen Google Merchant Center Feed zusätzlich zum On-Page-Markup hinzu. Es ist ein separates System, aber Google kombiniert beide und erweitert Ihre Eignung. Nicht erforderlich, um einen On-Page-Händler-Eintrag zu erhalten – es ist additiv.
• Behalten Sie nur das Markup bei, wenn Sie nur das On-Page-Rich-Result möchten und die Shopping-Oberflächen nicht benötigen.

4. Welcher Weg auch immer – bevor Sie veröffentlichen:

• Validieren Sie das Markup mit dem Rich Results Test und beobachten Sie Search Console.
• Wenn Sie einen Feed haben, validieren Sie ihn separat in Merchant Center.
• Bestätigen Sie, dass price, priceCurrency und availability übereinstimmen über Markup, Feed und Checkout. Dies ist der Schritt, der Listings nach der Validierung live hält.

Faustregel: On-Page-Product-Schema ist die Grundlage für jeden, der ein Produkt verkauft; der Merchant Center Feed ist die zusätzliche Ebene für alle, welche die Shopping-/kostenlosen-Listings-Oberflächen oder maximale Eignung möchten.

Product-Schema-Mythen und Fehler, die Sie vermeiden sollten

Mythos: „Das Hinzufügen von Product-Schema garantiert ein Rich Result.“ Es macht die Seite nur berechtigt. Laut Mueller muss die Seite auch indexiert sein und Googles Systeme müssen entscheiden, dass das Ergebnis „es wert ist, gezeigt zu werden“. Gültig ≠ angezeigt.

Mythos: „Product-Schema und mein Merchant Center Feed sind dieselbe Einreichung.“ Es sind zwei Systeme mit zwei Validatoren. Google gleicht sie ab (und kann Feed-Preise für ein Snippet ausleihen), aber das Beheben Ihres JSON-LD tut nichts für einen defekten Feed, und ein bestehender Rich Results Test sagt nichts über die Gültigkeit des Feeds aus.

Mythos: „Google hat Bewertungssterne auf Produktseiten abgeschafft, wie bei Unternehmensbewertungen.“ Die Nichtberechtigung für eigennützige Bewertungen ist auf LocalBusiness / Organization beschränkt (eine Unternehmensbewertung selbst, gemäß der Richtlinie vom September 2019) – nicht auf Product. Product review/aggregateRating sind weiterhin berechtigt. Was sich verschärft, ist die Durchsetzung echter Bewertungen (Reviews System, Product Reviews Updates), die manipulierte oder incentivierte Bewertungen abwertet, selbst wenn das Markup validiert. Verwechseln Sie eine Inhaltsqualitäts-Kampagne nicht mit einem Verbot strukturierter Daten.

Mythos: „priceCurrency ist immer erforderlich.“ Es ist erforderlich für Händler-Einträge, aber nur „derzeit von Google empfohlen“ für grundlegende Produkt-Snippets.

Mythos: „Sie benötigen Merchant Center, um Shopping-ähnliche Ergebnisse zu erhalten.“ On-Page-strukturierte Daten allein können ein Händler-Eintrags-Rich-Result erzeugen. Der Feed ist ein additiver Weg, keine Voraussetzung.

Mythos: „Jedes Preisformat funktioniert, solange es eine Zahl gibt.“ Währungssymbole, Tausendertrennzeichen oder ein falsch verschachteltes priceSpecification brechen regelmäßig die Validierung. Halten Sie price als nackte Zahl/Zeichenkette und priceCurrency als separaten ISO-Code.

Fehler: Eine Kategorieseite als Product auszeichnen. Product-Rich-Results decken nur Einzelprodukt- (oder Einzelproduktvarianten-) Seiten ab.

Fehler: Bewertungen erfinden oder importieren. Bewerternamen müssen eine Person/ein Team sein (nicht „50 % Rabatt“), Vor- und Nachteile sind nur redaktionell, und Sie dürfen „Bewertungen oder Bewertungen von anderen Websites aggregieren“ nicht.

Fehler: Markup, das nicht zur Seite passt. Wenn der Preis/die Verfügbarkeit in Ihrem JSON-LD nicht mit der Landingpage, dem Feed oder dem Checkout übereinstimmt, kann Google eine Abweichung kennzeichnen oder den Artikel sperren – selbst bei gültigem Markup.

Sauberes vs. defektes Product-JSON-LD

Ein sauberes, für Händlerlisten geeignetes Snippet

Einzelnes Produkt, Preis größer als null, korrekte Währung, eine ordnungsgemäße availability-Enum-URL und eine echte aggregierte Bewertung:

{
  "@context": "https://schema.org/",
  "@type": "Product",
  "name": "Trailhead 30L Hiking Backpack",
  "image": [
    "https://example.com/img/backpack-1x1.jpg",
    "https://example.com/img/backpack-4x3.jpg",
    "https://example.com/img/backpack-16x9.jpg"
  ],
  "description": "Lightweight 30-liter pack with a ventilated back panel.",
  "sku": "TH-30L-GRN",
  "gtin": "0192341567890",
  "brand": { "@type": "Brand", "name": "Trailhead" },
  "offers": {
    "@type": "Offer",
    "url": "https://example.com/backpacks/trailhead-30l",
    "price": "129.00",
    "priceCurrency": "USD",
    "availability": "https://schema.org/InStock",
    "itemCondition": "https://schema.org/NewCondition",
    "priceValidUntil": "2026-12-31"
  },
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.6",
    "reviewCount": "218"
  }
}

Dasselbe Snippet, defekt

Jede unten markierte Zeile ist ein realer, häufiger Search-Console-Fehler:

{
  "@context": "https://schema.org/",
  "@type": "Product",
  "name": "Trailhead 30L Hiking Backpack",
  "offers": {
    "@type": "Offer",
    "price": "$1,129.00",
    "priceCurrency": "dollars",
    "availability": "in stock"
  },
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.6"
  }
}

Was ist falsch:

• price: "$1,129.00" — ein Währungssymbol und ein Tausendertrennzeichen brechen die numerische Analyse. Verwenden Sie "1129.00".
• priceCurrency: "dollars" — muss ein gültiger ISO-4217-Code sein: "USD".
• availability: "in stock" — keine gültige Enum; verwenden Sie die URL-Form "https://schema.org/InStock". Dies erzeugt den klassischen Fehler Invalid enum value in field “availability”.
• Kein image — erforderlich für eine Händlerliste (es würde bestenfalls auf ein Produkt-Snippet zurückfallen).
• aggregateRating ohne reviewCount/ratingCount — eine aggregierte Bewertung benötigt eine Anzahl, um gültig zu sein.

Häufige Search-Console-Fehler → Korrekturen

Testen Sie sich selbst: Product-Schema

Fünf kurze Fragen zu schema.org/Product, den beiden Rich-Result-Erlebnissen und der Unterscheidung zwischen Feed und Markup. Wählen Sie für jede eine Antwort und prüfen Sie dann.

Ressourcen, die Ihre Zeit wert sind

Meine Beiträge zu diesem Thema

Ich habe keinen eigenständigen Leitfaden zum Product-Schema veröffentlicht — also anstatt Sie auf etwas zu verweisen, das es nicht gibt, ist der ehrliche Schritt, Sie auf die Primärquellen unten und auf die verwandten strukturierten-Daten-Arbeiten auf dieser Website zu verweisen. Für das breitere Vokabular und wo Product einzuordnen ist, siehe die Schema-Markup- und Strukturierte-Daten- Hubs; für den KI-Winkel, Schema-Markup für KI.

Aus der Branche

• Einführung in Product-Strukturierte-Daten (Google Search Central) — die maßgebliche Referenz für die beiden Erlebnisse und die Feed-Beziehung.
• Strukturierte Daten für Händlerlisten (Google) — die strengeren transaktionalen Anforderungen, Rückgaberichtlinien- und Bildhinweise.
• Strukturierte Daten für Produkt-Snippets (Google) — der leichtere Eigenschaftssatz für Produkt-Snippets und die Regeln für Rezensentennamen.
• Produktdatenspezifikation (Google Merchant Center Hilfe) — die Feed-seitigen Attribute und die Preis-Konsistenz-Anforderung über Landingpage, strukturierte Daten und Checkout hinweg.
• Google sagt, wie man mehr Produkt-Rich-Results erhält (Search Engine Journal) — die Mueller-Zitate zu Eignung vs. Anzeige und die Feed-Option.
• Was ist Schema-Markup? Wie fügt man es hinzu und warum es wichtig ist (Ahrefs) — ein allgemeiner Schema-Leitfaden mit einem nützlichen KI-Agenten-/Produktentdeckungs-Winkel.

Änderungsprotokoll