Product Review Schema: Fixing Review Markup and Display

Review and AggregateRating are different things

Two schema.org types describe reviews, and product pages usually need both. Mixing them up is behind a large share of the review problems the Ecommerce Audit reports.

A shop with 300 reviews of a kettle should not put 300 Review objects in its markup. Mark up the reviews that are visible when the page first loads, usually the first five to ten, and let the AggregateRating carry the total. That keeps the markup honest about what is on the page and keeps the block a sensible size.

Technical errors inside the summary rating, such as a missing count, a score outside the scale or a decimal comma, are covered in Fixing aggregateRating errors. The price, offer and identifier side of the same Product block is in Fixing Product schema errors. This guide deals with the reviews themselves: where they come from, whether they may be marked up, and how they reach the page.

What a single Review needs

Google's review snippet documentation asks for a small set of fields on each Review. Most failures are not missing fields but fields filled with the wrong thing.

• author: a Person or Organization with a name. Use the display name shown beside the review on the page, such as "Priya S." for a fictional customer. Badges like "Verified Buyer", placeholder text like "Customer", and anything promotional are not names.
• reviewRating: a Rating with ratingValue, plus bestRating if your scale is not 1 to 5.
• datePublished: the date the review was written, in ISO 8601 format such as 2026-08-14. Recommended rather than required, but review apps nearly always have it and it helps show the reviews are current.
• reviewBody: the text of the review as shown. Keep any shortening consistent with what the page displays.
• itemReviewed: only needed when the Review stands on its own rather than sitting inside the Product. Nested inside a Product, the parent is the item reviewed.

A product with its first reviews marked up

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Product",
  "@id": "https://example.co.uk/products/enamel-camping-kettle#product",
  "name": "Enamel camping kettle, 1.2 litre",
  "image": "https://example.co.uk/images/enamel-kettle.jpg",
  "sku": "FFK-12",
  "brand": { "@type": "Brand", "name": "Fernfold" },
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.6",
    "reviewCount": "58"
  },
  "review": [
    {
      "@type": "Review",
      "author": { "@type": "Person", "name": "Priya S." },
      "datePublished": "2026-08-14",
      "reviewRating": { "@type": "Rating", "ratingValue": "5" },
      "reviewBody": "Boils quickly on a small gas stove and the handle stays cool enough to hold."
    },
    {
      "@type": "Review",
      "author": { "@type": "Person", "name": "Tom W." },
      "datePublished": "2026-07-30",
      "reviewRating": { "@type": "Rating", "ratingValue": "4" },
      "reviewBody": "Solid kettle. The enamel chipped slightly on the base after a month of use."
    }
  ]
}
</script>

The offer is left out of this example to keep the review part readable; on a live shop page the same block carries the offer as well.

Pros and cons are not for shop pages

Schema.org has positiveNotes and negativeNotes for listing pros and cons, and Google can show them in results. Google's documentation limits that appearance to editorial product review pages, such as a magazine testing kettles, and says merchant product pages and customer reviews are not eligible. Adding pros and cons markup to your own product pages will not produce the feature, so it is not worth the effort.

Reviews that only exist inside a widget

Most shops collect reviews through an app: Judge.me, Yotpo, Reviews.io, Trustpilot product reviews, Okendo, Stamped or a platform's own reviews. How that app puts reviews on the page decides whether search engines see them at all.

To see which case you have, open the product page, press Ctrl+U (Cmd+Option+U on a Mac) and search the raw source for a phrase from one of the visible reviews. If it is missing, the reviews arrive later by script. Then run the URL through the Rich Results Test and open the rendered HTML: if the phrase appears there but not in the source, Google can probably read it after rendering, but other crawlers, including many AI assistants that fetch pages without running scripts, will not.

Store reviews, product reviews and whose opinion it is

Review platforms usually collect two kinds of feedback. Product reviews are about the item: fit, quality, how it performs. Store or service reviews are about the shop: delivery speed, packaging, customer service. Many shops show a store badge, such as "4.8 from 2,000 reviews", near the basket button on every product page.

That store score must not be marked up as the product's rating. It does not describe the kettle, the same number appears on every product, and the reviews behind it are about your business rather than about the item. Google does not show review stars where a business marks up reviews about itself on its own site, and a shop rating copied onto every Product is exactly that situation dressed up as product data. The aggregateRating guide sets out that policy in full; the practical point for a shop is to keep the store badge as a visual element only.

Reviews gathered by a review platform

Collecting product reviews through a third-party platform is normal. What matters is that the reviews are genuine customer opinions of that specific product, that they are shown on the product page, and that the markup describes those displayed reviews. What goes wrong is copying in figures that belong elsewhere: an average from a marketplace listing, a rating from a comparison site, or a manufacturer's global score that includes reviews from other retailers you do not display.

Reviews shared across variants and bundles

If a jumper in six colours has one page, pooling reviews across the colours is reasonable, because the page is about the jumper. If each colour has its own indexable page, showing the same pooled reviews on all six is common and acceptable when the page says so, but be consistent: the markup on each page should describe the reviews that page shows. For a bundle, do not borrow the ratings of the individual items unless the page makes clear which product each review is about.

Diagnosing why stars are missing

Work through these in order. Each rules out a cause before you spend time on the next.

1. Are the reviews in the page? Search the raw source and the rendered HTML for a phrase from a visible review. If they are in neither, no markup fix will help until the widget problem is solved.
2. Is there review markup at all? In the source, search for "Review" and aggregateRating. Some apps output review text visibly but no structured data unless an SEO or "rich snippets" option is switched on in their settings.
3. How many blocks describe the product? Count the "@type": "Product" matches. Two or three Products, each with a different rating, is a common result of a theme, an SEO plugin and a review app all adding markup.
4. Is the rating attached to the product? A rating on the Organization, the WebPage or a free-floating Review with no itemReviewed will not produce product stars.
5. Do the numbers match the page? Compare the average and count in the markup with the figures near the product name, and each marked-up review with what a shopper can read.
6. Does the Rich Results Test show a Review snippet or Product snippet? Valid items with no errors mean the page is eligible. If stars still do not appear after a recrawl, Google has chosen not to show them for that query, which it does for many eligible pages.

Where review markup comes from on each platform

Shopify

Themes often output a Product block with an aggregateRating read from the review app's metafields, and many review apps add their own block too. Decide which one owns the review markup: usually the app, since it has the individual reviews. Then remove the rating lines from the theme's block, or turn off the app's markup and let the theme print both summary and reviews from the metafields. Do not leave both on.

WooCommerce

WooCommerce stores product reviews as WordPress comments and its built-in structured data includes the rating and recent reviews when reviews are enabled. SEO plugins such as Yoast (with its WooCommerce add-on) or Rank Math can take over the Product markup, and external review plugins may add another layer. Check which plugin outputs each Review and keep one source. The setting that limits reviews to verified owners, under WooCommerce, Settings, Products, helps show reviews come from real buyers.

Headless and custom builds

Nothing is automatic. Fetch reviews from the review provider's API on the server, render the first set into the HTML, and build the Review objects from the same data. Cache sensibly, but refresh often enough that a new review does not leave the markup and the page disagreeing for days.

The fix, step by step

Keeping review markup healthy

• One owner. Write down which app or template produces review markup, so a new plugin or theme update that adds a second source is spotted quickly.
• Same data, same moment. Build the visible reviews and the markup from the same source so they can never drift apart.
• Handle zero reviews. Products with no reviews yet should output no review markup at all, rather than an empty rating.
• Collect reviews properly. Ask every buyer, not only happy ones, publish critical reviews as well as positive ones, and label any incentivised reviews clearly.
• Recheck after changes. Review app updates, theme changes and switches between review providers are when review markup most often breaks or doubles up.

For the wider picture of product page quality, see product review trust signals, and the Ecommerce SEO Guide for how reviews fit alongside the rest of the audit.