Strukturierte Daten für WooCommerce-Produkte — Product-, Offer- und Review-Schema

Ein Produkt in einem Shop hat einen Namen, Fotos, einen Preis, Verfügbarkeit, eine Marke, Varianten und Bewertungen. Der Kunde sieht diese Informationen auf der Produktseite. Google muss jedoch selbst herausfinden, welcher Teil der Seite der Preis ist, welcher der Lagerbestand und welcher die Kundenbewertung.

Strukturierte Produktdaten beschreiben diese Elemente in einem geordneten Format. Dadurch kann die Suchmaschine das Angebot besser verstehen und die Seite für erweiterte Ergebnisse qualifizieren, die unter anderem Preis, Verfügbarkeit und Bewertung des Produkts enthalten.

Das Problem beginnt, wenn der Code einen anderen Preis anzeigt als die Produktseite, eine nicht verfügbare Variante als verfügbar markiert ist oder mehrere Plugins drei verschiedene Product-Objekte erzeugen. Technisch mag die Seite weiterhin funktionieren, aber Google und das Merchant Center erhalten widersprüchliche Informationen.

Dieser Artikel ist für den technischen Teil der Produktdaten zuständig: Product, Offer, Varianten, Identifikatoren, Bewertungen und Konflikte zwischen Plugins. Den Prozess des Sammelns und Moderierens von Rezensionen beschreiben wir gesondert im Leitfaden zu Bewertungen und Rezensionen von Produkten in WooCommerce. Wenn Sie gerade erst die gesamte Sichtbarkeit Ihres Shops ordnen, beginnen Sie mit dem Leitfaden WooCommerce-Shop-SEO — womit anfangen. Eine umfassendere Diagnose von Technik, Inhalt und Struktur finden Sie hingegen im Artikel SEO-Audit eines Onlineshops — was es umfasst und wann es sinnvoll ist.

Kurz gesagt

Korrekte strukturierte Produktdaten in WooCommerce sollten:

1. genau das Produkt beschreiben, das der Nutzer auf der Seite sieht.
2. den aktuellen Namen, das Bild und die Produkt-URL enthalten.
3. den tatsächlichen Preis sowie die richtige Währung übermitteln.
4. die aktuelle Verfügbarkeit anzeigen.
5. Marke, SKU und GTIN angeben, sofern solche Identifikatoren existieren.
6. ein einfaches Produkt von Varianten unterscheiden.
7. Varianten mithilfe von ProductGroup verbinden, wenn die Konstruktion des Shops dies erfordert.
8. Bewertungen und die Durchschnittsnote nur dann übermitteln, wenn sie auf der Seite sichtbar sind.
9. mit den Daten im Google-Merchant-Center-Feed übereinstimmen.
10. von einem einzigen, konsistenten System generiert werden und nicht von mehreren konkurrierenden Plugins.
11. sich nach einer Änderung von Preis, Aktion, Variante oder Lagerbestand aktualisieren.
12. den Test auf Rich-Suchergebnisse ohne kritische Fehler bestehen.

Strukturierte Daten erhöhen die Möglichkeit, ein erweitertes Ergebnis anzuzeigen, garantieren aber nicht, dass Google bei jeder Suchanfrage Preis, Sterne oder Verfügbarkeit anzeigt.

Kurz zusammengefasst (TL;DR)

• Product beschreibt das Produkt, während Offer ein konkretes Verkaufsangebot darstellt.
• AggregateOffer zeigt die Preisspanne mehrerer Angebote, beschreibt aber nicht immer gut die direkt im Shop gekaufte Variante.
• Review beschreibt eine einzelne Bewertung, während AggregateRating die Durchschnittsnote eines Produkts beschreibt.
• ProductGroup hilft, Varianten zu verbinden, die sich in Farbe, Größe, Material oder einem anderen Merkmal unterscheiden.
• Preis, Währung und Verfügbarkeit müssen auf der Seite, im Schema, beim Kauf sowie im Merchant Center übereinstimmen.
• Erfinden Sie keine GTIN-Codes. Fügen Sie sie nur hinzu, wenn sie dem Produkt tatsächlich zugewiesen wurden.
• WooCommerce generiert grundlegende Daten automatisch, aber Theme und Plugins können Duplikate erzeugen.
• Korrekter Code gibt Ihnen die Möglichkeit eines erweiterten Ergebnisses, keine Garantie, dass es angezeigt wird.
• Korrigieren Sie zuerst die Produktdaten in WooCommerce und erst danach den Schema-Code selbst.

Was sind strukturierte Produktdaten?

Strukturierte Daten sind Informationen, die im Seitencode in einem für die Suchmaschine verständlichen Format gespeichert sind. Der Kunde sieht auf der Seite: „Höhenverstellbarer Schreibtisch Varius — 999 € — Verfügbar — Farbe: Natureiche — Bewertung: 4,7 auf Basis von 38 Rezensionen". Im Code lassen sich dieselben Informationen in geordneter Form übermitteln:

{
  "@type": "Product",
  "name": "Höhenverstellbarer Schreibtisch Varius",
  "offers": {
    "@type": "Offer",
    "price": 999,
    "priceCurrency": "EUR",
    "availability": "https://schema.org/InStock"
  }
}

Schema ist keine separate, ausschließlich für Google bestimmte Beschreibung — sie sollte widerspiegeln, was tatsächlich auf der Seite steht. Wenn der Kunde einen Preis von 999 € sieht und der Code 899 € anzeigt, sind die Daten inkonsistent.

Was sind Schema.org, JSON-LD und ein Rich Result?

Diese Begriffe werden oft zusammen verwendet, bedeuten aber unterschiedliche Dinge.

Begriff	Was bedeutet das in einfachen Worten?
Schema.org	Ein Vokabular von Typen und Eigenschaften zur Beschreibung von Inhalten
Strukturierte Daten	Informationen, die nach einem festgelegten Schema gespeichert sind
JSON-LD	Ein Format zum Speichern strukturierter Daten im Seitencode
Product	Ein Typ, der ein Produkt beschreibt
Offer	Ein Typ, der ein Verkaufsangebot beschreibt
Rich Result	Ein erweitertes Ergebnis in Google, z. B. mit Preis oder Bewertung
Merchant Listing	Ein Produktergebnis, das mit einem kaufbaren Angebot verbunden ist
Product Snippet	Ein Textergebnis mit zusätzlichen Daten zum Produkt

Google unterstützt mehrere Formate strukturierter Daten, in der Praxis wird jedoch am häufigsten JSON-LD verwendet. Der Beispielcode befindet sich in der Regel in einem Abschnitt <script type="application/ld+json">…</script> — er ist nicht als gewöhnlicher Text auf der Seite sichtbar, aber die darin beschriebenen Informationen sollten für den Kunden sichtbar sein.

Was können strukturierte Daten in den Google-Ergebnissen verändern?

Korrekte Produktdaten können die Möglichkeit erhöhen, unter anderem Preis, Währung, Verfügbarkeit, Bewertung, Anzahl der Rezensionen, Produktzustand, Informationen zu Versand und Rückgabe, Varianten sowie Produktfotos anzuzeigen.

Ein Produkt kann an verschiedenen Stellen und in verschiedenen Formen erscheinen: in einem gewöhnlichen Textergebnis, in Produktergebnissen, in Google Images, in Google Lens, in Produktpanels oder in kostenlosen Produktinformationen. Das bedeutet nicht, dass die Implementierung des Schemas automatisch alle diese Elemente hinzufügt. Google entscheidet selbst, ob ein erweitertes Ergebnis angezeigt wird, welche Elemente angezeigt werden, für welche Suchanfrage, auf welchem Gerät und an welchem Standort. Strukturierte Daten erhöhen die Lesbarkeit der Informationen für die Suchmaschine — sie sind kein Befehl, der ein bestimmtes Aussehen des Ergebnisses erzwingt.

Product Snippet vs. Merchant Listing — was ist der Unterschied?

Google unterscheidet zwei Hauptanwendungen von Produktdaten.

Product Snippet ist meist ein gewöhnliches Textergebnis, das mit Produktinformationen angereichert ist — es kann Preis, Verfügbarkeit, Bewertung und Anzahl der Rezensionen enthalten. Dieser Typ kann auch auf Seiten verwendet werden, auf denen ein Produkt beschrieben, aber nicht unbedingt direkt verkauft wird: eine Produktrezension auf einem Portal, ein Vergleich von Modellen oder eine Herstellerseite ohne Kaufmöglichkeit.

Merchant Listing betrifft eine Seite, auf der der Kunde das Produkt kaufen kann — in einem WooCommerce-Shop ist das in der Regel das richtige Modell. Über die grundlegenden Produktdaten hinaus kann es ein konkretes Verkaufsangebot, Preis, Verfügbarkeit, Versand, Rückgabe, Produktzustand, Varianten sowie Mitglieds- oder Aktionspreise umfassen. Wenn Sie einen Shop betreiben, beschränken Sie sich nicht nur auf Bewertungen und eine allgemeine Preisspanne — das Produkt sollte ein echtes Offer haben, das den auf der Seite sichtbaren Kaufbedingungen entspricht.

Die wichtigsten Schema-Typen für ein Produkt

Typ	Was beschreibt er?	Beispiel
Product	Das Produkt selbst	Schreibtisch Varius
Offer	Ein konkretes Angebot des Verkäufers	Preis 999 €, Produkt verfügbar
AggregateOffer	Eine gesammelte Spanne mehrerer Angebote	Preis von 999 bis 1.499 €
ProductGroup	Eine Familie von Varianten	Schreibtisch in mehreren Farben und Größen
Review	Eine einzelne Rezension	Bewertung eines bestimmten Kunden
Rating	Die Bewertung in einer konkreten Rezension	5 von 5
AggregateRating	Die Durchschnittsnote des Produkts	4,7 auf Basis von 38 Bewertungen
Brand	Die Marke des Produkts	Marke X
Organization	Den Verkäufer oder das Unternehmen	Name des Shops
OfferShippingDetails	Die Versandbedingungen des Angebots	Kosten und Lieferzeit
MerchantReturnPolicy	Die Rückgaberegeln	Rückgabe innerhalb einer bestimmten Frist

Nicht jedes Produkt benötigt alle Elemente. Der Code sollte dem tatsächlichen Verkaufsmodell entsprechen.

Product — was beschreibt das Produkt?

Das Product-Objekt identifiziert das auf der Seite befindliche Produkt. Es enthält meist Name, Fotos, Beschreibung, URL, Marke, SKU, GTIN, MPN, Farbe, Material, Größe, Angebot, Bewertungen und Durchschnittsnote. Eine beispielhafte Grundlage:

{
  "@context": "https://schema.org/",
  "@type": "Product",
  "name": "Höhenverstellbarer Schreibtisch Varius 120 × 65 cm",
  "description": "Schreibtisch mit elektrischer Höhenverstellung und Eichenplatte.",
  "image": [
    "https://shop.de/wp-content/uploads/schreibtisch-varius-1.webp",
    "https://shop.de/wp-content/uploads/schreibtisch-varius-2.webp"
  ],
  "sku": "VARIUS-120-OAK",
  "brand": {
    "@type": "Brand",
    "name": "Beispielmarke"
  }
}

Das Product allein beschreibt noch nicht die Kaufbedingungen. Dafür ist Offer zuständig.

Welche Produktinformationen sollte man übermitteln?

name sollte dem auf der Seite sichtbaren Produktnamen entsprechen. Fügen Sie ins Schema keinen anderen, künstlich erweiterten Namen ein, nur um mehr Phrasen hinzuzufügen — wenn auf der Seite „Schreibtisch Varius 120 cm" steht, sollte im Code nicht plötzlich „Bester günstiger elektrischer höhenverstellbarer Schreibtisch fürs Büro Aktion" erscheinen.

description sollte dem tatsächlichen Produkt entsprechen. Sie muss nicht die vollständige Seitenbeschreibung enthalten — sie kann eine kürzere, konkrete Zusammenfassung sein: was das Produkt ist, welche Haupteigenschaften es hat und wofür es dient.

image — die Adressen sollten zu Fotos führen, die für Google verfügbar sind, dieses Produkt zeigen, von angemessener Qualität sind, nicht in der robots.txt blockiert sind und keine Anmeldung erfordern. Verwenden Sie kein Kategorienfoto oder Shop-Logo als Hauptproduktfoto.

url sollte auf die richtige Adresse der Produktseite verweisen. Wenn das Produkt mehrere Varianten unter verschiedenen URLs hat, muss jede Adresse korrekt mit einer bestimmten Variante verknüpft sein.

brand sollte dem tatsächlichen Hersteller oder der Marke des Produkts entsprechen. Tragen Sie nicht automatisch den Shop-Namen als Marke jedes Produkts ein, wenn Sie Waren anderer Hersteller verkaufen.

sku ist der interne Lageridentifikator des Produkts (z. B. VARIUS-120-OAK-BLACK). In einem Shop mit Varianten kann jede Variante ihre eigene SKU haben.

gtin ist der globale Handelsidentifikator. Je nach Länge kann er als gtin8, gtin12, gtin13 oder gtin14 auftreten. Häufig anzutreffen ist der EAN-13-Code, der als gtin13 übermittelt wird. Erfinden Sie keinen GTIN-Code, wenn das Produkt keinen hat — ein falscher Identifikator ist schlimmer als kein Identifikator, weil er das Produkt mit der falschen Ware verknüpfen kann.

mpn ist die vom Hersteller vergebene Teilenummer. Sie kann nützlich sein, wenn das Produkt keinen GTIN hat, der Hersteller eine eigene Modellbezeichnung verwendet oder dasselbe Produkt in mehreren Shops verkauft wird. Die MPN sollte nicht automatisch durch die SKU des Shops ersetzt werden, wenn es sich um zwei verschiedene Identifikatoren handelt.

Offer — Preis, Währung und Verfügbarkeit

Offer beschreibt ein konkretes Verkaufsangebot für das Produkt. Die wichtigsten Informationen sind Preis, Währung, Verfügbarkeit, Adresse des Angebots, Produktzustand, Verkäufer, Versand und Rückgabe. Beispiel:

{
  "@type": "Offer",
  "url": "https://shop.de/schreibtisch-varius-120/",
  "price": 999,
  "priceCurrency": "EUR",
  "availability": "https://schema.org/InStock",
  "itemCondition": "https://schema.org/NewCondition"
}

price sollte der aktuelle Preis sein, zu dem der Kunde das Produkt kaufen kann. Tragen Sie nicht den Preis vor dem Rabatt als aktuellen Preis ein, nicht den Nettopreis, wenn der Kunde brutto sieht, nicht den Preis der günstigsten Variante, wenn eine teurere Variante geöffnet ist, keinen Betrag ohne obligatorische Aufschläge und keinen Preis, der nur nach Anmeldung sichtbar ist, wenn der Code ein öffentliches Angebot suggeriert.

priceCurrency sollte als dreistelliger Code geschrieben werden (EUR, GBP, USD, PLN, CZK). Verwenden Sie nicht die Schreibweise €, DE oder „Euro".

availability sollte der realen Kaufmöglichkeit entsprechen.

Wert	Bedeutung
InStock	Produkt verfügbar
OutOfStock	Produkt nicht verfügbar
BackOrder	Produkt auf Bestellung verfügbar
PreOrder	Bestellung vor der Veröffentlichung möglich
LimitedAvailability	Eingeschränkte Verfügbarkeit
Discontinued	Produkt ausgelaufen
SoldOut	Produkt ausverkauft

Markieren Sie ein Produkt nicht als InStock, wenn es nicht in den Warenkorb gelegt werden kann, keine Variante verfügbar ist, der Verkauf beendet wurde oder das Produkt ausschließlich eine Katalogfunktion erfüllt.

itemCondition — die am häufigsten anzutreffenden Werte sind NewCondition, UsedCondition und RefurbishedCondition. Wenn der Shop ausschließlich neue Produkte verkauft, kann der Parameter automatisch generiert werden; bei gebrauchten oder generalüberholten Produkten muss der Zustand mit der Beschreibung auf der Seite übereinstimmen.

Beispiel für ein vollständiges Schema eines einfachen Produkts

Das folgende Beispiel ist veranschaulichend. Es sollte an die Daten eines bestimmten Produkts und die Funktionsweise des Shops angepasst werden.

<script type="application/ld+json">
{
  "@context": "https://schema.org/",
  "@type": "Product",
  "@id": "https://shop.de/schreibtisch-varius-120/#product",
  "name": "Höhenverstellbarer Schreibtisch Varius 120 × 65 cm",
  "url": "https://shop.de/schreibtisch-varius-120/",
  "description": "Schreibtisch mit elektrischer Höhenverstellung, Eichenplatte und Speicher für drei Positionen.",
  "image": [
    "https://shop.de/wp-content/uploads/schreibtisch-varius-120-front.webp",
    "https://shop.de/wp-content/uploads/schreibtisch-varius-120-detail.webp"
  ],
  "sku": "VARIUS-120-OAK-BLACK",
  "gtin13": "5901234567890",
  "brand": {
    "@type": "Brand",
    "name": "Beispielmarke"
  },
  "offers": {
    "@type": "Offer",
    "url": "https://shop.de/schreibtisch-varius-120/",
    "price": 999,
    "priceCurrency": "EUR",
    "availability": "https://schema.org/InStock",
    "itemCondition": "https://schema.org/NewCondition",
    "seller": {
      "@type": "Organization",
      "name": "Beispielshop"
    }
  },
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": 4.7,
    "ratingCount": 38
  }
}
</script>

Wichtig: Kopieren Sie nicht den Beispiel-GTIN, tragen Sie nicht die Beispielbewertung ein, codieren Sie den Preis nicht fest, deklarieren Sie die Verfügbarkeit nicht unabhängig vom Lager und fügen Sie keine Bewertungen hinzu, die nicht auf der Seite stehen. Die Daten sollten dynamisch auf Basis von WooCommerce generiert werden.

Offer oder AggregateOffer?

Das ist ein häufiges Problem in Shops mit Varianten.

Offer beschreibt ein konkretes Angebot („schwarzer Stuhl, Standardgröße, Preis 399 €, verfügbar"). Für eine Shop-Seite, auf der der Kunde ein bestimmtes Produkt kaufen kann, ist Offer in der Regel am präzisesten.

AggregateOffer beschreibt eine Spanne mehrerer Angebote:

{
  "@type": "AggregateOffer",
  "lowPrice": 999,
  "highPrice": 1499,
  "priceCurrency": "EUR",
  "offerCount": 8
}

Es kann sinnvoll sein, wenn die Seite mehrere Angebote verschiedener Verkäufer, mehrere Preise eines Produkts oder eine Preisspanne der Varianten anzeigt.

Warum kann allein die Preisspanne ein Problem sein? Nehmen wir an, der Schreibtisch hat Varianten:

Variante	Preis
120 cm, schwarzes Gestell	999 €
140 cm, schwarzes Gestell	1.299 €
160 cm, weißes Gestell	1.499 €

WooCommerce kann zu Beginn „999–1.499 €" anzeigen, aber der Merchant-Center-Feed überträgt jede Variante einzeln. Wenn eine Anzeige zur Variante für 1.499 € führt und der Seitencode nur eine Spanne ab 999 € anzeigt, kann Google Schwierigkeiten haben, den Preis der konkreten Variante zu bestätigen. In einem solchen Fall muss man prüfen, ob die URL die richtige Variante öffnet, ob die Variante sofort ausgewählt ist, ob der sichtbare Preis dem Feed entspricht, ob das Schema die konkrete Version beschreibt und ob jede Variante einen eigenen Identifikator hat. Man sollte AggregateOffer nicht automatisch in Offer ändern, ohne die Konstruktion der Produktseite zu analysieren.

Variantenprodukte und ProductGroup

Ein Variantenprodukt ist ein Produkt, das in mehreren Versionen verfügbar ist — Farben, Größen, Materialien, Kapazitäten, Mustern oder Konfigurationen. Jede Kombination kann einen anderen Preis, eine eigene SKU, einen separaten GTIN, eine andere Verfügbarkeit, ein eigenes Foto und eine andere Lieferzeit haben. Wenn das Schema nur das übergeordnete Produkt und die Preisspanne beschreibt, erhält Google möglicherweise nicht die vollständigen Daten der konkreten Varianten.

Wofür dient ProductGroup? Es verbindet Produkte, die Versionen derselben Familie sind. Die wichtigsten Eigenschaften: productGroupID (der Identifikator der Gruppe oder des übergeordneten Produkts), variesBy (die unterscheidenden Merkmale der Varianten), hasVariant (die zur Gruppe gehörenden Varianten) und isVariantOf (der Verweis einer Variante auf die Gruppe). Ein vereinfachtes Beispiel:

{
  "@context": "https://schema.org/",
  "@type": "ProductGroup",
  "name": "Höhenverstellbarer Schreibtisch Varius",
  "productGroupID": "VARIUS",
  "variesBy": [
    "https://schema.org/color",
    "https://schema.org/size",
    "https://schema.org/material"
  ],
  "hasVariant": [
    {
      "@type": "Product",
      "name": "Schreibtisch Varius 120 cm — Eiche, schwarzes Gestell",
      "sku": "VARIUS-120-OAK-BLACK",
      "color": "Natureiche / schwarz",
      "size": "120 × 65 cm",
      "offers": {
        "@type": "Offer",
        "price": 999,
        "priceCurrency": "EUR",
        "availability": "https://schema.org/InStock"
      }
    },
    {
      "@type": "Product",
      "name": "Schreibtisch Varius 160 cm — Eiche, weißes Gestell",
      "sku": "VARIUS-160-OAK-WHITE",
      "color": "Natureiche / weiß",
      "size": "160 × 80 cm",
      "offers": {
        "@type": "Offer",
        "price": 1499,
        "priceCurrency": "EUR",
        "availability": "https://schema.org/BackOrder"
      }
    }
  ]
}

Eine Adresse für alle Varianten. In diesem Modell wählt der Kunde die Variante auf einer einzigen Produktseite aus. Man muss prüfen, ob sich nach einem Variantenwechsel Preis, Verfügbarkeit, Foto, SKU, GTIN, URL oder Variantenparameter sowie die an den Warenkorb übergebenen Daten aktualisieren. Das Schema sollte die auf der Seite verfügbaren Varianten widerspiegeln oder die aktuell ausgewählte Version korrekt beschreiben.

Eine separate Adresse für jede Variante. In diesem Modell hat jede Variante eine eigene URL (z. B. /schreibtisch-varius-120-eiche-schwarz/, /schreibtisch-varius-160-eiche-weiss/). Jede Seite sollte eine konkrete Variante beschreiben: eigenen Preis, Verfügbarkeit, SKU, GTIN, das richtige Foto und den korrekten Canonical. Eine Variante kann über isVariantOf auf die Gruppe verweisen.

Wann erfordert die Umsetzung von Varianten Entwicklungsarbeit? Meist dann, wenn WooCommerce nur eine Preisspanne zurückgibt, jede Variante einen eigenen GTIN hat, der Feed die Varianten einzeln überträgt, die gewählte Variante die URL nicht ändert, das Schema den Preis nicht aktualisiert, das Plugin eine andere Verfügbarkeit als das Lager anzeigt, ein Teil der Varianten nicht verfügbar ist, jede Variante eine eigene SEO-Seite hat oder Google eine Preis- oder Verfügbarkeitsabweichung meldet.

Review und AggregateRating

Bewertungsdaten sind Teil der Produktauszeichnung, haben aber ihre eigenen Regeln.

Review beschreibt eine einzelne Bewertung — sie kann Autor, Inhalt, Datum und Note enthalten:

{
  "@type": "Review",
  "author": {
    "@type": "Person",
    "name": "Anna"
  },
  "datePublished": "2026-05-20",
  "reviewBody": "Der Schreibtisch ist stabil und ändert die Höhe leise.",
  "reviewRating": {
    "@type": "Rating",
    "ratingValue": 5,
    "bestRating": 5,
    "worstRating": 1
  }
}

AggregateRating beschreibt den gesammelten Durchschnitt der Bewertungen:

{
  "@type": "AggregateRating",
  "ratingValue": 4.7,
  "ratingCount": 38
}

Die wichtigste Regel: Die Bewertungen müssen für den Kunden sichtbar sein. Wenn der Code einen Durchschnitt von 4,9 und eine Anzahl von 127 Bewertungen enthält, sollte der Nutzer auf der Seite denselben Durchschnitt und dieselbe Anzahl an Bewertungen finden können. Weisen Sie nicht die Shop-Bewertung jedem Produkt zu, nicht Bewertungen aus dem Google-Unternehmensprofil einem konkreten Produkt, nicht Rezensionen einer anderen Variante ohne klare Aggregationsmethode und keine fiktive Anzahl von Rezensionen. Das vollständige Thema des Sammelns, Moderierens und Verifizierens von Rezensionen beschreiben wir im Leitfaden Bewertungen und Rezensionen von Produkten in WooCommerce — SEO, Sterne und UGC.

Strukturierte Daten und Google Merchant Center

Das Schema auf der Seite und der Produktfeed sind zwei separate Informationsquellen.

Strukturierte Daten auf der Seite liest Google beim Besuch der Produktseite — sie beschreiben unter anderem Produkt, Preis, Verfügbarkeit, Identifikatoren, Variante und Bewertungen.

Der Merchant-Center-Feed überträgt Produktdaten direkt an Google. Er kann durch eine XML-Datei, eine WooCommerce-Integration, eine API oder ein externes Produktsystem aktualisiert werden. In einem größeren Shop gibt der Feed mehr Kontrolle über Aktualisierungshäufigkeit, Varianten, Verfügbarkeit, Shopping-Kampagnen und kostenlose Produktergebnisse. Strukturierte Daten ersetzen den Feed nicht, und der Feed entbindet nicht davon, die Seite zu ordnen.

Ort	Was muss verglichen werden?
Produktseite	Der für den Kunden sichtbare Preis und die Verfügbarkeit
Strukturierte Daten	price, priceCurrency, availability
Merchant-Center-Feed	Preis, Währung, Verfügbarkeit und Variante
Warenkorb oder Checkout	Der Endpreis und die Kaufmöglichkeit

Beispiel für einen Fehler: Produktseite 199 €, Schema 179 €, Feed 199 €, Warenkorb 199 €. Google kann die Daten als inkonsistent ansehen, selbst wenn der Kunde letztlich den richtigen Betrag zahlt.

Woher kommen die Unterschiede? Die häufigsten Ursachen: Der Cache speichert einen alten Preis, eine Aktion endete nur in einem System, der Feed aktualisiert sich einmal täglich, das Schema verwendet den regulären statt des Aktionspreises, die Variante ist nicht korrekt ausgewählt, JavaScript-Code aktualisiert den Preis mit Verzögerung, die Lagerintegration hat die Verfügbarkeit nicht aktualisiert, die Preise hängen von Währung/Land/Kundengruppe ab oder ein B2B-Plugin zeigt den Nettopreis, während das Schema brutto zeigt. Wenn Sie Produktkampagnen betreiben, sehen Sie sich auch den Leitfaden Produktwerbung bei Google — Shopping und Performance Max an.

Regulärer Preis, Aktionspreis und niedrigster Preis

Ein Shop kann gleichzeitig den regulären Preis, den Aktionspreis, den niedrigsten Preis eines bestimmten Zeitraums, den Preis für angemeldete Kunden, den Großhandelspreis und den Variantenpreis anzeigen. Das Schema sollte nicht versehentlich die erste auf der Seite gefundene Zahl auswählen.

Der aktuelle Verkaufspreis. Das Feld price sollte dem Preis entsprechen, zu dem der Kunde das Produkt derzeit kaufen kann. Wenn der reguläre Preis 499 € und der Aktionspreis 399 € beträgt, ist der aktive Angebotspreis 399 €.

B2B-Preise. Wenn der Shop einen Bruttopreis für den Verbraucher, einen Nettopreis für das Unternehmen, einen Rabatt nach Anmeldung oder eine individuelle Preisliste anzeigt, muss man feststellen, welches Angebot öffentlich verfügbar ist und wie die Auswahl des Kunden funktioniert. Man kann nicht ohne Analyse allen Nutzern einen einzigen Preis übermitteln.

Konfigurierbare Produkte. Wenn der Endpreis von Maß, Material, Anzahl der Elemente, gewähltem Zubehör, Gravur oder dem Entwurf des Kunden abhängt, reicht ein einfaches Offer möglicherweise nicht aus, um alle Szenarien zu beschreiben. Die Daten müssen einer realen, kaufbaren Konfiguration entsprechen und nicht einem theoretischen, vor dem Kunden verborgenen Basispreis.

Versand und Rückgabe in strukturierten Daten

Produktdaten können um Informationen zu Versandkosten, Lieferland, Vorbereitungszeit, Transportzeit und Rückgaberegeln ergänzt werden.

Man muss nicht immer die vollständige Richtlinie bei jedem Produkt wiederholen. Wenn die Regeln für den Großteil des Angebots gleich sind, kann man sie auf Unternehmensebene beschreiben. Wenn ein bestimmtes Produkt andere Bedingungen hat — Möbeltransport, keine Standardrückgabe bei einem personalisierten Produkt, Palettenversand oder eine verlängerte Lieferzeit — kann man eine Ausnahme auf Angebotsebene vorbereiten. Kümmern Sie sich jedoch zuerst um die Grundlagen: den korrekten Preis, die Währung, die Verfügbarkeit, die Identifikatoren und die Varianten. Umfangreiche Versandinformationen beheben keinen falschen Produktpreis.

Wie generiert WooCommerce strukturierte Daten?

WooCommerce generiert grundlegende Produktdaten automatisch — sie können unter anderem Produktname, Foto, Beschreibung, SKU, Angebot, Preis, Verfügbarkeit und Bewertungen umfassen. Der endgültige Code hängt jedoch auch von der WooCommerce-Version, dem Theme, dem SEO-Plugin, dem Bewertungs-Plugin, der Merchant-Center-Integration, dem Variantensystem, den Preis-Plugins und Entwickleranpassungen ab. Daher bedeutet die bloße Aussage „WooCommerce hat Schema" noch nicht, dass die Daten vollständig und korrekt sind.

Das häufigste Problem: mehrere Product-Objekte

Auf einer einzigen Seite können gleichzeitig wirken: von WooCommerce generiertes Schema, Schema vom SEO-Plugin, Schema vom Theme, Daten vom Bewertungs-Plugin, Daten von einer Produktintegration und manuell hinzugefügtes JSON-LD. Das Ergebnis können mehrere Product-Objekte sein, die widersprüchliche Informationen übermitteln — z. B. erstes Objekt: Preis 999 € / InStock / Bewertung 4,7; zweites Objekt: Preis 1.299 € / OutOfStock / keine Bewertung; drittes Objekt: Preis 999–1.499 € / InStock / Bewertung 5,0. Jedes Code-Fragment kann syntaktisch korrekt sein, aber zusammen übermitteln sie widersprüchliche Informationen.

Sind zwei Product-Objekte immer ein Fehler? Nicht immer. Mehrere Objekte können berechtigt sein, wenn die Seite tatsächlich mehrere Produkte, ein Produkt und seine Varianten, ein Set oder eine Produktfamilie beschreibt. Das Problem tritt auf, wenn mehrere Systeme dasselbe Produkt auf unterschiedliche Weise beschreiben.

Wie findet man die Quelle der Dopplung?

Das Deaktivieren von Plugins in einem laufenden Shop sollte nicht der erste Schritt sein. Ein sichererer Prozess:

1. Öffnen Sie den Quellcode der Seite.
2. Suchen Sie nach application/ld+json.
3. Finden Sie alle Vorkommen von "@type":"Product" oder "@type": "Product".
4. Vergleichen Sie die Daten.
5. Prüfen Sie die Klassen, Kommentare und die Struktur des Skripts.
6. Stellen Sie fest, welches Plugin oder Theme den jeweiligen Block generiert.
7. Führen Sie einen Test in einer Staging-Umgebung durch, also einer für Kunden unsichtbaren Arbeitskopie des Shops.
8. Deaktivieren Sie nur die überflüssige Schema-Quelle.
9. Prüfen Sie die Produktseite erneut.

Entfernen Sie nicht das gesamte WooCommerce-Schema nur, weil der Test eine Warnung anzeigt. Stellen Sie zuerst fest, ob ein anderes Plugin den vollen Datenumfang übernimmt.

Fehler vs. Warnungen in den Google-Tests

Der Datentest kann Fehler, Warnungen und gültige Elemente anzeigen.

Ein Fehler bedeutet meist, dass ein für die jeweilige Art des erweiterten Ergebnisses erforderliches Element fehlt — z. B. kein Preis, keine Währung, ein falsches Werteformat oder kein Produktname.

Eine Warnung bedeutet, dass eine empfohlene Information fehlt, das Objekt sich aber dennoch für das Ergebnis qualifizieren kann — z. B. keine Marke, kein GTIN, keine Bewertungen oder keine Versandinformationen. Nicht jede Warnung muss um jeden Preis beseitigt werden. Wenn das Produkt keinen GTIN hat, erstellen Sie keinen falschen Code, nur damit die Meldung verschwindet. Prüfen Sie zuerst, ob das Feld tatsächlich das Produkt betrifft, ob die Daten existieren, ob sie sich zuverlässig ergänzen lassen und ob sie für den Shop von Bedeutung sind.

Schnelle Zusammenfassung: fünf Fehler, die leicht zu übersehen sind

Die folgende Liste ersetzt nicht die vorherige Analyse. Sie fasst Probleme zusammen, die sich oft erst bei einer komplexeren Shop-Konfiguration zeigen.

1. Der Preis erscheint erst nach Ausführung von JavaScript. Der erste Seitencode enthält nicht den aktuellen Preis, und das Skript ruft ihn erst nach einem Moment oder nach der Auswahl einer Variante ab. Man muss prüfen, ob Google den richtigen Wert nach dem Rendern der Seite erhält, also nach Ausführung der erforderlichen Skripte.

2. Der Cache speichert eine beendete Aktion. Der Kunde sieht bereits den regulären Preis, aber das Schema oder die ausgewählte Version der Seite übermittelt weiterhin den Aktionspreis. Das Problem kann den Seiten-Cache, den Objekt-Cache, das CDN, den Browser-Speicher oder einen separaten Feed-Cache betreffen.

3. Der Preis hängt vom Nutzertyp ab. Der Shop zeigt einem Privatkunden, einem Unternehmen, einem angemeldeten Partner oder einem Empfänger aus einem anderen Land einen anderen Betrag. Das Schema muss dem im jeweiligen Kontext öffentlich verfügbaren Angebot entsprechen und nicht einem zufälligen Preis aus einer einzigen Preisliste.

4. Ein Konfigurator wird wie ein einfaches Produkt beschrieben. Auf der Seite steht ein Preis „ab 999 €", aber die tatsächliche Konfiguration erfordert obligatorische Aufschläge. Der Code sollte den Basispreis nicht als vollständigen Produktpreis darstellen, wenn der Kunde eine solche Konfiguration nicht kaufen kann.

5. Ein ausgelaufenes Produkt hat weiterhin ein aktives Offer. Das Produkt ist archiviert oder kann nicht gekauft werden, aber das Schema zeigt weiterhin InStock und ein aktuelles Verkaufsangebot. Dann muss man die Verfügbarkeit anpassen, das Angebot entfernen oder die Seite des ausgelaufenen Produkts korrekt behandeln.

Wie implementiert man strukturierte Daten ohne Chaos?

Schritt 1. Legen Sie die Datenquelle der Wahrheit fest. Bestimmen Sie zuerst, woher Name, Preis, Verfügbarkeit, Marke, SKU, GTIN, Variante und Bewertungen stammen. In den meisten Shops sollte die Quelle WooCommerce oder ein übergeordnetes PIM- oder ERP-System sein, das die Daten mit WooCommerce synchronisiert. Korrigieren Sie das Schema nicht manuell, wenn eine Integration in einer Stunde den Produktpreis überschreibt.

Schritt 2. Prüfen Sie die grundlegenden Produktdaten. Sehen Sie vor der Arbeit am Code nach, ob in WooCommerce korrekte Namen, Preise, Varianten, Lagerbestände, SKUs, Marken, Identifikatoren, Fotos und Bewertungen vorhanden sind. Das Schema repariert keinen ungeordneten Katalog.

Schritt 3. Identifizieren Sie alle Schema-Generatoren: WooCommerce, das SEO-Plugin, das Theme, das Bewertungs-Plugin, die Merchant-Center-Integration, ein zusätzliches Schema-Plugin, eigenen Code. Legen Sie fest, welches System für die Produktdaten zuständig sein soll.

Schritt 4. Wählen Sie repräsentative Produkte aus. Testen Sie nicht nur ein einfaches Produkt. Prüfen Sie mindestens ein einfaches Produkt, ein Aktionsprodukt, ein nicht verfügbares, ein Variantenprodukt, eines mit Bewertungen, eines ohne GTIN, eines mit unterschiedlichen Variantenpreisen sowie eines in einer anderen Sprachversion.

Schritt 5. Vergleichen Sie die sichtbaren Daten mit dem Code. Bereiten Sie für jedes Produkt eine einfache Tabelle vor:

Element	Seite	Schema	Merchant Center
Name	Schreibtisch Varius 120	Schreibtisch Varius 120	Schreibtisch Varius 120
Preis	999 €	999 EUR	999 EUR
Verfügbarkeit	Verfügbar	InStock	in_stock
SKU	VARIUS-120	VARIUS-120	VARIUS-120
GTIN	590…	590…	590…

Jeder Unterschied erfordert eine Erklärung.

Schritt 6. Beheben Sie die Quelle, nicht das Symptom. Wenn das Schema den falschen Preis anzeigt, liegt das Problem möglicherweise nicht im Code selbst. Prüfen Sie die Produkt-Metadaten, den Cache, die Synchronisation, den Aktionszeitplan, die Steuereinstellungen, die gewählte Variante, die B2B-Preise und den Währungsumrechner.

Schritt 7. Testen Sie in einer Staging-Umgebung — einer Arbeitskopie des Shops, in der Sie eine Änderung ohne Risiko für Kunden und Bestellungen prüfen können. Schema-Änderungen können alle Produkte betreffen; ein Fehler in der Vorlage wird auf Tausenden von Seiten repliziert, prüfen Sie daher vor der Veröffentlichung ein einfaches Produkt, Varianten, Aktionen, fehlenden Lagerbestand, Bewertungen, verschiedene Währungen und Sprachversionen.

Schritt 8. Veröffentlichen Sie einen Teil der Änderungen. Bei einem großen Shop lohnt es sich nicht immer, den gesamten Katalog gleichzeitig zu ändern. Sie können mit einer Kategorie, ausgewählten Produkten oder einem Teil der Varianten beginnen und anschließend den Rich-Results-Test, die Search Console, das Merchant Center, die Fehlerprotokolle und die Funktion des Shops prüfen.

Schritt 9. Überwachen Sie die Daten nach der Implementierung. Das Schema kann am Tag der Veröffentlichung korrekt sein, aber nach einem WooCommerce-Update, einem Theme-Wechsel, der Installation eines neuen Plugins, einer Steueränderung, einer ERP-Integration, dem Start einer Aktion oder einer Änderung der Varianten kaputtgehen. Daher erfordern Produktdaten eine regelmäßige Kontrolle.

Wie testet man strukturierte Produktdaten?

Die folgenden Werkzeuge beantworten unterschiedliche Fragen. Eines ersetzt nicht die anderen.

Der Test auf Rich-Suchergebnisse erlaubt unter anderem zu prüfen, ob Google Product erkennt, ob kritische Fehler vorliegen, welche Eigenschaften gelesen werden und ob sich die Seite für ein Produktergebnis qualifizieren kann. Der Test bestätigt jedoch nicht, dass Google ein erweitertes Ergebnis anzeigt, dass das Merchant Center das Produkt akzeptiert, dass der Preis geschäftlich korrekt ist oder dass die Variante richtig verknüpft wurde.

Der Schema.org-Validator kann einen breiteren Bereich von Schema.org-Daten anzeigen, auch solche, die Google in einem konkreten Ergebnis nicht verwendet. Er ist hilfreich bei der Analyse von Syntax, Beziehungen zwischen Objekten, eigenen Erweiterungen und von Googles Test nicht unterstützten Typen.

Die URL-Prüfung in der Search Console zeigt, wie Google eine konkrete Seite sieht — man kann die Verfügbarkeit der Seite, die Indexierbarkeit, den gerenderten Code (also die Seite nach Ausführung der Skripte), die erkannten strukturierten Daten und das Datum des letzten Besuchs prüfen.

Produktberichte in der Search Console. Je nach Implementierung können separate Berichte zu Produkt-Snippets, Verkäuferinformationen und Fehlern bei Produktdaten erscheinen. Der Bericht zeigt Muster von Problemen, aber nicht immer die vollständige Liste aller Adressen.

Google Merchant Center. Prüfen Sie die Reiter zu Produkten, die Aufmerksamkeit erfordern, Preisabweichungen, Verfügbarkeitsabweichungen, fehlenden Identifikatoren, Variantenfehlern und Bildproblemen. Das Merchant Center kann ein Problem erkennen, das der Test einer einzelnen Adresse nicht zeigt.

Was können Sie selbst prüfen?

Die folgende Checkliste konzentriert sich auf das Verhalten eines realen Produkts. Sie ersetzt nicht die im vorherigen Abschnitt beschriebene werkzeuggestützte Analyse.

1. Testen Sie ein Aktionsprodukt. Stellen Sie sicher, dass auf der Seite der aktuelle Verkaufspreis steht, der Warenkorb denselben Betrag anzeigt, das Ende der Aktion die Daten aktualisiert und der alte Preis nicht im Cache verbleibt.

2. Testen Sie mehrere Varianten. Wählen Sie die günstigste, die teuerste, eine nicht verfügbare und eine in einer anderen Farbe. Prüfen Sie, ob sich nach der Änderung Preis, SKU, Verfügbarkeit, Foto sowie die Adresse oder der Variantenparameter aktualisieren.

3. Verifizieren Sie den GTIN an der Quelle. Vergleichen Sie den Code mit der Verpackung, der Herstellerdokumentation, der Produktdatenbank des Lieferanten sowie dem PIM- oder ERP-System. Stellen Sie sicher, dass derselbe GTIN nicht mehreren verschiedenen Varianten zugewiesen ist.

4. Prüfen Sie ein nicht verfügbares Produkt. Sehen Sie nach, ob es noch in den Warenkorb gelegt werden kann, ob die Meldung auf der Seite korrekt ist, ob alle Varianten tatsächlich nicht verfügbar sind und ob das Produkt in den Verkauf zurückkehren soll.

5. Prüfen Sie ein ausgelaufenes Produkt. Wenn das Produkt nicht zurückkehrt, stellen Sie sicher, dass die Seite kein aktives Angebot darstellt und keine Verfügbarkeit suggeriert. Erwägen Sie, eine nützliche Informationsseite zu belassen, einen Nachfolger anzugeben, den richtigen Antwortcode zu verwenden und logisch weiterzuleiten.

6. Vergleichen Sie die Bewertungen mit der Produktseite. Die Durchschnittsnote und ihre Anzahl sollten dem entsprechen, was der Nutzer sehen kann. Prüfen Sie auch, ob eine gelöschte Bewertung nicht mehr gezählt wird, eine neue Rezension den Durchschnitt aktualisiert und die Bewertungen das richtige Produkt betreffen.

7. Öffnen Sie die Fotos im privaten Modus. Prüfen Sie, ob die Foto-Adressen ohne Anmeldung funktionieren, keinen Fehler zurückgeben, das richtige Produkt zeigen und nicht zu einem Vorschaubild sehr niedriger Qualität führen.

8. Ändern Sie Sprache, Währung oder Kundentyp. Wenn der Shop mehrere Märkte oder B2B bedient, prüfen Sie, ob nach der Änderung die Währung korrekt ist, der Preis dem jeweiligen Nutzer entspricht, die Variante dieselbe bleibt und die Adresse zur richtigen Sprachversion führt.

9. Leeren Sie den Cache nach einer Preisänderung. Ändern Sie einen Testpreis in der Arbeitsumgebung, leeren Sie den Cache und prüfen Sie, ob alle Stellen gleichzeitig aktualisiert werden.

Wann lohnt es sich, dies einem Spezialisten zu übergeben?

Technische Hilfe ist gerechtfertigt, wenn die Search Console Produktfehler auf einer großen Anzahl von Seiten anzeigt, das Merchant Center Produkte ablehnt oder mehrere Plugins Product-Daten generieren.

Erwägen Sie Unterstützung, wenn die Search Console Produktfehler auf einer großen Anzahl von Seiten anzeigt, das Merchant Center Produkte wegen Preis oder Verfügbarkeit ablehnt, mehrere Plugins Product-Daten generieren, der Shop Hunderte von Varianten hat, jede Variante einen separaten GTIN und Preis hat, das Schema sich nach einem Variantenwechsel nicht aktualisiert, der Shop B2B-Preise nutzt, die Preise von Währung oder Standort abhängen, eine Integration mit ERP oder PIM läuft, die Daten erst durch JavaScript generiert werden, der Shop von einer anderen Plattform migriert wurde, Bewertungen importiert werden, sich Produktdaten zwischen Seite und Feed unterscheiden, das Theme Standardfunktionen von WooCommerce überschreibt oder das Problem Tausende von Produktseiten betrifft.

In solchen Fällen muss man SEO-Analyse, WooCommerce-Code, Produktstruktur, Merchant-Center-Feed, Preisquelle, Lagerintegration, Cache und Variantentests verbinden. Die bloße Installation eines weiteren Schema-Plugins erhöht oft die Anzahl der Konflikte, anstatt sie zu beseitigen.

---

Ein Angebot, konsistent an vier Stellen beschrieben

Strukturierte Daten für WooCommerce-Produkte sollten keine separate, manuell gepflegte Beschreibung des Shops sein. Sie müssen aus echten Produktdaten resultieren: dem aktuellen Preis, der richtigen Währung, der realen Verfügbarkeit, der konkreten Variante, der korrekten SKU und GTIN, sichtbaren Bewertungen sowie den Kaufbedingungen.

Im Rahmen des technischen SEO können wir die Produktdaten von WooCommerce, den Product- und Offer-Code, die Varianten, die Bewertungen sowie die Übereinstimmung mit dem Merchant Center analysieren. Sie erhalten eine Liste problematischer Adressen, die Quelle jedes Konflikts und einen Umsetzungsplan, ohne eine weitere Schicht inkonsistenten Schemas hinzuzufügen.