Strukturierte Daten für Produkte: Preis und Bewertung

Preis, Verfügbarkeit und Sterne direkt im Suchergebnis entstehen nicht von allein: Google muss diese Angaben eindeutig aus deiner Seite lesen können. Genau dafür sind strukturierte Daten da. Dieser Artikel zeigt, welche Felder ein Produkt braucht, wie das JSON-LD konkret aussieht, wo Shops typischerweise Fehler machen und wie du das Ergebnis prüfst.

Was strukturierte Daten leisten – und was nicht

Strukturierte Daten sind ein zusätzlicher Block im Quellcode, der die sichtbaren Inhalte der Seite noch einmal maschinenlesbar beschreibt. Das gängige Format ist JSON-LD, ein Skript-Block im HTML. Das Vokabular kommt von schema.org, die Regeln für die Darstellung in der Suche von Google.

Zwei Dinge dazu, die dir Enttäuschungen ersparen:

• Auszeichnung macht eine Seite nur infrage kommend; sie erzwingt keine Darstellung. Ob Google Preis oder Sterne zeigt, entscheidet es je Suchanfrage.
• Strukturierte Daten sind kein Rankinghebel im engeren Sinn. Sie verändern, wie dein Treffer aussieht. Das wirkt auf die Klickrate, nicht direkt auf die Position.

Der Nutzen ist trotzdem konkret: Ein Treffer mit Preis, Verfügbarkeit und Bewertungsdurchschnitt nimmt mehr Platz ein und beantwortet eine Frage, die der Suchende sonst erst durch den Klick klären könnte.

Die drei Typen, die du brauchst

Product ist der Rahmen: Name, Bild, Beschreibung, Marke, SKU, GTIN.

Offer hängt im Feld offers und beschreibt das kaufbare Angebot: Preis, Währung, Verfügbarkeit, Zustand, URL. Bei Produkten mit mehreren Varianten in verschiedenen Preisen kann statt Offer auch AggregateOffer mit lowPrice und highPrice stehen – für ein Händlerlisting verlangt Google allerdings ein echtes Offer. Wenn du Varianten sauber abbilden willst, gibt es dafür den eigenen Typ ProductGroup mit productGroupID, variesBy und hasVariant; die Varianten verweisen mit inProductGroupWithID zurück.

AggregateRating enthält den Durchschnitt und die Anzahl: ratingValue plus reviewCount oder ratingCount. Einzelne Bewertungen zeichnest du zusätzlich als Review aus, jeweils mit Autor und Bewertung.

Pflicht und Empfehlung im Überblick

Wichtig für die Einordnung: Google unterscheidet nicht zwischen „einfach“ und „ausführlich“, sondern nach dem Zweck der Seite. Produkt-Snippets sind für Seiten gedacht, auf denen man das Produkt nicht direkt kaufen kann – dort liegt der Schwerpunkt auf Bewertungen. Händlerlistings sind für Seiten, auf denen Kunden bei dir kaufen können; dort zählen Preis, Verfügbarkeit, Versand und Rückgabe. Für einen Shop ist also praktisch immer das Händlerlisting der richtige Fall.

Ein Produkt-Snippet setzt als einziges Feld name voraus, dazu muss mindestens eines von offers, aggregateRating oder review vorhanden sein. Ein Händlerlisting verlangt name, image und offers, und im Angebot Preis sowie Währung. Alles andere ist empfohlen, nicht Pflicht – auch Versand- und Rückgabeangaben. Die verbindlichen Listen stehen in der Google-Dokumentation, getrennt nach Produkt-Snippets und Händlerlistings; die Übersichtsseite zum Produkt-Markup verweist auf beide.

JSON-LD-Beispiel für eine Produktseite

Der Block gehört in den <head> oder an das Ende des <body>. Die Werte sind ein Beispiel, ersetze sie durch die echten Daten deiner Seite.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Wanderrucksack Trailhead 32 L",
  "image": [
    "https://www.beispielshop.de/bilder/trailhead-32-front.webp",
    "https://www.beispielshop.de/bilder/trailhead-32-seite.webp"
  ],
  "description": "Wanderrucksack mit 32 Litern Volumen, belüftetem Rücken und Regenhülle.",
  "sku": "TRH-32-BLK",
  "gtin13": "4012345678901",
  "brand": {
    "@type": "Brand",
    "name": "Trailhead"
  },
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.6",
    "reviewCount": "38",
    "bestRating": "5",
    "worstRating": "1"
  },
  "offers": {
    "@type": "Offer",
    "url": "https://www.beispielshop.de/wanderrucksack-trailhead-32",
    "price": "129.00",
    "priceCurrency": "EUR",
    "availability": "https://schema.org/InStock",
    "itemCondition": "https://schema.org/NewCondition",
    "priceValidUntil": "2026-12-31"
  }
}
</script>

Drei Details, die oft falsch sind: Der Preis wird als Zahl mit Punkt geschrieben, nicht als 129,00 €. Die Verfügbarkeit ist ein Wert aus der schema.org-Liste – https://schema.org/InStock oder die Kurzform InStock, aber nicht das Wort auf Lager. Und ratingValue und reviewCount müssen zu dem passen, was Besucher auf der Seite sehen.

Preis und Verfügbarkeit konsistent halten

Das ist der häufigste Grund, warum bei Shops erweiterte Darstellungen wieder verschwinden. Die Regel ist einfach: Was im Markup steht, muss auf der Seite sichtbar und aktuell sein.

Kritische Stellen im Shop-Alltag:

• Varianten. Wenn der Besucher eine andere Größe wählt und der Preis springt, muss das Markup das nachziehen – entweder pro Varianten-URL, über AggregateOffer mit Preisspanne oder über ProductGroup mit den einzelnen Varianten.
• Rabattaktionen. Ein statisch eingebauter Preis im Template überlebt keine Aktion. Der Wert muss aus der Produktdatenbank kommen.
• Ausverkauft. Bei OutOfStock kein InStock melden. Falsche Angaben führen dazu, dass Google die Darstellung entzieht.
• Mehrwertsteuer und Versand. Der Preis im Markup ist derselbe, den der Kunde sieht. Rechne nichts heraus und nichts hinzu.
• Kein Markup für Nicht-Sichtbares. Zeichne nur aus, was tatsächlich auf der Seite steht. Angaben ohne Entsprechung sind ein Richtlinienverstoß.

Wenn du deine Produktdaten zusätzlich per Feed an das Merchant Center schickst, sollten Feed und Markup die gleichen Werte enthalten. Widersprüche zwischen beiden sorgen für Ablehnungen und Preisabweichungen – wie du den Feed sauber aufsetzt, steht im Artikel zum Optimieren des Produktfeeds.

Bei Varianten, Filtern und Parameter-URLs hängt das Thema eng an Canonical-Fragen. Wenn mehrere URLs dasselbe Produkt zeigen, gehört das Markup auf die kanonische Seite; alles Weitere dazu im Artikel über Duplicate Content im Shop.

Bewertungen: die Regeln, die wirklich zählen

Sterne im Suchergebnis sind attraktiv, und genau deshalb gibt es klare Vorgaben. Bewertungen müssen von echten Kunden stammen und auf der Seite für Besucher sichtbar sein. Nicht erlaubt sind:

• selbst geschriebene oder erfundene Bewertungen,
• eingekaufte Bewertungen und Bewertungspakete,
• Bewertungen, die du aus anderen Quellen zusammenträgst und als eigene ausgibst,
• Auszeichnung eines Durchschnitts, der auf der Seite nirgends steht.

Erfundene oder eingekaufte Bewertungen verstoßen gegen die Richtlinien – unabhängig davon, ob sie jemand bemerkt. Das Risiko trägt der Shop: Google kann die erweiterte Darstellung für die betroffenen Seiten entziehen oder eine manuelle Maßnahme wegen unzulässiger strukturierter Daten verhängen. Dazu kommen Vorgaben außerhalb von Google, für die dein Shop verantwortlich ist; das ist nichts, was ein SEO-Artikel klären kann.

Der ehrliche Weg ist unspektakulär und funktioniert: nach dem Kauf freundlich um eine Bewertung bitten, den Weg dahin kurz halten, auch kritische Bewertungen stehen lassen und beantworten. Wie du das systematisch aufbaust, beschreibt der Artikel über mehr Google-Bewertungen – dort geht es um das Unternehmensprofil, die Haltung dahinter ist bei Produktbewertungen dieselbe.

Ein technischer Hinweis: aggregateRating mit reviewCount: 0 oder ohne Bewertungen führt zu Fehlern. Zeichne den Block erst aus, wenn es echte Bewertungen gibt, und lass ihn bei neuen Produkten weg.

Schritt für Schritt: einführen und prüfen

1. Bestand prüfen. Öffne den Test für Rich-Suchergebnisse und gib eine Produkt-URL ein. Viele Shopsysteme und Themes bringen schon Markup mit – oft unvollständig oder doppelt.
2. Doppeltes finden. Wenn Theme und eine App beide Product ausgeben, sieht Google zwei widersprüchliche Angaben. Entscheide dich für eine Quelle und deaktiviere die andere.
3. Felder ergänzen. Fehlt brand, sku, availability oder priceValidUntil, ergänze es im Template aus den Produktdaten, nicht von Hand.
4. Vier Seitentypen testen. Ein einfaches Produkt, ein Produkt mit Varianten, ein ausverkauftes Produkt, ein Produkt im Angebot. Diese vier deckt fast jeden Fehler ab.
5. Rendering beachten. Wenn das Markup erst durch JavaScript entsteht, prüfe in der Search Console mit der URL-Prüfung, ob es im gerenderten HTML ankommt.
6. Ausrollen und warten. Nach dem Livegang dauert es einige Tage bis Wochen, bis Google die Seiten neu erfasst hat.
7. Search Console beobachten. Unter den Berichten zu Produkt-Snippets und Händler-Angeboten stehen Fehler und Warnungen, gruppiert nach Ursache. Fehler zuerst, Warnungen danach. Wie du dich in dem Bericht zurechtfindest, steht in unserer Anleitung zur Search Console.
8. Nach jedem Theme- oder App-Update nachsehen. Markup fällt bei Updates gern still aus.

Kurzcheck vor dem Livegang

• Ein einziger Product-Block pro Produktseite, kein zweiter aus einer App.
• Preis als Zahl mit Punkt, Währung als ISO-Code.
• Verfügbarkeit als schema.org-Wert, passend zum tatsächlichen Lagerstand, und nur ein Wert.
• Bild-URLs absolut und öffentlich erreichbar, nicht hinter Login oder Hotlink-Schutz.
• aggregateRating nur bei echten, auf der Seite sichtbaren Bewertungen.
• Werte kommen aus der Datenbank, nicht aus dem Template.
• Test für Rich-Suchergebnisse ohne Fehler für alle vier Testseiten.
• Markup auch im gerenderten HTML vorhanden, nicht nur im Browser sichtbar.

In ecomando prüft der SEO-Audit die Produktseiten unter anderem auf fehlendes oder widersprüchliches Produkt-Markup, damit du nicht jede Vorlage einzeln durch den Rich-Results-Test schickst. Das ersetzt den Test nicht, spart aber das Suchen.

Strukturierte Daten gehören zu den Aufgaben, die man einmal ordentlich löst und danach nur noch überwacht. Wenn du gerade dabei bist, die Technik deines Shops durchzugehen, arbeite parallel die Checkliste für technisches SEO ab; den Gesamtüberblick liefert der Leitfaden zu SEO für Online-Shops.