--- title: aggregateRating slug: aggregate-rating canonical_url: https://www.geoquality.ai/glossar/aggregate-rating md_url: https://www.geoquality.ai/glossar/aggregate-rating.md language: de last_modified: 2026-05-03T00:00:00+00:00 related_terms: [json-ld, local-business-schema, schema-org, software-application-schema, structured-data] content_hash: cdf830085dd8df1d license: CC BY 4.0 author: Marco Biner (geoquality.ai) schema_type: DefinedTerm --- # aggregateRating aggregateRating ist eine Schema.org-Property für strukturierte Bewertungs-Aggregate (Sterne plus Anzahl Bewertungen) — schaltet Star-Snippets in Google Rich Results frei und ist relevant für Produkte, Lokalbusinesses, Software und Services mit User-Bewertungen. ## Erläuterung aggregateRating ist die Schema.org-Property für aggregierte Bewertungen einer Entity — typisch Sterne-Bewertung plus Anzahl der zugrundeliegenden Reviews. Sie wird mit einem AggregateRating-Sub-Objekt befüllt und schaltet bei Google die markanten Star-Snippets in den Suchergebnissen frei. Aus GEO-Sicht ist aggregateRating ein wichtiger Trust-Hebel — wenn echte User-Bewertungen vorliegen. Google's Star-Snippets erhöhen die Click-Through-Rate aus Suchergebnissen messbar (typisch 15-30 Prozent), und KI-Modelle nutzen Bewertungs-Aggregate als Authority-Signal bei Produkt- oder Service-Anfragen. Technisch hat AggregateRating drei zentrale Properties. ratingValue ist der durchschnittliche Bewertungs-Wert (typisch 1-5, kann auch andere Skalen sein). reviewCount ist die Anzahl der zugrundeliegenden Reviews. bestRating und worstRating definieren die Skala (Default ist 1-5). Plus optional itemReviewed als Verweis auf die bewertete Entity. Eine kritische Konvention: aggregateRating darf nur mit echten User-Bewertungen ausgezeichnet werden. Fake-Ratings werden von Google seit 2020 systematisch erkannt und führen zu Penalties — verlust der Star-Snippets bis hin zur Domain-Sichtbarkeits-Reduktion. Die Bewertungen müssen tatsächlich auf der Page sichtbar sein und nachvollziehbar. Für eine Schweizer KMU bedeutet aggregateRating konkret: nur einsetzen wenn echte Bewertungen vorliegen. Bei Restaurants, Hotels, Praxen, Online-Shops mit User-Reviews: AggregateRating mit ratingValue und reviewCount, plus Review-Sub-Entitäten für die einzelnen Bewertungen. Bei Sites ohne echte Bewertungen: weglassen. Manipulation ist rechtlich und SEO-technisch problematisch. Bei Sites mit ehrlichem Reviews-Backend (Trustpilot-Sync, eigene Review-Datenbank, Plattform-Reviews via API) ist aggregateRating ein hoher Hebel. Bei Sites ohne Reviews ist es eine Falle — Manipulationsversuche werden erkannt und führen zu Penalties. Mein Standard für Klienten: nur einsetzen, wenn echte Reviews vorhanden sind und automatisch aktualisiert werden. Plus mindestens eine Review-Sub-Entity ausspielen, sonst werden Star-Snippets nicht freigeschaltet. Bei aggregateRating-Pflege lohnt sich auch der Blick auf reviewCount-Wachstum über die Zeit — ein langsam wachsender Review-Pool wirkt authentischer als plötzliche Sprünge. Die Verbindung zu Product- oder LocalBusiness-Entities ist Standard. Bei E-Commerce: aggregateRating an jedem Product. Bei stationären Geschäften: aggregateRating an LocalBusiness . Bei SaaS-Produkten: aggregateRating an SoftwareApplication . Diese Entity-Typ-spezifische Auszeichnung macht die Bewertung im Kontext sichtbar — ein Restaurant-Bewertung wird anders interpretiert als eine SaaS-Bewertung, aber beide nutzen dasselbe AggregateRating-Pattern. Bei Sites mit ehrlichem Reviews-Backend (Trustpilot-Sync, eigene Review-Datenbank, Plattform-Reviews via API) ist aggregateRating ein hoher Hebel. Bei Sites ohne Reviews ist es eine Falle — Manipulationsversuche werden erkannt und führen zu Penalties. Mein Standard für Klienten: nur einsetzen, wenn echte Reviews vorhanden sind und automatisch aktualisiert werden. Plus mindestens eine Review-Sub-Entity ausspielen, sonst werden Star-Snippets nicht freigeschaltet. Bei aggregateRating-Pflege lohnt sich auch der Blick auf reviewCount-Wachstum über die Zeit — ein langsam wachsender Review-Pool wirkt authentischer als plötzliche Sprünge. Die Verbindung zu Product- oder LocalBusiness-Entities ist Standard. Bei E-Commerce: aggregateRating an jedem Product. Bei stationären Geschäften: aggregateRating an LocalBusiness. Bei SaaS-Produkten: aggregateRating an SoftwareApplication. Diese Entity-Typ-spezifische Auszeichnung macht die Bewertung im Kontext sichtbar — ein Restaurant-Bewertung wird anders interpretiert als eine SaaS-Bewertung, aber beide nutzen dasselbe AggregateRating-Pattern. ## Praxisbeispiel Product mit aggregateRating und einzelnen Reviews: { "@type": "Product", "@id": "https://www.beispiel.ch/produkte/laptop-stand#product", "name": "Ergonomischer Laptop-Stand", "aggregateRating": { "@type": "AggregateRating", "ratingValue": "4.7", "reviewCount": "127", "bestRating": "5", "worstRating": "1" }, "review": [ { "@type": "Review", "reviewRating": { "@type": "Rating", "ratingValue": "5" }, "author": { "@type": "Person", "name": "Anna B." }, "reviewBody": "Sehr stabil, gute Verarbeitung." } ] } Aggregate-Daten plus mindestens eine Review als Beleg. Google fordert bei aggregateRating mindestens eine sichtbare Review — sonst werden Star-Snippets nicht ausgespielt. ## Häufige Fehler - aggregateRating ohne echte Bewertungen ausspielen — Google erkennt Fake-Ratings und verhängt Penalties. - Bewertungen nur im Markup, nicht sichtbar auf der Page — Google fordert sichtbare Bewertungs-Inhalte. - ratingValue und reviewCount inkonsistent zur Realität — bei 5 Reviews keine 4.9-Bewertung von 200 Usern auszeichnen. - bestRating und worstRating bei Custom-Skalen vergessen — wenn die Skala nicht 1-5 ist, müssen die Grenzen definiert werden. - aggregateRating an Entities setzen, die keine Bewertungen haben können — z. B. an Articles oder Glossar-Begriffen. ## Best Practices - aggregateRating nur bei Entities mit echten User-Bewertungen ausspielen — Product, LocalBusiness, SoftwareApplication. - Sichtbare Bewertungen auf der Page sicherstellen — Google fordert Markup-Inhalte sichtbar. - Mindestens eine Review-Sub-Entity ausspielen — Google fordert das für Star-Snippets. - Werte konsistent zur Realität halten — automatisch aus Review-Datenbank generieren statt manuell pflegen. - Bei Custom-Skalen: bestRating und worstRating explizit setzen — Default ist 1-5. - Verbinde aggregateRating mit itemReviewed-Property bei Stand-alone-Reviews — verlinkt Bewertung mit Bewerteter Entity. ## Fakten - aggregateRating ist seit Schema.org 1.0 (2011) verfügbar und einer der ersten Schema-Properties für Trust-Signale. - Google's Star-Snippets in Suchergebnissen erhöhen die CTR um 15-30 Prozent — eine der grössten Sichtbarkeits-Verbesserungen via Schema.org. - Seit 2020 erkennt Google Fake-aggregateRating systematisch und verhängt Penalties — die Toleranz für Manipulation ist null. - Bei Produkten ist aggregateRating eines der wichtigsten Markup-Elemente für E-Commerce-SEO. - Im DACH-Raum nutzen 2026 etwa 23 Prozent aller E-Commerce-Sites aggregateRating — wertvoller Differenzierungs-Hebel. - Die Skala muss konsistent sein — wenn ratingValue 5 und bestRating 5, ist das volle Bewertung; wenn ratingValue 4.5 und bestRating 10, ist das eher mittelmäßig. ## FAQ ### Brauche ich aggregateRating für meine KMU-Site? Nur wenn du echte User-Bewertungen hast und auf der Page sichtbar machst. Bei Service-Sites ohne strukturiertes Bewertungs-System: nicht einsetzen. Bei Restaurants, Hotels, Online-Shops mit Reviews: Pflichtprogramm. Faustregel: wenn du nicht aktiv Bewertungen sammelst, kein aggregateRating. ### Was passiert bei Fake-Ratings? Google erkennt Manipulation seit 2020 systematisch. Penalties reichen von Star-Snippet-Entzug bis zu Domain-Sichtbarkeits-Reduktion in der Suche. Bei E-Commerce kann das schwerwiegende Auswirkungen auf das Geschäft haben — Fake-Ratings sind ein hohes Risiko mit minimalem Upside. ### Wie viele Reviews sind nötig? Google fordert keine spezifische Mindestzahl, aber unter 3-5 Reviews sind Star-Snippets selten sichtbar. Erste Reviews müssen aktiv gesammelt werden — Customer-Feedback nach Kauf, Service-Bewertungen, Plattform-Reviews mit Site-Sync. Bei wachsendem Review-Pool wachsen Star-Snippet-Effekte. ### Kann ich Plattform-Reviews (Google, Trustpilot) nutzen? Eingeschränkt. Reviews müssen first-party auf der eigenen Site sein, nicht nur auf externen Plattformen. Google akzeptiert keine aggregateRating, die nur Trustpilot-Daten zeigen — die Reviews müssen auf der Page selbst sichtbar sein. Plattform-Integration via Widget/Embed ist OK, aber die Reviews müssen ins HTML. ### Wie verbinde ich Reviews mit Pricing-Information? Bei Products: aggregateRating und offers parallel pflegen — Bewertung zeigt Quality, offers zeigen Pricing. Beide ergeben das vollständige Produkt-Bild. KI-Modelle bei Anfragen wie „Was ist ein gutes günstiges X?“ nutzen beide Properties. ### Soll ich ratingValue rund oder mit Dezimalstellen? Dezimalstellen sind authentischer (4.7 statt 5.0). 5.0 bei vielen Reviews wirkt zu perfekt und kann Skepsis auslösen. Bei wenigen Reviews (< 5) sind ganze Zahlen OK. Best Practice: automatisch aus Review-Daten berechnen, mit einer Dezimalstelle ausspielen — realistisch und glaubwürdig. ## Experten-Definition aggregateRating ist Pflicht für jede Site mit echten User-Bewertungen — und gleichzeitig der Schema-Typ mit dem höchsten Manipulations-Risiko. Google's Erkennung von Fake-Ratings ist 2026 sehr gut, Penalties sind real und schmerzhaft. Mein Standard: nur einsetzen bei echten Bewertungen, automatisch aus Review-Backend generieren, niemals manuell „aufhübschen“. Was ich konsistent sehe: KMU mit korrekt ausgezeichneten aggregateRatings (echte Reviews, sichtbar auf der Page, automatisch aktuell) gewinnen 15-30 Prozent CTR aus Google-Suchergebnissen. KMU mit Fake-Ratings verlieren langfristig Authority. Die Versuchung ist gross, der Schaden noch grösser. ## Verwandte Begriffe - [JSON-LD](https://www.geoquality.ai/glossar/json-ld.md) — JSON-LD ist ein W3C-standardisiertes Format zur Einbettung strukturierter Daten in Webseiten — typischerweise nach Schema.org-Vokabular — und der von Google sowie allen grossen KI-Crawlern bevorzugte Weg, Entitäten und Beziehungen maschinenlesbar zu beschreiben. - [LocalBusiness-Schema](https://www.geoquality.ai/glossar/local-business-schema.md) — LocalBusiness ist der Schema.org-Typ für stationäre Geschäfte mit physischer Adresse und Öffnungszeiten — Pflicht für Restaurants, Praxen, Werkstätten, Handwerksbetriebe und alle KMU mit lokalem Geschäftsbetrieb. - [Schema.org](https://www.geoquality.ai/glossar/schema-org.md) — Schema.org ist das von Google, Microsoft, Yahoo und Yandex gemeinsam entwickelte Vokabular zur strukturierten Beschreibung von Web-Inhalten — der De-facto-Standard für maschinenlesbare Auszeichnung und das technische Fundament jeder GEO-Strategie. - [SoftwareApplication-Schema](https://www.geoquality.ai/glossar/software-application-schema.md) — SoftwareApplication ist der Schema.org-Typ für Software-Produkte aller Art — Webapps, Mobile Apps, Desktop-Software — und enthält Properties wie applicationCategory, operatingSystem, offers für Pricing-Information. - [Strukturierte Daten](https://www.geoquality.ai/glossar/structured-data.md) — Strukturierte Daten sind maschinenlesbare Auszeichnungen von Web-Inhalten — typischerweise als JSON-LD im HTML-Head — die Entitäten, Beziehungen und Metadaten explizit benennen statt sie nur implizit im Fliesstext zu hinterlassen. ## Quelle und Zitation - HTML-Original: https://www.geoquality.ai/glossar/aggregate-rating - Lizenz: CC BY 4.0 - Zitiervorschlag: "aggregateRating (geoquality.ai Glossar, Biner 2026)"