Product-Schema im Detail: Preis, Verfügbarkeit, Bewertungen

1. Warum Product-Schema über Sichtbarkeit im Suchergebnis entscheidet

Product-Schema markiert strukturierte Daten nach dem Schema.org-Vokabular direkt im Produktseiten-HTML und ist die Grundlage für Rich Results wie Preis, Verfügbarkeitsstatus und Sternebewertung in der Google-Suche. Ein Suchergebnis mit sichtbarem Preis und Bewertungssternen sticht optisch aus der Ergebnisliste heraus und erhöht die Klickrate messbar gegenüber einem reinen Text-Snippet, weil Nutzer bereits vor dem Klick die wichtigsten Kaufsignale sehen. Für Magento-Shops mit umfangreichen Katalogen ist das kein Nice-to-have, sondern ein direkter Hebel auf den organischen Traffic pro Produktseite.

Google nutzt Product-Schema zusätzlich als strukturierte Datenquelle für das Merchant-Center-Ökosystem und für Google-Shopping-Ergebnisse, sofern die entsprechenden Feeds korrekt verknüpft sind. Fehlerhafte oder unvollständige Auszeichnung führt nicht nur zu entgangenen Rich Results, sondern in wiederholten Fällen zu manuellen Maßnahmen gegen die gesamte Domain, wenn Google systematische Abweichungen zwischen Schema und sichtbarem Content feststellt. Die Investition in sauberes Product-Schema zahlt sich also doppelt aus: höhere Klickrate und geringeres Risiko einer Rich-Snippet-Sperre.

2. Die wichtigsten Product-Schema-Eigenschaften im Überblick

Der Product-Typ nach Schema.org kennt weit mehr Eigenschaften, als in der Praxis genutzt werden. Kern sind name, image, description und sku als Basisidentifikation, ergänzt um brand als eigenes Brand-Objekt mit name-Eigenschaft. Für die Produktidentifikation über Grenzen hinweg erwartet Google zusätzlich mindestens eine globale Kennung: gtin (bzw. gtin8/gtin12/gtin13/gtin14 je nach Produktkategorie) oder mpn in Kombination mit brand, wenn keine GTIN existiert.

Das offers-Objekt (Typ Offer oder AggregateOffer bei Varianten) trägt Preis, Währung und Verfügbarkeit und ist für jedes verkäufliche Produkt die wichtigste Teilstruktur überhaupt. aggregateRating und review sind optional, aber conversion-relevant, weil sie Sternebewertungen im Suchergebnis auslösen. Weitere empfohlene Eigenschaften wie color, size, material oder additionalProperty verbessern die Sichtbarkeit in Google-Shopping-Filtern, sind für das reine Rich-Snippet im organischen Suchergebnis aber nicht entscheidend.

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Laufschuh AirRun Pro",
  "image": [
    "https://mironsoft.de/media/catalog/product/airrun-pro-1.jpg",
    "https://mironsoft.de/media/catalog/product/airrun-pro-2.jpg"
  ],
  "description": "Leichter Laufschuh mit Dämpfungssohle für Straße und leichtes Gelände.",
  "sku": "MS-AR-4102",
  "mpn": "AR4102-42",
  "gtin13": "4006381333931",
  "brand": {
    "@type": "Brand",
    "name": "Mironsoft Sports"
  },
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.6",
    "reviewCount": "312"
  },
  "offers": {
    "@type": "Offer",
    "url": "https://mironsoft.de/laufschuh-airrun-pro",
    "priceCurrency": "EUR",
    "price": "89.90",
    "priceValidUntil": "2026-12-31",
    "availability": "https://schema.org/InStock",
    "itemCondition": "https://schema.org/NewCondition"
  }
}

3. Das Offers-Objekt: Preis, Währung und Verfügbarkeit korrekt auszeichnen

Das offers-Objekt benötigt zwingend price und priceCurrency (ISO-4217-Code wie EUR oder USD) sowie availability als URL aus dem Schema.org-Vokabular, etwa https://schema.org/InStock, OutOfStock, PreOrder oder LimitedAvailability. Ein häufiger Fehler ist die Angabe von Preisen als Zeichenkette mit Währungssymbol statt als reine Zahl, etwa "49,90 €" statt "49.90". Das führt in der Google Search Console zuverlässig zu einem Validierungsfehler.

Bei Produkten mit Varianten (Größe, Farbe) bildet AggregateOffer die Preisspanne über lowPrice, highPrice und offerCount ab, während jede einzelne Variante idealerweise ein eigenes Offer mit eigener sku und eigenem availability-Wert erhält. Zusätzlich empfiehlt Google seit 2023 priceValidUntil, um die Gültigkeitsdauer eines Preises explizit zu machen, sowie shippingDetails und hasMerchantReturnPolicy als eigene strukturierte Unterobjekte, die zusammen mit den Merchant-Listing-Richtlinien für Google-Shopping-Sichtbarkeit relevant werden.

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Laufschuh AirRun Pro",
  "offers": {
    "@type": "AggregateOffer",
    "priceCurrency": "EUR",
    "lowPrice": "79.90",
    "highPrice": "94.90",
    "offerCount": "4",
    "offers": [
      {
        "@type": "Offer",
        "sku": "MS-AR-4102-40",
        "price": "89.90",
        "priceCurrency": "EUR",
        "availability": "https://schema.org/InStock",
        "shippingDetails": {
          "@type": "OfferShippingDetails",
          "shippingRate": {
            "@type": "MonetaryAmount",
            "value": "4.90",
            "currency": "EUR"
          },
          "shippingDestination": {
            "@type": "DefinedRegion",
            "addressCountry": "DE"
          },
          "deliveryTime": {
            "@type": "ShippingDeliveryTime",
            "handlingTime": {
              "@type": "QuantitativeValue",
              "minValue": "0",
              "maxValue": "1",
              "unitCode": "DAY"
            },
            "transitTime": {
              "@type": "QuantitativeValue",
              "minValue": "1",
              "maxValue": "3",
              "unitCode": "DAY"
            }
          }
        },
        "hasMerchantReturnPolicy": {
          "@type": "MerchantReturnPolicy",
          "applicableCountry": "DE",
          "returnPolicyCategory": "https://schema.org/MerchantReturnFiniteReturnWindow",
          "merchantReturnDays": "30"
        }
      }
    ]
  }
}

4. AggregateRating und Review: Bewertungen ohne Abstrafung auszeichnen

aggregateRating benötigt ratingValue und reviewCount (oder ratingCount) als Pflichtfelder; bestRating und worstRating sind optional, werden bei Fehlen aber von Google standardmäßig als 1 bis 5 angenommen. Entscheidend ist, dass die ausgezeichneten Bewertungen tatsächlich von echten Kunden stammen und auf der Seite sichtbar sind. Google verbietet explizit selbst erstellte, gekaufte oder von Drittseiten kopierte Bewertungen und entzieht bei Verstößen konsequent die Rich-Snippet-Berechtigung für die betroffene Domain.

Ein einzelnes review-Objekt ohne begleitendes aggregateRating wird von Google für Produktseiten grundsätzlich ignoriert; Review-Schema ist nur in Kombination mit einer Gesamtbewertung rich-result-fähig. Wer ein Bewertungssystem wie Yotpo, Trustpilot oder ein Magento-natives Review-Modul einsetzt, sollte aggregateRating direkt aus der Datenbank berechnen statt statisch zu pflegen, damit reviewCount und ratingValue jederzeit mit der sichtbaren Sternebewertung auf der Seite übereinstimmen.

5. Pflichtfelder vs. empfohlene Felder nach Googles Richtlinien

Googles Structured-Data-Richtlinien für Product unterscheiden explizit zwischen required und recommended properties. Pflicht sind name sowie mindestens eine Kombination aus offers, review oder aggregateRating. Ein Produkt ganz ohne diese drei gilt für Google als nicht rich-result-fähig. Innerhalb von offers sind price, priceCurrency und availability faktisch verpflichtend, auch wenn Schema.org selbst sie technisch als optional führt.

Empfohlen, aber nicht zwingend, sind image, description, sku, mpn, gtin, brand sowie bei Bewertungen die Einzelbewertungen über review. Diese Felder erhöhen zwar nicht die Rich-Snippet-Berechtigung direkt, verbessern aber die Qualität der Google-Shopping-Einbindung und die Trefferquote bei Produktsuchen mit spezifischen Filtern wie Marke oder Artikelnummer. Die praktische Faustregel für Magento-Shops: alles, was ohnehin im Produktdatenblatt gepflegt wird, sollte auch ins Schema übernommen werden, weil der Zusatzaufwand bei automatisierter Generierung gegen null geht.

6. Häufige Validierungsfehler und wie man sie vermeidet

Der mit Abstand häufigste Fehler ist ein fehlendes oder falsches availability-Feld, gefolgt von Preisangaben im Schema, die vom tatsächlich angezeigten Preis auf der Seite abweichen, etwa weil ein Sonderpreis im Frontend, aber der reguläre Preis im Schema steht. Google prüft diese Übereinstimmung aktiv und markiert die betroffene Seite in der Search Console unter "Nicht behebbare Probleme", bis die Diskrepanz behoben ist.

Weitere typische Fehler: price als Text mit Tausendertrennzeichen oder Währungssymbol statt reiner Dezimalzahl, availability als Freitext statt vollständiger Schema.org-URL, aggregateRating ohne zugehöriges reviewCount, und mehrere widersprüchliche JSON-LD-Blöcke für dasselbe Produkt auf einer Seite, etwa durch ein zusätzliches Drittanbieter-Modul. Jeder dieser Fehler lässt sich mit einer festen Regel vermeiden: Das Schema muss aus derselben Datenquelle generiert werden wie der sichtbare Content, niemals aus einer separaten, unabhängig gepflegten Struktur.

// WRONG: price as text with currency symbol, availability as free text
{
  "offers": {
    "@type": "Offer",
    "price": "89,90 EUR",
    "availability": "Auf Lager"
  }
}

// CORRECT: price as plain decimal, availability as full schema.org URL
{
  "offers": {
    "@type": "Offer",
    "priceCurrency": "EUR",
    "price": "89.90",
    "availability": "https://schema.org/InStock"
  }
}

// WRONG: aggregateRating without reviewCount, ratingValue out of range
{
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "6"
  }
}

// CORRECT: matching reviewCount, ratingValue within the default 1 to 5 scale
{
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.6",
    "reviewCount": "312"
  }
}

7. Preis- und Verfügbarkeitsaktualität: Googles Frische-Anforderungen

Google verlangt für Product-Rich-Results, dass price und availability spätestens alle 30 Tage aktualisiert werden, auch wenn sich der Wert inhaltlich nicht geändert hat. Andernfalls verliert die Seite stillschweigend ihre Rich-Snippet-Berechtigung, ohne dass in der Search Console zwingend ein Fehler angezeigt wird. Für Magento-Shops mit dynamischer Preisbildung ist das in der Regel unkritisch, weil das Schema bei jedem Seitenaufruf oder Cache-Refresh neu generiert wird.

Kritisch wird es bei stark gecachten Seiten mit langer Full-Page-Cache-TTL: Wenn eine Produktseite 90 Tage unverändert aus dem Cache ausgeliefert wird, veraltet auch das eingebettete Schema, selbst wenn sich der reale Lagerbestand längst geändert hat. Die Lösung ist, die Cache-Invalidierung für price und availability an dieselben Events zu koppeln, die auch den sichtbaren Preis und Bestand aktualisieren, statt eine separate Gültigkeitsdauer für das Schema zu definieren.

8. Validierung mit Rich Results Test und Search Console

Der Google Rich Results Test prüft eine einzelne URL oder einen Code-Schnipsel gegen die aktuellen Google-Richtlinien und zeigt exakt an, welche Properties als fehlend, ungültig oder nur empfohlen markiert sind, inklusive einer Live-Vorschau, wie das Rich Result in der Suche aussehen würde. Für die Entwicklung ist das Tool unverzichtbar, weil es Fehler bereits vor dem Deployment sichtbar macht, ohne auf die nächste Google-Crawling-Runde warten zu müssen.

Für die laufende Überwachung im Katalogmaßstab ist die Google Search Console unter "Erweiterungen" > "Produkte" der richtige Ort: Sie aggregiert Fehler über alle indexierten Produktseiten hinweg und gruppiert sie nach Fehlertyp, etwa "Fehlende Feldangabe: price". Ein wöchentlicher Blick in diesen Bericht deckt systematische Probleme auf, die einzelne Stichprobenprüfungen mit dem Rich Results Test übersehen würden, etwa wenn ein neues Attribut-Set im Katalog das Schema für eine ganze Produktkategorie bricht.

9. Magento-2-Implementierung: ViewModel und JSON-LD in Hyvä

In Magento 2 gehört die Generierung von Product-Schema strikt in ein ViewModel, das ArgumentInterface implementiert und über Dependency Injection in die Produktseiten-Layout-XML eingebunden wird, niemals in eine Block-Klasse mit Geschäftslogik oder gar hartcodiert im phtml-Template. Das ViewModel liest Preis, Verfügbarkeit und Bewertung direkt aus denselben Repositories und Services, die auch die sichtbare Produktseite befüllen (ProductRepositoryInterface, ReviewFactory, StockRegistryInterface), damit Schema und sichtbarer Content garantiert konsistent bleiben.

Im Hyvä-Theme wird das erzeugte JSON-LD über ein eigenes phtml-Template im catalog_product_view.xml-Layout-Handle ausgegeben, mit einem dedizierten JSON-Encoder statt manueller String-Konkatenation, um Injection-Risiken auszuschließen. Da Hyvä keine Knockout.js-Templates nutzt, lässt sich das Schema als reines Server-Side-Rendering direkt beim ersten HTML-Response ausliefern, was zusätzlich die Crawlbarkeit verbessert, weil Google das Schema nicht erst nach JavaScript-Ausführung sieht.

<!-- app/code/Mironsoft/SeoSuite/view/frontend/layout/catalog_product_view.xml -->
<page xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xsi:noNamespaceSchemaLocation="urn:magento:framework:View/Layout/etc/page_configuration.xsd">
    <body>
        <referenceBlock name="product.info.main">
            <block class="Magento\Framework\View\Element\Template"
                   name="mironsoft.product.schema"
                   template="Mironsoft_SeoSuite::product/schema.phtml"
                   before="-">
                <arguments>
                    <!-- ViewModel provides Product schema data, decoupled from block logic -->
                    <argument name="view_model" xsi:type="object">Mironsoft\SeoSuite\ViewModel\ProductSchema</argument>
                </arguments>
            </block>
        </referenceBlock>
    </body>
</page>

<?php
/** @var Magento\Framework\View\Element\Template $block */
/** @var Mironsoft\SeoSuite\ViewModel\ProductSchema $viewModel */
$viewModel = $block->getData('view_model');
?>
<?php if ($viewModel->getProductSchemaJson()): ?>
<script type="application/ld+json">
    <?= /* @noEscape */ $viewModel->getProductSchemaJson() ?>
</script>
<?php endif; ?>

Product-Schema-Elemente im direkten Vergleich

Die folgende Übersicht fasst zusammen, welche Elemente Pflicht sind, wie der typische Fehler aussieht und wie die korrekte Umsetzung im Magento-Kontext lautet.

In der Praxis hängen die häufigsten Product-Schema-Fehler eng zusammen: Wer price und availability zuverlässig aus derselben Datenquelle wie den sichtbaren Content generiert, vermeidet automatisch auch die meisten Diskrepanz-Fehler bei aggregateRating und Varianten. Die Tabelle dient als Checkliste vor jedem Rich-Results-Test.

10. Zusammenfassung

Product-Schema löst ein konkretes Problem: Es entscheidet, ob ein Suchergebnis nur als Text erscheint oder mit Preis, Verfügbarkeit und Sternebewertung heraussticht und dadurch mehr Klicks generiert. Die Pflichtfelder sind überschaubar: name, mindestens eines aus offers/review/aggregateRating, und innerhalb von offers zwingend price, priceCurrency und availability als vollständige Schema.org-URL. Empfohlene Felder wie gtin, mpn und brand verbessern zusätzlich die Google-Shopping-Sichtbarkeit.

Die meisten Validierungsfehler entstehen durch Diskrepanzen zwischen Schema und sichtbarem Content oder durch veraltete Preis- und Verfügbarkeitsangaben in stark gecachten Seiten. Wer das Schema konsequent aus derselben Datenquelle generiert wie die sichtbare Produktseite, über ein sauberes Magento-ViewModel statt Block-Hacks, vermeidet fast alle dieser Fehler von Anfang an und behält über Rich Results Test und Search Console jederzeit den Überblick.

11. FAQ: Product-Schema im Detail