AggregateRating-Schema

Kurz gesagt — AggregateRating ist Code, den du einer Seite hinzufügst und der sagt: „Der Durchschnitt dieses Elements beträgt 4.6 Sterne aus dieser Anzahl von Bewertungen.“ Damit entstehen die ⭐ Sterne-Snippets, die du unter manchen Suchergebnissen siehst. Meist verschachtelst du es im Markup des bewerteten Elements (eines Produkts, Rezepts oder Unternehmens). Google erlaubt auch eine eigenständige Variante, die das bewertete Element direkt benennt, aber die Verschachtelung ist das übliche Muster. Du kannst außerdem nicht einfach dein eigenes Unternehmen bewerten und Sterne erwarten — Google blockiert das.

Was das AggregateRating-Schema ist

Wenn eine Seite etwas wie „4.6 ★ (218 Bewertungen)“ zeigt, versteht ein Mensch das auf einen Blick. Eine Suchmaschine sieht zunächst nur Text und muss raten, was die Zahlen bedeuten. AggregateRating macht es im Code eindeutig und verwendet das gemeinsame Vokabular von schema.org: Es bezeichnet den Durchschnittswert, die Anzahl der Bewertungen, auf denen er beruht, und die Skala.

Das Schlüsselwort ist aggregate — gemeint ist der Durchschnitt vieler Bewertungen. Das unterscheidet sich vom Review-Schema, das die schriftliche Meinung einer Person auszeichnet. Seiten, die beides haben, verwenden es meist gemeinsam: ein AggregateRating für den Gesamtdurchschnitt und einige einzelne Reviews.

Fast immer wird es als JSON-LD geschrieben — ein kleiner Codeblock, der auf der Seite liegt, ohne ihr Aussehen zu verändern.

Warum sich das lohnt

Der Nutzen ist das Sterne-Rich-Snippet: goldene Sterne und eine Bewertungszahl unter einem Suchergebnis. Ein Eintrag mit Sternen fällt auf und kann mehr Klicks erhalten. Dafür braucht Google einige Angaben:

• ratingValue — der Durchschnittswert, zum Beispiel 4.6.
• mindestens eine Anzahl — entweder ratingCount (wie viele Bewertungen insgesamt) oder reviewCount (wie viele Personen eine Rezension hinterlassen haben, mit oder ohne Sternebewertung). Einer dieser Werte ist erforderlich.
• itemReviewed — das bewertete Element. Wenn du AggregateRating in ein Produkt, Rezept usw. verschachtelst, ist es durch diese Verschachtelung abgedeckt und kann entfallen — das bewertete Element braucht aber in jedem Fall einen Namen. Evidence for this claim Google supports aggregate ratings in review snippets only for eligible item types and qualifying content. Scope: Google Search review snippet requirements; stars are not guaranteed. Confidence: high · Verified: 2026-07-14 Google: Review snippet structured data

Optional beschreiben bestRating und worstRating die Skala (Google nimmt 1–5 an, wenn du sie weglässt).

Der häufigste Denkfehler

Du kannst nicht AggregateRating zu deinem eigenen Unternehmen hinzufügen und dafür Sterne erhalten. Wenn du ein lokales Unternehmen oder eine Firmenseite betreibst und „unsere Kunden bewerten uns mit 4.9 Sternen“ auszeichnest, zeigt Google diese Sterne nicht an. Google nennt das selbstreferenziell — ein Unternehmen bewertet sich selbst — und blockiert es speziell für das Markup von LocalBusiness und Organization.

Aber — und genau das sorgt oft für Verwirrung — daraus folgt nicht pauschal: „Du darfst deine eigenen Dinge nicht bewerten.“ Ein Onlineshop darf auf seinen eigenen Produktseiten rechtmäßig Sternebewertungen anzeigen. Die Sperre betrifft ein Unternehmen, das sich als Unternehmen selbst bewertet, nicht einen Shop, der echte Kundenbewertungen zu den von ihm verkauften Produkten zeigt.

Zwei weitere Fallen für Einsteiger:

• Du brauchst immer eine Anzahl, nicht nur einen Durchschnitt. Ein bloßes „4.6 Sterne“ ohne Anzahl zugrunde liegender Bewertungen reicht nicht.
• Bewertungen müssen echt sein. Gefälschte oder gekaufte Bewertungen verstoßen nicht nur gegen die Regeln — sie können zu einer manuellen Maßnahme führen, die Rich Results von deiner Seite entfernt.

Du möchtest die exakt erforderlichen Eigenschaften, den Unterschied zwischen ratingCount und reviewCount, den vollständigen Geltungsbereich der Selbstreferenz-Regel und die Lösung für häufige Search-Console-Fehler? Wechsle zum Tab Fortgeschritten.

Kurz gesagt — AggregateRating wird gewöhnlich in der aggregateRating-Eigenschaft eines übergeordneten Typs verschachtelt (Product, LocalBusiness, Recipe, Book, Course, Event, Movie, SoftwareApplication und weitere). Deshalb lassen verschachtelte Beispiele itemReviewed weg. Googles Spezifikation unterstützt aber auch ein nicht verschachteltes AggregateRating, das itemReviewed direkt benennt. In beiden Fällen braucht das bewertete Element einen Namen. Für das Sterne-Rich-Ergebnis verlangt Google ratingValue, einen von ratingCount/reviewCount und itemReviewed, wenn keine Verschachtelung vorliegt; bestRating/worstRating werden empfohlen und sind für Skalen außerhalb von 1–5 wichtig. Die Berechtigungsregel muss genau sitzen: Selbstreferenzielle Bewertungen sind speziell bei LocalBusiness/Organization für Sterne unzulässig — ein Unternehmen bewertet sich selbst —, während Product, Recipe, Movie und die meisten anderen unterstützten Typen für echte Bewertungen berechtigt bleiben. ratingCount (alle Bewertungen einschließlich reiner Sternebewertungen) und reviewCount (Personen, die eine Rezension abgegeben haben, mit oder ohne Sternebewertung) sind verschiedene Zahlen. Gültiges Markup schafft die Berechtigung für Sterne, kein Ranking; gefälschte Bewertungen können eine manuelle Maßnahme wegen strukturierter Daten auslösen. Das Thema ist sowohl unter strukturierten Daten als auch E-Commerce-SEO einsortiert, weil Bewertungs-Markup regelmäßig in E-Commerce-Audits geprüft wird.

AggregateRating vs. Review — der entscheidende Unterschied

Viele Wettbewerbsleitfäden vermischen diese beiden Typen in einer einzigen Anforderungsliste. Sie sind verschieden:

• Review zeichnet die Meinung einer Person zu einem Element aus — eine Person, ein reviewRating und ein Textkörper der Rezension.
• AggregateRating zeichnet den statistischen Durchschnitt vieler Bewertungen aus — ratingValue plus eine Anzahl.

Viele echte Implementierungen verwenden beide gemeinsam und verschachteln sie im selben übergeordneten Typ: ein aggregateRating für den Gesamtscore und ein Array von review-Objekten für einzelne Meinungen. Googles Empfehlung geht in eine Richtung: Wenn du mehrere einzelne Rezensionen auszeichnest, ergänze daneben eine aggregierte Bewertung. Das bedeutet nicht, dass ein eigenständiges AggregateRating erfundene Review-Objekte braucht — eine Seite mit nur einem Aggregat und ohne Einzelrezensionen ist eine normale, vollständige Implementierung. Merke dir: Review = eine Meinung, AggregateRating = der Durchschnitt vieler Meinungen. Für die Einzelrezension siehe das Schwester-Thema Review-Schema.

Verschachtelt oder nicht verschachtelt — zwei gültige Anbindungen

AggregateRating hat auf einer eigenen Seite keine unabhängige Bedeutung, aber es gilt auch nicht strikt „verschachteln oder gar nichts“. Google unterstützt zwei Formen:

• Verschachtelt (das häufige Muster) — AggregateRating liegt in der aggregateRating-Eigenschaft eines anderen Typs (Product, LocalBusiness, Recipe und den übrigen unten aufgeführten unterstützten Typen). Da der übergeordnete Typ das Element bereits identifiziert, lässt ein verschachteltes AggregateRating itemReviewed weg — das übergeordnete Element braucht aber weiterhin einen name.
• Nicht verschachtelt — AggregateRating kann auch allein stehen, sofern es mit itemReviewed das bewertete Element benennt. Das ist in der Praxis seltener, aber ein dokumentierter, gültiger Weg und kein Behelf.

Beide Formen brauchen den Namen des bewerteten Elements — bei Verschachtelung am übergeordneten Element, sonst in itemReviewed. Die Host-Typen, die Google für das Review-/Sterne-Rich-Ergebnis unterstützt, bilden eine endliche Liste: Book, Course, Event, LocalBusiness, Movie, Product, Recipe, Software App sowie weitere unterstützte Verschachtelungstypen (CreativeWorkSeason, CreativeWorkSeries, Episode, Game, MediaObject, MusicPlaylist, MusicRecording und Organization).

Die praktische Folge: Wenn du aggregateRating an einen nicht unterstützten Typ hängst, erscheinen selbst bei fehlerfrei validiertem Markup keine Sterne. Validierung und Berechtigung für Rich Results sind zwei verschiedene Hürden.

Erforderliche und empfohlene Eigenschaften

Googles (strengere) Spezifikation für das Sterne-Rich-Ergebnis, nicht nur das reine schema.org-Vokabular. Die Zeile zu itemReviewed hängt von der verwendeten Form ab:

Zwei Formatierungsregeln aus den eigenen Nutzungshinweisen von schema.org verhindern vermeidbare Validierungsfehler: Verwende echte Ziffern (0–9) statt ähnlich aussehender Unicode-Symbole und einen Punkt als Dezimaltrennzeichen, kein Komma. "4,6" ist ein häufiger Fehler in Regionen mit Komma als Dezimaltrennzeichen.

ratingCount vs. reviewCount — ein echter Unterschied

Viele Leitfäden verwenden die Begriffe austauschbar oder verkürzen reviewCount auf „geschriebene Rezensionen“. Googles aktuelle Eigenschaftsdefinitionen sind genauer:

• ratingCount — die Gesamtzahl der Bewertungen, einschließlich reiner Sternebewertungen ohne begleitenden Rezensionstext.
• reviewCount — die Anzahl der Personen, die eine Rezension abgegeben haben, mit oder ohne begleitende Bewertung. Es bedeutet nicht ausschließlich „geschriebene Rezensionen“, sondern bezieht sich auf Personen, die rezensiert haben, unabhängig davon, ob sie zusätzlich eine Zahlbewertung hinterließen.

In der Praxis ergeben sich auf den meisten Bewertungsplattformen trotzdem verschiedene Zahlen: Nicht jede Person, die Sterne vergibt, schreibt eine Rezension, und nicht jede Person, die rezensiert, vergibt Sterne. Ein Shop könnte 4,6 Sterne bei einem ratingCount von 1 200 anzeigen, wobei 340 Personen (reviewCount) tatsächlich Rezensionstext hinterlassen haben. Übertrage die Definitionen auf die Trennung von „bewertet“ und „rezensiert“ in deiner Plattform, statt anzunehmen, dass sie exakt dem Beispiel entspricht. Google verlangt mindestens eine der beiden Eigenschaften; liefere diejenige, die deine Plattform tatsächlich erfasst, und erhöhe keine Zahl künstlich über das hinaus, was deine Seite belegen kann.

bestRating / worstRating — außerhalb der Standardskala angeben

Wenn sie fehlen, nimmt Google eine Skala von 1–5 an. Wenn du auf einer Skala von 1–10, 1–100 oder einer anderen nicht standardmäßigen Skala bewertest, musst du bestRating/worstRating setzen, sonst kann Google die Skala falsch lesen — ein 9.2 auf einer Zehnerskala würde ohne diese Angaben als 9,2 von 5 interpretiert, was keinen Sinn ergibt.

Die Selbstreferenz-Regel für Rezensionen — genau abgegrenzt

Das ist der am häufigsten verfälschte Punkt dieses Themas, daher hier die genaue Aussage.

Googles Formulierung lautet: “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 das bewertete Unternehmen die Rezensionen über sich selbst kontrolliert, sind seine Seiten, die strukturierte Daten vom Typ LocalBusiness oder einem anderen Organization-Typ verwenden, für die Sterne-Rezensionsfunktion nicht berechtigt.“ Lies den Geltungsbereich genau: Er nennt LocalBusiness und Organization (sowie deren Untertypen). Es geht um ein Unternehmen, das sich als Unternehmen selbst bewertet.

Das gilt nicht für Product. Ein Webshop darf auf seinen eigenen Produktseiten rechtmäßig Sternebewertungen zeigen — es handelt sich um den Durchschnitt echter Kundenbewertungen eines von ihm verkauften Produkts, nicht um die Bewertung des Unternehmens selbst. Auch Recipe, Movie, Book, SoftwareApplication und die übrigen unterstützten Typen bleiben berechtigt, sofern die Bewertungen echt sind.

Die Regel geht auf eine Google-Richtlinienänderung im September 2019 („Making Review Rich Results more helpful“) zurück, die den Begriff „self-serving“ einführte — auch für Rezensionen zum eigenen Unternehmen, die direkt eingebettet oder über ein Widget eines Drittanbieters eingebunden werden. (Die Begründung dieser Ankündigung ist hier sinngemäß wiedergegeben; die oben zitierte Review-Snippet-Dokumentation ist die aktuelle zitierfähige Formulierung der Regel.) Die Folge: Ein Widget eines Drittanbieters auf deiner eigenen LocalBusiness-/Organization-Seite bleibt selbstreferenziell und damit für Sterne unberechtigt.

Genau deshalb ist das Schwester-Thema Organization-Schema hier relevant — es ist einer der beiden Host-Typen, bei denen selbst gehostete Bewertungen keine Sterne einbringen.

Nur echte Bewertungen — Spam- und Manual-Action-Regeln

Aus Googles Leitfaden folgen zwei klare Regeln:

• Nicht von anderen Websites aggregieren. Google sagt: “Don’t aggregate reviews or ratings from other websites.” (Übersetzung) „Aggregiere keine Rezensionen oder Bewertungen von anderen Websites.“ Bewertungen anderer Quellen in das eigene Markup zu übernehmen, ist unzulässig.
• Bewertungen müssen von echten Nutzern stammen. Googles Richtlinien für strukturierte Daten behandeln echte Bewertungen als verbindlich, nicht als Wunschvorstellung — das rezeptspezifische Beispiel sagt: “reviews or ratings not by actual users may result in manual action.” (Übersetzung) „Rezensionen oder Bewertungen, die nicht von echten Nutzern stammen, können zu einer manuellen Maßnahme führen.“ Dieses Prinzip gilt allgemein für die Richtlinie zu Rezensionen über verschiedene Typen hinweg.

Eine manuelle Maßnahme für irreführende oder gefälschte Bewertungen entfernt die Berechtigung der Seite für Rich Results. Das wird durchgesetzt und ist nicht nur theoretisch. Stelle außerdem sicher, dass der Rezensionstext tatsächlich auf der Seite vorhanden ist — Google erwartet, dass die ausgezeichneten Bewertungen auf derselben Seite für Nutzer leicht verfügbar sind und ein bestimmtes Element betreffen, keine Kategorie oder Liste.

AggregateRating im größeren Zusammenhang

Wie alle strukturierten Daten beeinflusst AggregateRating die Berechtigung für Rich Results, nicht das Ranking — die umfassenderen Themenbereiche Schema-Markup und strukturierte Daten erläutern das vollständig, daher wird es hier nicht noch einmal aufgerollt. aggregateRating ist eine empfohlene Eigenschaft für Product (den häufigsten Host-Typ in der Praxis) und für ProductGroup bei Bewertungsaggregationen auf Variantenebene — beides sind sinnvolle nächste Themen. Verwende JSON-LD; das ist Googles empfohlenes Format und wird in jedem Beispiel dieses Artikels verwendet.

Bing und andere Suchmaschinen: schema.org ist ein gemeinsames Vokabular von Google/Microsoft/Yahoo/Yandex, und Bings allgemeine Dokumentation zu strukturierten Daten bestätigt, dass Bing schema.org-/JSON-LD-Markup liest. Eine Gleichheit mit Googles AggregateRating-Anforderungen lässt sich derzeit nicht anhand von Microsofts Primärdokumentation belegen — Bing veröffentlicht keine vergleichbare Aufschlüsselung erforderlicher und empfohlener Eigenschaften nach Typ und keine Dokumentation zur Selbstreferenz-Regel wie Google. Außerdem ist Bings Oberfläche für Bewertungs-Rich- Results kleiner und schlechter dokumentiert. Gehe nicht davon aus, dass Bings Berechtigungsregeln Punkt für Punkt Googles Regeln entsprechen; behandle das als offene Frage, bis Bing eigene AggregateRating-spezifische Hinweise veröffentlicht.

KI-Zusammenfassung

Eine komprimierte Fassung des Abschnitts für Fortgeschrittene:

• Was es ist: schema.org/AggregateRating-Markup (meist JSON-LD) für den Durchschnitt vieler Bewertungen/Rezensionen eines Elements — anders als Review, das die Meinung einer Person auszeichnet. Viele Seiten verwenden beide gemeinsam; Google erwartet ein Aggregat, wenn bereits mehrere Einzelrezensionen ausgezeichnet werden, nicht umgekehrt.
• Verschachtelt oder nicht verschachtelt: AggregateRating liegt meist in der aggregateRating-Eigenschaft eines übergeordneten Typs (Product, LocalBusiness, Recipe, Book, Course, Event, Movie, SoftwareApplication und weitere), weshalb verschachtelte Beispiele itemReviewed auslassen. Google unterstützt aber auch ein nicht verschachteltes AggregateRating, das itemReviewed direkt benennt. Das bewertete Element braucht in jedem Fall einen Namen.
• Erforderlich für das Sterne-Rich-Ergebnis: ratingValue, mindestens einer von ratingCount/reviewCount und itemReviewed bei fehlender Verschachtelung. Empfohlen: bestRating/worstRating (außerhalb der Standardskala 1–5 unerlässlich).
• ratingCount vs. reviewCount: ratingCount = alle Bewertungen einschließlich reiner Sternebewertungen; reviewCount = Personen, die eine Rezension abgegeben haben, mit oder ohne Bewertung. Verschiedene Zahlen; einer der Werte ist erforderlich.
• Selbstreferenz-Regel (die zentrale Verwechslung), genau abgegrenzt: Selbstreferenzielle Bewertungen sind nur bei LocalBusiness/Organization für Sterne unzulässig — ein Unternehmen bewertet sich selbst —, eingeführt im September 2019. Product, Recipe, Movie usw. bleiben für echte Bewertungen berechtigt. Ein Widget mit Rezensionen zum eigenen Unternehmen bleibt selbstreferenziell.
• Die unterstützten Host-Typen sind begrenzt: Book, Course, Event, LocalBusiness, Movie, Product, Recipe, Software App sowie weitere Verschachtelungstypen. Bei einem nicht unterstützten Typ erscheinen Sterne auch dann nicht, wenn das Markup validiert.
• Nur echte Bewertungen: “Don’t aggregate reviews or ratings from other websites,” (Übersetzung) „Aggregiere keine Rezensionen oder Bewertungen von anderen Websites“, und gefälschte oder incentivierte Bewertungen können eine manuelle Maßnahme wegen strukturierter Daten auslösen, welche die Berechtigung für Rich Results entfernt.
• Formatierung: echte Ziffern (0–9), Dezimaltrennzeichen als Punkt (kein Komma).
• Berechtigung ≠ Ranking: Gültiges Markup macht die Seite nur für Sterne berechtigt; es ist kein Rankingfaktor. Bing verwendet dasselbe Vokabular, hat aber keine vergleichbare Dokumentation zur Berechtigung.

Offizielle Dokumentation

Dokumentation aus Primärquellen zu AggregateRating.

schema.org (das Vokabular)

• AggregateRating-Typ — grundlegende Typdefinition, Eigenschaftsliste (itemReviewed, ratingCount, reviewCount, geerbtes ratingValue/bestRating/worstRating) sowie Nutzungshinweise zu Ziffern und Dezimaltrennzeichen.

Google — Berechtigung und Anforderungen

• Review-Snippet: strukturierte Daten für Review und AggregateRating — die maßgebliche Spezifikation: erforderliche Eigenschaften, unterstützte Host-Typen, Geltungsbereich der Selbstreferenz-Regel (LocalBusiness/Organization) und das Verbot, von anderen Websites zu aggregieren.
• Allgemeine Richtlinien für strukturierte Daten — Spamregeln, Formulierungen zur manuellen Maßnahme und die Pflicht zu echten Bewertungen.
• Review-Rich-Results hilfreicher machen (September 2019) — Ursprung der Selbstreferenz-Regel, zitiert für den zeitlichen und sachlichen Kontext ihrer Änderung.
• Rich Results Test — Markup validieren und die Berechtigung für Sterne prüfen.

Bing / Microsoft

• Die eigene Website mit strukturierten Daten auszeichnen — Bings allgemeine Unterstützung für strukturierte Daten (schema.org, JSON-LD).

Zitate aus den Quellen

Dokumentierte Aussagen von schema.org und Google. Wenn die Quellseite den Text bereitstellt, führt der Link direkt zur zitierten Passage.

schema.org — die Typdefinition

• “The average rating based on multiple ratings or reviews.” (Übersetzung) „Die durchschnittliche Bewertung auf Grundlage mehrerer Bewertungen oder Rezensionen.“ Zum Zitat

Google-Dokumentation — ein Aggregat auszeichnen

• “Make sure to mark up an aggregate evaluation of an item by many people with schema.org/AggregateRating.” (Übersetzung) „Stelle sicher, dass du eine aggregierte Bewertung eines Elements durch viele Personen mit schema.org/AggregateRating auszeichnest.“ Zum Zitat

Google-Dokumentation — die Selbstreferenz-Regel für Rezensionen (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 das bewertete Unternehmen die Rezensionen über sich selbst kontrolliert, sind seine Seiten mit strukturierten Daten vom Typ LocalBusiness oder einem anderen Organization-Typ für die Sterne-Rezensionsfunktion nicht berechtigt.“ Zum Zitat

Google-Dokumentation — nicht von anderen Websites aggregieren

• “Don’t aggregate reviews or ratings from other websites.” (Übersetzung) „Aggregiere keine Rezensionen oder Bewertungen von anderen Websites.“ Zum Zitat

Google — Richtlinien für strukturierte Daten (Täuschung/Irreführung, manuelle Maßnahme)

• “Don’t use structured data to deceive or mislead users. Don’t impersonate any person or organization.” (Übersetzung) „Verwende strukturierte Daten nicht, um Nutzer zu täuschen oder irrezuführen. Gib dich nicht als eine Person oder Organisation aus.“ Zum Zitat
• Zu echten Bewertungen (rezeptspezifisches Beispiel, verallgemeinerbar auf die Rezensionen-Richtlinie): “reviews or ratings not by actual users may result in manual action.” (Übersetzung) „Rezensionen oder Bewertungen, die nicht von echten Nutzern stammen, können zu einer manuellen Maßnahme führen.“ Allgemeine Richtlinien für strukturierte Daten

AggregateRating vs. Review — was brauche ich?

Arbeite die Fragen der Reihe nach durch:

1. Zeichnest du die Meinung einer Person oder den Durchschnitt vieler aus?

• Meinung einer Person (eine Bewertung plus Rezensionstext) → du brauchst das Review-Schema, nicht AggregateRating.
• Durchschnitt vieler Bewertungen → AggregateRating. Weiter.
• Beides (Gesamtscore und einzelne Meinungen) → verwende beides, gemeinsam im selben übergeordneten Typ verschachtelt: ein aggregateRating plus ein Array von review-Objekten.

2. Verschachtelst du es oder steht es allein?

• Verschachtelung in Product (oder ProductGroup), Recipe, Movie, Book, Course, Event oder SoftwareApplication → unterstützter Host; echte Bewertungen sind normalerweise für Sterne berechtigt, und itemReviewed kann entfallen, weil der übergeordnete Typ das Element bereits benennt. Weiter.
• Ein LocalBusiness oder eine Organization, die sich selbst bewertet → Stopp. Selbstreferenzielle Bewertungen sind hier nicht für Sterne berechtigt. Erwarte auch bei validiertem Markup keine Sterne.
• Keine Verschachtelung → ebenfalls in Ordnung, solange AggregateRating mit itemReviewed das bewertete Element direkt benennt.
• Ein anderer übergeordneter Typ, der nicht auf Googles Liste steht → das Markup kann validieren, aber Sterne erscheinen nicht — der Host wird nicht unterstützt.

3. Sind die erforderlichen Eigenschaften vorhanden?

• Bestätige ratingValue und mindestens einen Wert aus ratingCount/reviewCount. Bei fehlender Verschachtelung setze zusätzlich itemReviewed — das bewertete Element braucht in jedem Fall einen Namen. Die fehlende Anzahl ist der häufigste Fehler.
• Außerhalb der Skala 1–5? Ergänze bestRating/worstRating, sonst kann Google sie falsch lesen.

4. Sind die Bewertungen echt und auf der Seite sichtbar?

• Echt, von Nutzern stammend, auf dieses konkrete Element bezogen und auf derselben Seite sichtbar → gut.
• Von anderen Websites aggregiert, erfunden oder incentiviert → nicht verwenden — es droht eine manuelle Maßnahme für strukturierte Daten, nicht nur ein fehlendes Snippet.

Faustregel: Review ist eine Meinung; AggregateRating ist der Durchschnitt vieler. Product und verwandte Typen dürfen echte Sterne zeigen; ein Unternehmen darf sich selbst nicht bewerten.

AggregateRating-Mythen und zu vermeidende Fehler

Mythos: „Ich kann meinem Organization-/LocalBusiness-Schema AggregateRating hinzufügen und wie ein Produkt Sterne erhalten.“ Nein. Google schließt selbstreferenzielle Bewertungen bei LocalBusiness/Organization ausdrücklich von der Sterne-Rezensionsfunktion aus — “pages that use LocalBusiness or any other type of Organization structured data are ineligible for star review feature” (Übersetzung) „Seiten, die strukturierte Daten vom Typ LocalBusiness oder einem anderen Organization- Typ verwenden, sind für die Sterne-Rezensionsfunktion nicht berechtigt“, wenn das Unternehmen die Rezensionen über sich selbst kontrolliert. Das gilt seit der Richtlinienänderung im September 2019. Ein Unternehmen erhält für seine Bewertung selbst keine Sterne; ein Shop kann seine Produkte weiterhin bewerten lassen.

Mythos: „AggregateRating und Review sind dasselbe.“ Review zeichnet die Meinung einer Person aus; AggregateRating den Durchschnitt vieler. Unterschiedliche Typen, unterschiedliche erforderliche Eigenschaften. Viele Seiten verwenden beide verschachtelt — sie sind aber nicht austauschbar, und ein Aggregat verpflichtet dich nicht, dazu einzelne Review-Objekte zu erfinden.

Mythos: „Ich brauche nur ratingValue — die Anzahl ist egal.“ Google verlangt neben ratingValue mindestens einen Wert aus ratingCount oder reviewCount. Ein bloßer Durchschnitt ohne Stichprobengröße ist nicht berechtigt.

Mythos: „ratingCount und reviewCount sind dieselbe Zahl.“ Sie sind verschieden. ratingCount umfasst reine Sternebewertungen ohne Rezensionstext; reviewCount ist die Zahl der Personen, die eine Rezension abgegeben haben, mit oder ohne zusätzliche Bewertung — nicht nur „geschriebene Rezensionen“. Eine Seite kann 1 200 Bewertungen, aber nur 340 Personen mit Rezensionstext haben. Liefere die Zahl, die deine Plattform tatsächlich erfasst — erhöhe keine künstlich.

Mythos: „Ein Rezensionen-Widget eines Drittanbieters auf meiner Unternehmensseite schafft automatisch die Berechtigung für Sterne.“ Wenn das Widget Rezensionen über dein eigenes Unternehmen bzw. deine Organisation anzeigt — selbst wenn sie von einer Plattform eines Drittanbieters stammen — ist das weiterhin selbstreferenziell und für die Sternanzeige von LocalBusiness/Organization nicht berechtigt.

Mythos: „Gefälschte oder incentivierte Fünf-Sterne-Bewertungen riskieren nur, dass das Snippet nicht erscheint.“ Google setzt die Pflicht zu echten Bewertungen durch — gefälschte Bewertungen können eine manuelle Maßnahme wegen strukturierter Daten auslösen, welche die Berechtigung der Seite für Rich Results entfernt, nicht nur ein Snippet unterdrückt.

Mythos: „AggregateRating-Schema verbessert Rankings.“ Wie jedes Schema-Markup beeinflusst es die Berechtigung für Rich Results, nicht das Ranking — es schafft die Berechtigung für Sterne, nicht eine bessere Position. (Der Themenbereich Strukturierte Daten erläutert das ausführlich.)

Fehler: Bewertungen von anderen Websites aggregieren. Googles Leitfaden sagt klar: “Don’t aggregate reviews or ratings from other websites.” (Übersetzung) „Aggregiere keine Rezensionen oder Bewertungen von anderen Websites.“ Verwende nur Bewertungen, die deine eigene Seite tatsächlich gesammelt hat.

Fehler: fehlerhaftes ratingValue. Verwende echte Ziffern und einen Punkt als Dezimaltrennzeichen (4.6, nicht 4,6 oder ein ähnlich aussehendes Unicode-Zeichen). Kommawerte sind ein häufiger und vermeidbarer Validierungsfehler.

Fehler: aggregateRating an einem nicht unterstützten Host-Typ. Ein alleinstehendes AggregateRating mit itemReviewed ist gültig, und die Verschachtelung in einem unterstützten Typ ist das häufige Muster — der Elementtyp muss aber in Googles Unterstützungsliste stehen. An einem nicht unterstützten Typ kann es validieren und trotzdem keine Sterne anzeigen.

Sauberes und fehlerhaftes AggregateRating-JSON-LD

Ein sauberes, verschachteltes Bewertungsaggregat

AggregateRating ist korrekt in ein Product verschachtelt, mit einem gültigen Durchschnitt, einer Anzahl und ausdrücklich angegebener Skala — daneben steht eine einzelne review (das häufige Muster aus der Praxis):

{
  "@context": "https://schema.org/",
  "@type": "Product",
  "name": "Trailhead 30L Hiking Backpack",
  "image": "https://example.com/img/backpack.jpg",
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.6",
    "bestRating": "5",
    "worstRating": "1",
    "ratingCount": "1200",
    "reviewCount": "340"
  },
  "review": [
    {
      "@type": "Review",
      "author": { "@type": "Person", "name": "James Smith" },
      "reviewRating": {
        "@type": "Rating",
        "ratingValue": "5",
        "bestRating": "5"
      },
      "reviewBody": "Comfortable on long days, great ventilation."
    }
  ]
}

Beachte, dass ratingCount (1 200 Bewertungen insgesamt) und reviewCount (340 Personen mit Rezension) verschiedene Zahlen sind — wie es in der Praxis meist der Fall ist.

Die nicht verschachtelte Form

Die Verschachtelung ist das häufige Muster, aber AggregateRating muss nicht in einem Product (oder einem anderen Host) liegen. Es kann allein stehen, solange es mit itemReviewed das bewertete Element benennt — das ist eine dokumentierte, gültige Form und kein Behelf:

{
  "@context": "https://schema.org/",
  "@type": "AggregateRating",
  "itemReviewed": {
    "@type": "Product",
    "name": "Trailhead 30L Hiking Backpack"
  },
  "ratingValue": "4.6",
  "bestRating": "5",
  "worstRating": "1",
  "ratingCount": "1200",
  "reviewCount": "340"
}

Gleiche Eigenschaften, gleiche Berechtigungsregeln — der einzige Unterschied ist, wo itemReviewed steht. Bei Verschachtelung ergibt es sich aus dem Elternelement und wird meist weggelassen; ohne Verschachtelung muss es ausdrücklich angegeben werden.

Dasselbe Aggregat, fehlerhaft

Jede unten markierte Zeile zeigt einen echten, häufigen Validierungsfehler:

{
  "@context": "https://schema.org/",
  "@type": "Product",
  "name": "Trailhead 30L Hiking Backpack",
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4,6"
  }
}

Was ist falsch?

• Kein ratingCount und kein reviewCount — erzeugt den klassischen Fehler „Either ‘ratingCount’ or ‘reviewCount’ should be specified“. Ein Aggregat braucht eine Stichprobengröße.
• ratingValue: "4,6" — ein Komma als Dezimaltrennzeichen. Verwende einen Punkt: "4.6".
• Kein bestRating/worstRating — bei 1–5 tolerierbar, aber bei einer anderen Skala führt das Weglassen dazu, dass Google die Skala falsch liest.

Und der Fehler, der validiert, aber trotzdem keine Sterne zeigt: dieses genaue aggregateRating an einem LocalBusiness oder einer Organization anbringen, die sich selbst bewertet — es ist selbstreferenziell und unabhängig von sauberem Markup nicht für Sterne berechtigt.

Häufige Search-Console-/Rich-Results-Testfehler → Lösungen

Tools zum Erstellen und Prüfen von AggregateRating-Markup

Mit meinem Schema-Markup-Validator würde ich beginnen, sobald du das JSON-LD geschrieben hast. Füge den Block (oder eine vollständige Seite) ein; das Tool prüft nach Schweregrad gegen das AggregateRating-Vokabular von schema.org und Googles Rich-Results-Anforderungen. Es erkennt den Fehler einer fehlenden Anzahl, das Komma als Dezimaltrennzeichen und die oben beschriebenen Skalenprobleme von bestRating/worstRating und gibt einen korrigierten, kopierbaren JSON-LD-Block zurück.

Mein Rich-Result-Berechtigungsprüfer beantwortet eine andere Frage: nicht „Ist dieses JSON-LD gültig?“, sondern „Ist diese konkrete Seite für Googles Sterne-Rich-Ergebnis berechtigt?“ Füge JSON-LD oder eine HTML-Seite ein oder rufe eine Live-URL ab. Das Tool zeigt je Typ, welche erforderlichen Felder (itemReviewed, ratingValue, ratingCount/reviewCount) vorhanden bzw. fehlend sind und welche empfohlenen Felder (bestRating, worstRating) du außerhalb der Standardskala weglässt.

Wenn du bei einer leeren Seite startest, statt vorhandenes Markup zu reparieren, bietet mein Schema-Markup-Generator ein fokussiertes Formular, um aggregateRating in Product (oder einen anderen unterstützten Host-Typ) zu verschachteln, ohne das JSON-LD von Hand zu schreiben. Beim Ausfüllen kennzeichnet er, ob eine Eigenschaft von Google verlangt, empfohlen oder nur schema.org-spezifisch ist.

Sobald das Markup diese beiden Prüfungen besteht, führe die Seite durch Googles eigenen Rich Results Test — dieses Tool verwendet Google tatsächlich für die Berechtigungsentscheidung; vor dem Ausrollen ist es daher die letzte Instanz.

Häufige AggregateRating-Probleme und ihre Lösungen

Das Markup validiert sauber, aber in Suchergebnissen erscheinen nie Sterne

Die wahrscheinlichste Ursache ist die Selbstreferenz-Regel: aggregateRating ist in LocalBusiness oder Organization verschachtelt und das Unternehmen bewertet sich selbst. Google schließt diese Kombination unabhängig davon vollständig von der Sternefunktion aus, wie sauber das JSON-LD ist. Prüfe zuerst den übergeordneten Typ — wenn er LocalBusiness oder Organization ist, verlagere die Bewertung auf echte Produktrezensionen; ein Unternehmen erhält keine Sterne durch Selbstbewertung, ein Shop kann seine Produkte aber bewerten lassen. Die zweithäufigste Ursache ist ein nicht unterstützter Host-Typ — aggregateRating in einem Typ außerhalb von Googles Liste (Book, Course, Event, LocalBusiness, Movie, Product, Recipe, SoftwareApplication und der kleineren Zusatzliste) validiert zwar, zeigt aber nie Sterne.

Rich Results Test oder Search Console meldet „Either ‘ratingCount’ or ‘reviewCount’ should be specified“

Im aggregateRating-Objekt fehlt die Eigenschaft für die Stichprobengröße. ratingValue allein reicht nicht — Google verlangt daneben mindestens einen Wert aus ratingCount oder reviewCount. Ergänze den Wert, den deine Plattform tatsächlich erfasst (alle Bewertungen einschließlich reiner Sternebewertungen oder die Anzahl der Personen mit Rezension), und prüfe erneut.

ratingValue validiert nicht, obwohl die Zahl richtig aussieht

Prüfe auf ein Komma als Dezimaltrennzeichen ("4,6" statt "4.6") oder auf eine ähnlich aussehende Unicode-Ziffer statt eines echten 0–9-Zeichens. Beides sind häufige Ursachen in Regionen, die Dezimalwerte mit Komma formatieren, und beides bleibt unsichtbar, bis ein Validator den Fehler meldet.

Validatorfehler: Der Wert für die beste Bewertung muss größer sein als der Wert für die schlechteste Bewertung

bestRating und worstRating sind vertauscht, oder worstRating fehlt und Googles Standard von 1–5 passt nicht zu deiner Skala (eine unqualifizierte Skala von 1–10 oder bis 100 wird anhand des Standards 1–5 falsch gelesen). Setze beide ausdrücklich — etwa worstRating: 1, bestRating: 5 — sobald deine Skala nicht dem Standard entspricht.

Search Console zeigt gültige Elemente, aber Sterne erscheinen nicht im Live-SERP

Eine bestandene Validierung und der Status „valid“ in Search Console bedeuten nur, dass die Seite für das Sterne-Rich-Ergebnis berechtigt ist — Google muss es nicht anzeigen. Das ist erwartbar und kein Fehler, den du weiter verfolgen musst: Berechtigung ist keine Garantie für Anzeige oder Ranking. Wenn das Markup tatsächlich gültig und berechtigt ist, gibt es auf der Markup-Seite nichts weiter zu reparieren.

Rich Results verschwanden, nachdem sie zuvor angezeigt wurden

Eine manuelle Maßnahme wegen gefälschter oder von anderen Quellen aggregierter Bewertungen entfernt die Berechtigung der Seite für Rich Results. Prüfe zuerst den Bericht zu manuellen Maßnahmen in Search Console. Gibt es keine solche Maßnahme, validiere das aktuelle Markup erneut — eine Template- oder CMS-Änderung kann eine zuvor korrekte Eigenschaft (etwa eine fehlende Anzahl oder geänderte Skala) unbemerkt brechen.

Nachweisen, dass deine AggregateRating-Änderung funktioniert

Test 1: JSON-LD-Syntax und Validierung erforderlicher Eigenschaften

Auszuführender Test: Füge das aktualisierte JSON-LD in meinen Schema-Markup-Validator ein oder führe die Live-Seite durch Googles Rich Results Test. Erwartetes Ergebnis: Keine Fehler im AggregateRating-Block — ratingValue ist mit einem echten Ziffern-/Dezimalpunktwert vorhanden und mindestens einer von ratingCount oder reviewCount ist gesetzt. Fehlerinterpretation: Ein gemeldetes fehlendes Feld bedeutet, dass die Eigenschaft im ausgelieferten Markup tatsächlich fehlt, nicht dass Caching oder Rendering schuld ist — prüfe die JSON-LD-Quelle. Beobachtungsfenster: Sofort — beide Tools lesen das Markup direkt, ohne Crawl-Wartezeit. Rollback-Auslöser: Die Validierung scheitert nach einer direkten Korrektur weiter — Template-Änderung zurücknehmen und gegen das letzte bekannte gültige JSON-LD diffen.

Test 2: Rich-Result-Berechtigung für den konkreten Host-Typ

Auszuführender Test: Meinen Rich-Result-Berechtigungsprüfer gegen die Live-URL ausführen. Erwartetes Ergebnis: Der übergeordnete Typ der Seite (z. B. Product) wird für das Review-/Sterne-Rich-Ergebnis als berechtigt angezeigt, und itemReviewed ist korrekt aufgelöst. Fehlerinterpretation: Wenn der Elterntyp LocalBusiness oder Organization ist, ist „not eligible“ erwartbares Verhalten (Selbstreferenz-Regel), kein Fehler — bestätige den Host-Typ, bevor du es als Fehlschlag behandelst. Beobachtungsfenster: Sofort. Rollback-Auslöser: Eine Seite mit berechtigtem Typ (Product, Recipe usw.) zeigt nach der Korrektur weiterhin Fehler zu fehlenden Pflichtfeldern — der Deploy hat das von Google gelesene Markup nicht aktualisiert; prüfe Caching oder einen Build-Schritt, der die Änderung überschreibt.

Test 3: Der Search-Console-Erweiterungsbericht zeigt die Korrektur

Auszuführender Test: Search Console → den passenden Erweiterungsbericht (Product-Snippets / Händler-Listings, je nach Host-Typ) für die betroffenen URLs öffnen. Erwartetes Ergebnis: Die Seite wechselt von „Invalid“ oder „Not eligible“ in den Bereich „Valid“, und die Fehlerzahl für diese URL fällt auf null. Fehlerinterpretation: Wird die Seite nach Googles erneutem Crawl weiter markiert, ist die Korrektur entweder nicht live ausgeliefert oder eine andere Pflichtangabe fehlt ebenfalls — Test 1 gegen die Live-URL, nicht gegen eine Staging-Kopie, erneut ausführen. Beobachtungsfenster: Einige Tage bis etwa eine Woche, bis Google erneut crawlt und den Bericht aktualisiert — Search-Console-Daten hinken der Live-Seite hinterher. Rollback-Auslöser: Die Zahl ungültiger Elemente steigt nach einem Template-Rollout statt zu fallen — ein Hinweis, dass die Änderung Markup auf anderen Seiten mit demselben Template beschädigt hat; Rollout pausieren.

Test 4: Das Sterne-Snippet erscheint tatsächlich im Live-SERP

Auszuführender Test: Eine manuelle Suche nach einer Anfrage, bei der die Seite rankt, und prüfen, ob die Sternebewertung unter dem Eintrag erscheint (ein privates Inkognito-Fenster vermeidet Verzerrungen durch Personalisierung). Erwartetes Ergebnis: Sterne und eine Bewertungszahl erscheinen unter dem Ergebnis. Fehlerinterpretation: Das Ausbleiben bei Status „Valid“ in Search Console ist kein zu behebender Fehler — die Anzeige liegt im Ermessen von Google und wird durch die Berechtigung nicht garantiert. Zusammen mit „Not eligible“ oder einer manuellen Maßnahme gehst du zu Test 1 oder 3 zurück. Beobachtungsfenster: Google nennt keine feste Anzeigefrist; in den folgenden Wochen regelmäßig prüfen, statt die Anzeige unmittelbar nach bestandener Validierung zu erwarten. Rollback-Auslöser: Keiner auf Markup-Seite — für eine von Google gesteuerte Anzeigeentscheidung gibt es nichts zurückzunehmen. Nur bei einer Markierung unter Manual Actions zurücksetzen.

Laufende KPIs für AggregateRating-Markup

Metrik: Anzahl gültiger Elemente (Search-Console-Erweiterungsbericht) Was sie sagt: wie viele deiner berechtigten Seiten derzeit fehlerfreies AggregateRating- Markup besitzen — die Abdeckungsseite der KPI. So ermittelst du sie: Search Console → Verbesserungen → den passenden Bericht (Product-Snippets / Händler-Listings) für deine Website. Benchmark / realistischer Bereich: kein universelles Ziel — aus der Zahl der Seiten, die das Markup tragen sollten (deine Gesamtzahl berechtigter Seiten), eine eigene Basislinie bilden und verfolgen, ob die gültigen Elemente auf diese Zahl zulaufen. Rhythmus: monatlich oder sofort nach einer Template-/CMS-Änderung am Rezensionen-Markup.

Metrik: Anzahl ungültiger/fehlerhafter Elemente (derselbe Bericht) Was sie sagt: wie viele Seiten fehlerhafte Pflichtangaben haben — die Qualitätsseite der KPI, getrennt von der Abdeckung. So ermittelst du sie: derselbe Erweiterungsbericht, Bereich Fehler/Ungültig. Benchmark / realistischer Bereich: Das einzig ehrliche Ziel ist null; jede andere Zahl steht für eine tatsächlich fehlerhafte Seite, nicht für statistisches Rauschen. Rhythmus: monatlich und immer nach einem Deployment, bei dem das Markup-Template geändert wird.

Metrik: CTR-Veränderung auf Seiten, die Sterne-Berechtigung erhalten haben Was sie sagt: ob das Sterne-Snippet tatsächlich mehr Klicks für Seiten bringt, auf denen es nun erscheint, statt nur die Berechtigungsseite zu betrachten. So ermittelst du sie: Leistungsbericht in Search Console, auf die betroffenen Seiten gefiltert; CTR der Wochen vor und nach der Markup-Auslieferung vergleichen (Search Console isoliert „Klicks speziell durch ein Sterne-Snippet“ nicht sauber, daher ist dies ein Vorher-Nachher-Proxy und keine exakte Attribution). Benchmark / realistischer Bereich: keine belastbare feste Steigerungszahl — eine eigene CTR-Basislinie vor dem Rollout auf denselben Seiten bilden und die Differenz verfolgen, da sie stark von Anfrage, Position und den Rich Results der Konkurrenz abhängt. Rhythmus: im ersten Quartal nach dem Rollout monatlich, danach vierteljährlich.

Metrik: Wachstum von ratingCount/reviewCount im Zeitverlauf Was sie sagt: ob die Stichprobengröße hinter deinem Durchschnitt tatsächlich wächst — eine gleichbleibende oder schrumpfende Zahl auf einer Seite mit aktiver Rezensionsbasis sollte untersucht werden, bevor du sie auszeichnest. So ermittelst du sie: eigene Bewertungsplattform, CMS oder Datenbank — das System, aus dem das Markup seine Quelle der Wahrheit bezieht. Benchmark / realistischer Bereich: Rohwachstum gegen die eigene Historie verfolgen; es gibt keinen externen Maßstab dafür, „wie viele Bewertungen eine Seite haben sollte“. Rhythmus: monatlich.

Teste dich selbst: AggregateRating-Schema

Fünf kurze Fragen zu schema.org/AggregateRating, den erforderlichen Eigenschaften und der Selbstreferenz-Regel für Rezensionen. Wähle jeweils eine Antwort und prüfe sie dann.

Änderungsprotokoll