
Review schema markup is JSON-LD built from schema.org's Review and AggregateRating types that tells Google a page carries a genuine rating, so an eligible page can show a star snippet in search results. Add a Review block to mark up one specific review, an AggregateRating block once you have enough reviews to summarize into a score, or both together, and follow Google's eligibility rules or the rich result simply will not show.
Review schema markup is structured data, almost always written as JSON-LD, that describes a review or a rating using schema.org's vocabulary so search engines can read it as data rather than plain text. The two working parts are the Review type, for one specific review, and the AggregateRating type, for a summarized score across many reviews. Both nest inside a parent item, most often Product, using the review and aggregateRating properties, though the standalone item can carry its own name too.
The payoff for getting it right is visual: a listing with stars, a numeric score, and a review count sitting under the title in Google's results, ahead of any competitor without it. The payoff for getting it wrong, especially on the wrong page type, is a manual action for structured data spam rather than a rich result, which is why the rules matter more here than for most other schema types.
Review describes a single review: who wrote it, what score they gave, and what they said. AggregateRating describes the summary: an average ratingValue calculated from a reviewCount of individual ratings. Schema.org's own documentation draws the line this way: reviewRating applies to the rating given inside one review, while aggregateRating applies to the item being reviewed as a whole, treating the collection of reviews as a single creative work.
In practice you rarely need to choose only one. A product page might feature one detailed Review from a standout customer while also carrying an AggregateRating built from every rating the product has received. Google's Rich Results Test will happily show a preview for either type alone, or both together, as long as the required properties are present and the numbers genuinely reflect content on the page.
Google grants the star snippet to reviews nested in item types like Product, Book, Course, Recipe, Movie, Event, Game, and SoftwareApplication without restriction, but LocalBusiness, Organization, and Service only qualify when the reviews are not self-serving. Google Search Central lists the full set of eligible parent types, and for the three restricted ones it draws a hard line: if the entity being reviewed controls or collects the reviews about itself, those pages are ineligible for the star result, no matter how correct the code is.
That single distinction explains most of the confusion around this schema. A software company can mark up reviews of its own product and expect stars. A dentist's office cannot mark up testimonials on its own homepage and expect the same, because a LocalBusiness reviewing itself is exactly the self-serving pattern Google excludes.
Google will not show the star rich result for LocalBusiness, Organization, or Service pages when the business being reviewed controls or collects those reviews itself, a restriction BrightLocal traces to a 2019 guideline update that Google has enforced ever since. The rule applies whether the reviews are typed directly into your HTML or pulled in through a third-party widget embedded on your own domain; what matters is who controls the collection, not the delivery method.
Google's policy has only tightened since. Its structured data documentation, last updated July 24, 2026, adds a second layer on top of the self-serving rule: fake reviews and undisclosed incentivized reviews are banned from both the visible page and the structured data, whatever the item type. Disclosed incentivized reviews, where a reader can plainly see that a discount or gift prompted the review, are still allowed.
Building the JSON-LD is mechanical once you know which properties each type actually requires. Follow this order and you avoid the two mistakes that cause most rejections: missing a required property, and marking up a rating that is not genuinely visible on the page.
author, reviewRating.ratingValue, and ideally datePublished and reviewBody.ratingValue and either reviewCount or ratingCount, adding bestRating if your scale is not 1 to 5.review and aggregateRating properties, or use them standalone with their own itemReviewed reference.type="application/ld+json" to the page, then run the URL through Google's Rich Results Test before you consider it done.For a Product page carrying one featured review alongside an overall score, the JSON-LD looks like this:
{
"@context": "https://schema.org",
"@type": "Product",
"name": "Aria Standing Desk",
"review": {
"@type": "Review",
"author": { "@type": "Person", "name": "Jordan T." },
"datePublished": "2026-07-14",
"reviewRating": {
"@type": "Rating",
"ratingValue": "5",
"bestRating": "5"
},
"reviewBody": "Motor is quiet and it held steady at standing height through six months of daily use."
},
"aggregateRating": {
"@type": "AggregateRating",
"ratingValue": "4.7",
"reviewCount": "184",
"bestRating": "5"
}
}Writing this by hand for every product on a large catalog gets tedious fast, and a mistyped field is easy to miss. Rankite's free Review Schema Generator builds both blocks from a short form, keeps the rating scale consistent between them, and warns you the moment you pick a restricted type like LocalBusiness or Service.
A third option worth understanding is the review widget many platforms offer, where a service like Trustpilot or Yelp hosts and verifies the reviews, then embeds them on your page. It behaves differently from writing your own schema, and the table below lays out where each approach fits.
| Aspect | Review | AggregateRating | Third-party widget |
|---|---|---|---|
| What it shows | One specific review's text and rating | An averaged score across many reviews | Reviews collected and verified by the platform |
| Where the data lives | Written and hosted on your own page | Calculated from reviews on your own page | Stored on the third party's servers, embedded via script |
| Minimum required fields | author, reviewRating.ratingValue | ratingValue, reviewCount or ratingCount | None you control; the platform emits its own schema |
| Self-serving risk | High on LocalBusiness, Organization, Service | High on LocalBusiness, Organization, Service | Low, since a neutral third party controls collection |
| Best use case | Featuring one strong, specific testimonial | Summarizing overall satisfaction at scale | Local businesses that cannot self-publish star-eligible reviews |
That last row is the practical answer for most local businesses: since a dentist's office or law firm cannot make its own testimonials star-eligible, a legitimate third-party review platform is often the only realistic path to a star rich result at all. Our breakdown of whether Google reviews help SEO covers how those platform reviews factor into local rankings even without your own Review schema in the mix.
Most rejected review markup fails for one of a handful of repeat reasons, not obscure edge cases:
Paste the page URL or the raw JSON-LD into Google's Rich Results Test to see whether Google detects the Review or AggregateRating block and marks it eligible, has warnings, or invalid. A green eligible result with a rating preview means the code and the page both meet Google's bar; a warning usually points to a missing recommended property like bestRating, while an error means a required field is absent entirely.
Run the check again after any content change, since a rating that used to be visible on the page but got removed in a redesign will make previously valid schema fail the self-serving and visibility checks even though the JSON-LD itself has not changed. Our full walkthrough on how to check schema markup covers the Rich Results Test, the Schema Markup Validator, and Search Console's Enhancements report together, useful once review schema is one of several types on a page. For a fast syntax pass before you get that far, Rankite's free JSON-LD Schema Checker catches malformed code in seconds.
If you sell a product, offer a course, or run any item type Google treats as star-eligible, start with genuine reviews already on the page, add AggregateRating once you have enough of them to summarize honestly, and test the result before you consider it live. If you run a LocalBusiness, Organization, or Service page, accept that your own testimonials will not earn stars and lean on a third-party review platform instead. For ecommerce catalogs specifically, our guide to schema markup for ecommerce covers Product and Offer schema alongside Review and AggregateRating together. And if you are not sure your existing markup on WordPress is even in the page's HTML, our guide to adding schema markup in WordPress walks through the plugin and manual routes, or talk to Rankite about a full schema markup service if you would rather have it audited and implemented for you.
Get a free, no-obligation SEO audit and a 30-minute strategy session. We'll show you exactly where the growth is hiding.
Fill out the form and we'll get back to you within one business day. Prefer email? Write to us directly at contact@rankite.com.