Review Schema Markup: Wann Google wirklich Sterne zeigt

Ein Café kann sein Aufsteller-Schild an der Tür mit „4,9 Sterne, 300 Bewertungen" bepinseln, so oft es will. Sobald dasselbe als Review-Schema-Markup auf der eigenen Website landet, ignoriert Google es. Nicht wegen eines Formatfehlers, sondern wegen einer Regel, die genau diesen Fall trifft: Review Schema Markup für die eigene Organisation oder das eigene Local-Business-Profil zeigt keine Sterne in der Suche, ganz gleich, wie akkurat das JSON-LD geschrieben ist. Wer verstehen will, wann Bewertungssterne tatsächlich erscheinen, muss zuerst verstehen, wann sie kategorisch nicht erscheinen.

Was ist Review-Schema-Markup?

Review-Schema-Markup ist ein JSON-LD-Block, der schema.org's Review- oder AggregateRating-Typ nutzt, um eine Bewertung maschinenlesbar zu machen: wer bewertet hat, was bewertet wurde, und wie hoch die Bewertung ausfiel. Eine Einzelbewertung sitzt im review-Feld, eine zusammengefasste Bewertung aus vielen Stimmen im aggregateRating-Feld, meist verschachtelt innerhalb des bewerteten Objekts. Ein Produkt mit einer Gesamtbewertung sieht im JSON-LD so aus:

{
  "@context": "https://schema.org",
  "@type": "SoftwareApplication",
  "name": "FlowDesk",
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.8",
    "ratingCount": "512"
  }
}

ratingValue läuft standardmäßig von 1 bis 5, lässt sich aber über bestRating und worstRating auf jede andere Skala umstellen – Google akzeptiert dafür laut eigener Dokumentation auch Brüche oder Prozentwerte wie 6 / 10 oder 60%. Bei AggregateRating reicht laut derselben Doku eines der beiden Felder ratingCount oder reviewCount, nicht zwingend beide. Beide Objekttypen, Review und AggregateRating, unterliegen derselben Einschränkung, um die es in diesem Artikel eigentlich geht: nicht jeder Typ, der bewertet werden kann, darf dafür auch Sterne in der Suche zeigen.

Die Verschachtelung selbst ist dabei nichts Review-Spezifisches. Genau wie im Event-Schema-Markup steckt der Löwenanteil der Struktur in einem einzigen eingebetteten Objekt, hier aggregateRating statt location. Wer das Prinzip einmal an einem Typ verstanden hat, erkennt es bei jedem anderen schema.org-Typ wieder.

Welche Typen dürfen Sterne zeigen – und welche nicht?

Genau hier liegt der Punkt, an dem die meisten Anleitungen zu grob werden. Google verbietet nicht „Review-Schema für Unternehmen" pauschal. Verboten ist etwas Präziseres: Bewertungen, bei denen die bewertete Entität die Bewertungen selbst kontrolliert, auf LocalBusiness- oder Organization-Typen. Das trifft dein eigenes Firmenprofil auf deiner eigenen Website, es trifft aber nicht das Produkt, das du auf derselben Website verkaufst – derselbe Shop, dieselbe Domain, zwei völlig unterschiedliche Ergebnisse, je nachdem, welches Objekt die Bewertung trägt.

Der SchemaValid Review-Schema-Generator bietet deshalb bewusst nur die obere Hälfte dieser Tabelle an: Product, SoftwareApplication, Book, Course, Event und Recipe. Kein technischer Zufall, sondern die direkte Umsetzung dessen, was Google überhaupt stern-fähig macht. Wer sein Produkt ohnehin schon mit dem Product-Schema-Generator ausgezeichnet hat, ergänzt die Bewertung einfach im selben Objekt, statt ein zweites, unabhängiges Markup zu pflegen.

Der Hintergrund dieser Trennung ist kein Formalismus. Lokale Unternehmen sammelten über Jahre Kundenlob in eigenen Widgets und markierten sich damit selbst mit fünf Sternen, ohne dass eine unabhängige Instanz die Bewertungen kuratierte. Ein Produkt, das über einen Marktplatz oder eine unabhängige Bewertungsplattform läuft, hat dieses Kontrollproblem strukturell seltener. Die Person, die kauft, ist selten dieselbe wie die Person, die das Produktschema pflegt. Deshalb zieht Google die Grenze nicht am Inhalt der Bewertung, sondern an der Frage, wer über sie bestimmt. Anatomisch bleibt das bewertete Objekt dabei überschaubar, egal wie viele Bewertungen dahinterstehen:

Die Anatomie bleibt für jeden erlaubten Typ identisch, itemReviewed tauscht nur das @type. Genau diese Schlichtheit macht die eigentliche Hürde umso auffälliger: Kein Feld in diesem Block verrät, ob eine Bewertung self-serving ist oder nicht. Die Antwort steht nirgends im JSON, sie hängt komplett davon ab, wer die bewertete Entität ist und wer die Kontrolle über die Bewertungen hat – eine Unterscheidung, die sich nicht validieren lässt, sondern nur verstehen.

Was Google wörtlich verbietet

Die Regel selbst steht recht unscheinbar mitten in einer längeren Dokumentationsseite, zwischen Feldbeschreibungen und Codebeispielen – wer nur die Pflichtfeld-Tabelle überfliegt, liest glatt daran vorbei. Im Wortlaut liest sie sich so:

Am 24. Juli 2026 hat Google dieselbe Dokumentation um eine zweite, unabhängige Verbotszeile erweitert, berichtet von mehreren SEO-Fachmedien am folgenden Montag (Search Engine Journal, 27.07.2026): „Don't include fake or undisclosed incentivized reviews on your page or in your structured data markup." Gemeint sind Bewertungen, die nicht auf einer echten Nutzung beruhen, oder Bewertungen, die im Tausch gegen Geld, Rabatte oder Gratisprodukte entstanden sind, ohne das offenzulegen.

Wer die Self-Serving-Regel für unnötig pedantisch hält, übersieht das eigentliche Problem, das sie löst. Ohne diese Grenze könnte jedes Unternehmen sich selbst zur Bestnote erklären. Das Signal wäre wertlos, für Nutzer wie für Google gleichermaßen. Die Regel ist streng, aber sie zielt auf genau den Fall, in dem ein Sternebewertungssystem sonst am schnellsten kaputtgeht: wenn der Bewertete gleichzeitig der Türsteher der Bewertungen ist. Zwei getrennte Regeln, ein gemeinsamer Nenner: Google will Sterne, die etwas Reales abbilden, keine, die nur gut aussehen sollen.

Pflichtfelder für Review und AggregateRating

Wer die Tabelle oben verinnerlicht hat, braucht als Nächstes nur noch die Feldliste, keine Ratespiele mehr über Reihenfolge oder Verschachtelung.

Die 100-Zeichen-Grenze bei author steht wörtlich in Googles Review-Snippet-Doku (Stand 08.09.2026): Ist der Name länger, verliert die Seite die Berechtigung fürs autorenbasierte Review-Snippet. In der Praxis betrifft das selten Einzelpersonen, häufiger einen automatisch zusammengesetzten Firmennamen mit vollständiger Rechtsform und Zusatz.

Fehlt itemReviewed, weil das Review-Objekt eigenständig irgendwo auf der Seite steht, statt im bewerteten Objekt verschachtelt zu sein, wertet Google das Markup gar nicht erst aus. Das ist der mit Abstand häufigste technische Fehler, noch vor den inhaltlichen Verstößen der Self-Serving-Regel. Am schnellsten findest du eine solche Lücke mit dem Schema Validator, der fehlende Pflichtfelder einzeln auflistet, statt nur eine allgemeine Fehlermeldung zu zeigen.

Häufige Fehler und was ein Manual Action wirklich bedeutet

Ein typisches Beispiel wäre ein Softwareanbieter, der auf seiner Startseite unter dem eigenen Firmennamen (Organization) eine Gesamtbewertung von 4,9 Sternen einbindet, gesammelt aus Trustpilot-Bewertungen per Widget. Technisch valides JSON-LD, trotzdem keine Sterne in der Suche – die Bewertung betrifft die Organisation selbst, und die Organisation kontrolliert, welche Bewertungen im Widget landen. Sterne bleiben aus. Derselbe Anbieter kann dieselben Bewertungen ohne Weiteres unter seinem Produkt (SoftwareApplication) markieren und bekommt dort ein völlig anderes Ergebnis.

Ein zweiter, unabhängiger Stolperstein: Googles allgemeine Richtlinien zu strukturierten Daten (Stand 10.07.2026) verlangen zusätzlich, dass markierte Inhalte für Lesende der Seite tatsächlich sichtbar sind. Ein Rating, das nur im JSON-LD existiert und nirgendwo im sichtbaren Text auftaucht, verstößt unabhängig von der Self-Serving-Frage gegen diese Grundregel.

Verstößt eine Seite gegen die Richtlinien, kann Google laut eigener Doku ein manuelles Verfahren einleiten. Praktisch bedeutet das laut Search-Console-Hilfe zu Manual Actions (fortlaufend gepflegte Hilfeseite, kein festes Versionsdatum, live geprüft am 21.09.2026): Die strukturierten Daten der betroffenen Seite werden ignoriert, das Rich-Result verschwindet.

Wer sein Review-Markup nicht von Hand tippen will, baut es mit dem SchemaValid Review-Schema-Generator: Typ wählen, Bewertung eintragen, JSON-LD kopieren – ohne Konto, ohne dass die eingegebenen Daten den Browser verlassen.

Häufige Fragen zu Review Schema Markup