Review Schema: How to Get Star Ratings in Search and AI
Review schema only earns stars when the markup, the page and the review source agree. What makes a page eligible, what disqualifies it, and how to check.
Review snippet eligibility is defined as the condition in which a page may be shown with a star rating, requiring that the marked-up reviews describe one specific item, that the same rating is visible to a visitor, and that the business did not supply the reviews about itself. Review schema fails far more often on those rules than on syntax, which is why a page can validate cleanly and still earn nothing. Products with reviews convert materially better than products without them [Spiegel Research Center, 2017], so the stars are worth the hour it takes to get right. This guide covers what qualifies a page, what disqualifies it, and how to verify the two ratings agree.
- Attach the rating to a specific item, never to your organisation or brand page.
- Render the same rating visibly on the page, because unsupported markup is discounted.
- State the rating value, the count and the best rating on every aggregate.
- Remove self-supplied reviews: they disqualify the snippet rather than weaken it.
- Test the rendered production page, since widgets inject stars after the markup.
- Compare the marked-up rating with the visible one product by product, every quarter.
Omniconvert has measured how product evidence is published across the CROBenchmark dataset of 7,000+ websites in 15+ industries, against 248+ audit criteria, over 13 years in eCommerce [CROBenchmark Report 2026, Omniconvert]. Reviews are near-universal on product pages in that set, and correctly scoped review markup is not, which is the gap this guide is about.
What review schema actually does
The distinction matters because it sets expectations correctly. Markup is a translation layer. It takes facts that already exist on the page, the rating, the count, the dates and the authors, and states them in a form that does not depend on how your review widget happens to render.
That translation buys two things. In search it makes a page eligible for a review snippet, which is the star rating in the result. In an answer engine it makes the rating unambiguous rather than something to be inferred from markup the engine may never execute.
What it does not buy is a better rating. A thin review profile described accurately is still thin, so this work sits downstream of how to build a Review-Generation system that runs without anyone remembering to launch it.
The eligibility gate, and why valid markup still fails
The first rule is that the rating must describe a specific item. A rating attached to your company, your brand or your homepage is not a product rating, and the review snippet exists to describe things rather than organisations. This is the single most common reason a carefully built implementation produces nothing.
The second rule is that the rating has to be visible on the same page. Markup is a description of page content, not an addition to it, so a rating that exists only in the structured data is unsupported. The subtle version of this failure is a rating that is visible but different, which happens whenever a widget aggregates a slightly different review set from the one feeding the markup.
The third rule is that the reviews cannot be supplied by the business about itself. A testimonial you collected and published about your own company is marketing copy, and treating it as an independent rating is exactly what the rule exists to prevent. Google's review snippet documentation sets out the current eligible types and the self-serving restriction, and it is worth reading rather than inferring, because the eligible set has changed more than once.
The version of this that wastes the most time: a brand puts an aggregate of every review it has ever collected on its homepage, marks it up against the Organization, validates it, sees no stars, and spends a sprint rewriting the JSON. The markup was correct the entire time and the page was never eligible, because an organisation is not an item with a rating.
The fields that have to be there
| Field | Where it sits | What breaks without it |
|---|---|---|
| Rating value | Aggregate | No snippet at all |
| Review or rating count | Aggregate | Snippet suppressed as incomplete |
| Best rating | Aggregate | Scale is assumed, sometimes wrongly |
| Author | Each review | Review reads as unattributed |
| Date published | Each review | Nothing can be placed in time |
| Item reviewed | Each review | Rating cannot be tied to the product |
The date field is the one worth arguing about internally. It is easy to omit, no validator insists on it in every configuration, and it is the field that decides whether your review evidence can be read as current. A review nobody can date is evidence about an unknown moment.
An aggregate rating is defined as a single summary value standing for a set of individual reviews about one item, which is why mixing variants, bundles or regional listings into one aggregate quietly misstates what the number describes. Keep the aggregate aligned to the item the page is about.
Where this intersects with AI answers
An engine assembling an answer about a product needs three things it can state: what the rating is, how many reviews it rests on, and when they were written. Structured data supplies all three without the engine executing your review widget, which is the practical argument for doing this work beyond the stars.
The limit is worth being honest about. Correct markup around forty-month-old reviews describes an old rating accurately. The underlying evidence problem is unchanged, and the same logic that governs independent corroboration in the GEO playbook for eCommerce applies here: a source describing itself is weaker than a source describing someone else.
AliveCor used Omniconvert to run a structured A/B testing programme and achieved +21% conversion rate, +5% revenue per visitor, and 94% statistical relevance across their experiments. [Omniconvert, AliveCor case study] The same discipline applies to a schema change: ship it on one template, compare the before and after on that template only, and do not read a single week as a result.
How to verify it actually works
The check itself is simple. Open a live product page, read the rating a visitor sees, then read the rating in the page's structured data. They should be identical. Do it for a hero product, a long-tail product, a product with one review and a product with none, because each of those exposes a different defect.
Three failures show up reliably. A cached aggregate that no longer matches the widget, a variant page carrying the parent's rating, and a zero-review product carrying a template default, which is the one that costs credibility rather than a snippet.
Shopify's own product-data guidance asks for complete, consistently structured records across sales channels, and review records sit inside that advice, so check what your theme and your widget actually emit rather than what either promises.
Validate the syntax too, with the standard structured data testing tools and the vocabulary reference at schema.org's AggregateRating type. Just do not stop there, because syntax is the layer that is almost never the problem.
What to do this week
- Check what the rating is attached to. If it is your organisation or your brand page, move it to the product. That is the whole fix in a surprising number of cases.
- Compare visible against marked-up, on four products. Hero, long tail, one review, no reviews. Note every mismatch.
- Add the missing dates. Author and date published on every individual review, so the evidence can be placed in time. The conversion case for doing this properly is in how reviews affect conversion.
- Remove the self-supplied ratings. Testimonials about your company are not product reviews, and keeping them in the markup risks the snippet on pages that would otherwise qualify. If you want to see how your review profile reads against the category, you can benchmark your reviews directly.
None of this needs a new platform, and all of it works on whatever review system you already run. The layer worth adding later is interpretation rather than markup: Brandfeel, Omniconvert's sentiment-intelligence layer, aggregates reviews, NPS and support-ticket themes so a shift in what customers say surfaces as a theme rather than as a slow drift in an average. Downstream of that, Omniconvert Commander (formerly Nexus) is an AI for eCommerce growth engine that unifies commerce data, prioritises experiments by True Profit, and generates campaigns and creative you approve before they go live.
One last caution on scope. Roughly 70% of carts are abandoned [Baymard Institute, 2025], and a star rating in a search result does nothing about the specifics a shopper gives up looking for on the page itself. Fix the markup because it is cheap and because it stops systems guessing, then spend the rest of the quarter on the review content behind it.
The counterpart to this is review recency, and why it matters.
Frequently asked questions
Why does our review schema not produce stars?
Almost always because of an eligibility rule rather than a syntax error. The three common causes are marking the rating against the organisation rather than against a specific item, a rating that exists in the markup but is not visible on the page, and reviews the business supplied about itself. Valid markup that breaks one of those rules validates cleanly and still earns nothing.
Which schema types can show a review snippet?
Only a defined set, and Product is the one that matters for a store. A rating attached to an Organization or to a brand page is outside that set, which is why a homepage carrying an aggregate of all your reviews never produces stars no matter how well formed it is. Check the current list in the search engine documentation rather than assuming, because the set has changed before.
Do we need every individual review in the markup?
No, and including hundreds is usually counterproductive for page weight. What matters is a correct aggregate rating, with the value, the count and the best rating stated, plus a reasonable sample of individual reviews carrying an author and a date. The aggregate is what drives the snippet; the individual reviews supply the evidence behind it.
Does review markup help with AI answers as well as search?
It helps as a parsing aid rather than as a ranking factor. Marked-up reviews make the rating, the count and the dates unambiguous, so a system reading the page does not have to infer them from a widget it may not render. The review text itself still carries the weight, and markup around thin or dated review content does not improve the claim it supports.
Can a review widget break the markup?
Frequently, and it is the most common reason a correct implementation stops working. Many widgets render the visible stars with a script after the page loads and emit their own markup at the same time, which can produce two competing ratings or a rating with nothing visible to support it. Test the rendered production page, not the template.
What should we check first?
Whether the rating in the markup matches the rating a visitor sees on the same page, product by product. That single comparison catches the majority of real-world failures, including stale caches, widgets aggregating a different set of reviews, and templates that carry a rating for a product variant nobody is looking at.
The one comparison to run
Before touching any code, check what your rating is attached to and whether the number in your markup matches the number on the page. Those two questions account for most review schema that validates and earns nothing, and both are answerable in an afternoon without a developer.
Then add the dates. A rating a system can place in time is worth more than a rating it has to take on trust, and dates are the field most implementations skip.