aggregateRating richtig umsetzen: das Feld, das Google still ablehnt

Welche Felder verlangt aggregateRating wirklich?

aggregateRating ist ein kleines Objekt, und nur wenige Teile zählen. Du brauchst einen ratingValue, also den Durchschnittswert, und eine Zahl, aus wie vielen Bewertungen er entstanden ist. Diese Zahl steht entweder als reviewCount (Anzahl der geschriebenen Bewertungen) oder als ratingCount (Anzahl der Wertungen, inklusive reiner Sternebewertungen ohne Text), aber mindestens eine der beiden musst du angeben.

Alles andere ist optional. bestRating und worstRating stehen standardmäßig auf 5 und 1, also gibst du sie nur an, wenn deine Skala abweicht. Die meisten Shops brauchen das nie.

• ratingValue: der Durchschnitt, zum Beispiel "4,6".
• reviewCount oder ratingCount: mindestens einer ist Pflicht.
• bestRating: optional, Standardwert 5.
• worstRating: optional, Standardwert 1.

reviewCount oder ratingCount: welchen nehme ich?

Nimm ratingCount, wenn deine Zahl reine Sternebewertungen ohne Text enthält, und reviewCount, wenn jeder Eintrag im Gesamtwert eine echte geschriebene Bewertung ist. Der Unterschied ist wichtig, weil die beiden Zahlen oft auseinandergehen, und wer die falsche angibt, bläht seinen Gesamtwert auf eine Weise auf, die leicht aufzudecken ist.

Wenn hundert Personen eine Sternebewertung abgeben und vierzig davon etwas schreiben, ist reviewCount 40 und ratingCount 100. Du darfst beide angeben. Was du nicht darfst: 100 in reviewCount schreiben, obwohl nur 40 Bewertungen existieren, denn der Feldname ist eine Aussage darüber, wofür die Zahl steht.

Was besagt die Regel, dass die Zahl zur sichtbaren Seite passen muss?

Die Richtlinien von Google für strukturierte Daten verlangen, dass das aggregateRating die Bewertungen widerspiegelt, die ein Nutzer auf genau dieser Seite tatsächlich sehen kann. Die Zahl in deinem Markup und die auf der Seite gerenderten Bewertungen sollen dieselbe Menge sein. Gehen sie auseinander, gilt das Markup als nicht repräsentativ für die Seite, und das ist ein Grund, die Sterne zurückzuhalten.

Darüber stolpern Shops, die zehn Bewertungen auf einer Produktseite zeigen, im Schema aber eine Zahl von zweihundert angeben. Die Absicht mag ehrlich sein, das Produkt hat ja irgendwo wirklich zweihundert Bewertungen, aber wenn die Seite nur zehn ausspielt, überzeichnet das Markup, was die Seite enthält.

Warum wird ein shopweiter oder aufgeblähter Durchschnitt abgelehnt?

Eine häufige Ablehnung entsteht, wenn ein einziger globaler Wert auf jedes Produkt angewendet wird. Ein Shop berechnet einen Durchschnitt über alle Bewertungen und stempelt ihn auf jede Produktseite, sodass ein brandneues Produkt den Ruf eines Bestsellers erbt. Google bewertet das als irreführend, denn das aggregateRating eines Product ist eine Aussage über dieses Produkt, nicht über den Shop.

Aufblähen funktioniert genauso: die Zahl polstern, Wertungen von einer eingestellten Variante mitschleppen oder Bewertungen zählen, die nicht mehr angezeigt werden. Jedes davon bringt sichtbare Seite und angegebenes Markup zum Widerspruch, und genau dieser Widerspruch lässt die Sterne verschwinden.

• Ein shopweiter Durchschnitt, der auf jeder Produktseite wiederverwendet wird.
• Eine Zahl, die größer ist als die Bewertungen, die die Seite ausspielt.
• Wertungen, die von einem anderen Produkt oder einer anderen Variante übernommen wurden.
• Zahlen, die ausgeblendete, entfernte oder unveröffentlichte Bewertungen enthalten.

Wie prüfe ich, ob mein aggregateRating gültig ist?

Lies das gerenderte HTML, nicht das Widget. Öffne die Produktseite, schau in den Quelltext oder nutze den Test für Rich-Suchergebnisse und stelle sicher, dass das aggregateRating-Objekt im Server-HTML steht, mit ratingValue und einer Zahl. Zähle dann die tatsächlich auf der Seite gezeigten Bewertungen und prüfe, ob die beiden Zahlen eine stimmige Geschichte erzählen.

Der Test für Rich-Suchergebnisse meldet fehlende Pflichtfelder, aber er erkennt keine ehrlich wirkende Zahl, die die Seite überzeichnet. Das liegt bei dir: Das Tool prüft die Form, nicht die Wahrheit. Eine Zahl von dreihundert neben zwölf sichtbaren Bewertungen besteht den Validator und riskiert trotzdem eine manuelle Ablehnung.

Warum fehlen meine Sterne, obwohl das Markup gültig ist?

Die Validierung bestätigt die Syntax, nicht die Eignung. Dein aggregateRating kann formal perfekt sein und trotzdem keine Sterne erzeugen, wenn die Zahl der sichtbaren Seite widerspricht, wenn das Markup von einem Skript eingefügt wird, das der Crawler nicht ausführt, oder wenn Google die Sterne für diese Suchanfrage schlicht nicht zeigt. Die ersten beiden Punkte lassen sich beheben, der dritte ist Googles Entscheidung.

Das Einfügeproblem ist das leise. Viele Bewertungs-Apps rendern die Bewertung erst nach dem Laden in ein JavaScript-Widget, sodass das aggregateRating, das ein Käufer sieht, nie im HTML landet, das ein Crawler liest. Das Feld ist korrekt. Es steht nur nicht dort, wo der Crawler nachschaut.

Was macht aggregateRating jedes Mal richtig?

Ein korrektes aggregateRating ist serverseitig gerendert, pro Produkt und ehrlich: ratingValue und Zahl stehen im Seiten-HTML, bevor irgendein Skript läuft, sie beschreiben dieses eine Produkt statt den ganzen Shop, und die Zahl passt zu den Bewertungen auf der Seite. Die meisten Bewertungs-Apps wurden für den Käufer auf der Seite gebaut und rendern die Sterne in ein Widget, das richtig aussieht und für einen Crawler falsch liest. Die Bewertung, die du bereits hast, in lesbares, produktgenaues und zahlenkorrektes Markup zu bringen, damit sie in der Suche die Sterne verdient und in der KI-Suche zitierbar bleibt, ist die Lücke, die BeyondReviews schließen soll.