Review & Aggregate Rating Schema for Ecommerce: Get Stars in Search Results

1. Review vs AggregateRating: Which Schema Type Triggers Stars

Google displays star ratings in search results based on AggregateRating schema, not individual Review schema. That distinction matters because I audit stores every week where the developer marked up 200 individual reviews per product page and none of them show stars in search. The AggregateRating type is what carries the summary - the average score and total count - and that summary is what Google renders as the yellow stars beneath your search listing.

The Review type in Schema.org represents a single evaluation by one person. It contains a rating (a number from 1 to 5), an author name, a date, and optionally a review body. The AggregateRating type represents the statistical summary of all reviews: the average ratingValue, the ratingCount (how many ratings), and the reviewCount (how many written reviews). Google uses AggregateRating to populate the "4.6 ★ (312 reviews)" line in search results.

You can include both types on a product page, and you should. Nest the AggregateRating and an array of Review objects inside a single Product schema block. The AggregateRating triggers the stars. The individual Review items give Google additional content to potentially display in the review snippet and help validate that the aggregate numbers are backed by real review content. For the full picture of how Review schema fits alongside other structured data types for ecommerce, our ecommerce schema markup guide covers every schema type from Product to BreadcrumbList.

One mistake I see frequently: stores that only mark up individual Review objects without any AggregateRating. Google can technically calculate an aggregate from individual reviews, but it rarely does. Always include an explicit AggregateRating property on your Product schema. Do not rely on Google to do the math.

2. Google's Self-Serving Review Policy and What It Means for Your Store

Google updated their review snippet guidelines in 2023 with a specific warning about self-serving reviews. A self-serving review is any review where the entity being reviewed controls the review content. If your store writes its own product reviews and marks them up with Review schema, that is self-serving.

If your marketing team creates "editorial reviews" of your own products and adds structured data, that is also self-serving. Google can issue a manual action that strips your rich results entirely.

The policy extends beyond fabricated reviews. Selectively curating only 5-star reviews in your structured data while hiding negative reviews on the page also violates the spirit of the guidelines. Google's documentation states that the AggregateRating in your structured data must accurately reflect the reviews visible on the page.

If your page shows 312 reviews with a 4.3 average, your AggregateRating schema must say 4.3 with 312 reviews. Inflating the ratingValue or undercounting negative reviews in the schema is a manipulation that Google's review systems are built to detect.

The safest path is using a third-party review platform: Yotpo, Judge.me, Stamped, Bazaarvoice, or Trustpilot. These platforms inject schema markup automatically, and because the reviews are collected and hosted by an independent third party, Google treats them as more trustworthy. Judge.me generates the JSON-LD server-side and includes it in the page HTML by default. Yotpo adds the schema through their widget JavaScript, though I recommend configuring Yotpo to output the schema server-side for faster Googlebot processing.

If you collect reviews natively without a third-party platform, you can still mark them up. Each review needs a verifiable author name, a date, and must represent a genuine purchase. Display both positive and negative reviews on the page.

Make the review submission process open to all verified buyers, not gated behind satisfaction surveys that filter out unhappy customers. Google cannot always detect gating, but their algorithms get better at identifying stores with suspiciously uniform 5-star ratings.

3. The Combined JSON-LD Block: Product + AggregateRating + Review

The correct structure nests AggregateRating and Review inside the Product object as properties. Do not create three separate JSON-LD script tags for Product, AggregateRating, and Review. Google explicitly recommends connecting them in a single block so the relationship between the product and its ratings is unambiguous.

Here is the complete JSON-LD structure I use on product pages. Every property in this example is one that Google documents as either required or recommended for the Product with review rich result.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Wireless Noise-Cancelling Headphones Pro",
  "image": [
    "https://example.com/photos/headphones-front.jpg",
    "https://example.com/photos/headphones-side.jpg",
    "https://example.com/photos/headphones-case.jpg"
  ],
  "description": "Over-ear wireless headphones with 40dB active noise cancellation, 30-hour battery life, and multipoint Bluetooth 5.3 connectivity.",
  "sku": "WNC-PRO-2026",
  "mpn": "WNC-PRO-2026-BLK",
  "brand": {
    "@type": "Brand",
    "name": "AudioTech"
  },
  "offers": {
    "@type": "Offer",
    "url": "https://example.com/products/wireless-nc-headphones-pro",
    "priceCurrency": "USD",
    "price": "249.99",
    "priceValidUntil": "2026-12-31",
    "availability": "https://schema.org/InStock",
    "itemCondition": "https://schema.org/NewCondition",
    "seller": {
      "@type": "Organization",
      "name": "AudioTech Official Store"
    }
  },
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.6",
    "bestRating": "5",
    "worstRating": "1",
    "ratingCount": "312",
    "reviewCount": "287"
  },
  "review": [
    {
      "@type": "Review",
      "author": {
        "@type": "Person",
        "name": "Sarah K."
      },
      "datePublished": "2026-01-15",
      "reviewBody": "Best noise cancellation I have used. The 30-hour battery easily lasts a full week of commuting. Sound quality is flat and accurate, which I prefer over bass-heavy tuning.",
      "reviewRating": {
        "@type": "Rating",
        "ratingValue": "5",
        "bestRating": "5",
        "worstRating": "1"
      }
    },
    {
      "@type": "Review",
      "author": {
        "@type": "Person",
        "name": "Marcus T."
      },
      "datePublished": "2026-01-08",
      "reviewBody": "Solid headphones but the ear cushions get warm after 2 hours. ANC is excellent and the multipoint connection between my laptop and phone works without manual switching.",
      "reviewRating": {
        "@type": "Rating",
        "ratingValue": "4",
        "bestRating": "5",
        "worstRating": "1"
      }
    },
    {
      "@type": "Review",
      "author": {
        "@type": "Person",
        "name": "Priya M."
      },
      "datePublished": "2025-12-22",
      "reviewBody": "Returned after a week. The headband puts too much pressure on the top of my head during long listening sessions. Sound and ANC quality are great though.",
      "reviewRating": {
        "@type": "Rating",
        "ratingValue": "2",
        "bestRating": "5",
        "worstRating": "1"
      }
    }
  ]
}
</script>

Notice three things about this structure. First, the AggregateRating is a direct property of the Product object, not a standalone schema. Second, the review array includes a mix of positive and negative reviews, which signals authenticity to Google. Third, every Review object includes both the author as a Person type and the reviewRating as a Rating type with explicit bestRating and worstRating values. Omitting bestRating defaults it to 5, but being explicit avoids ambiguity.

The distinction between ratingCount and reviewCount in AggregateRating matters. The ratingCount is the total number of ratings (including people who gave stars without writing text). The reviewCount is the number of written reviews. If your platform tracks both numbers separately, include both. If you only have one number, use ratingCount. For a broader look at how this Product schema block connects with offers, availability, and merchant feeds, the Google Merchant Center schema guide covers the feed-to-schema pipeline.

4. Individual Review Schema: When and How to Mark Up Single Reviews

You do not need to mark up every review on the page. Marking up 3-10 recent reviews is enough to give Google content to validate against your AggregateRating. Including all 500 reviews in your JSON-LD creates a massive script block that slows page parsing. On a furniture store I audited, the JSON-LD block was 847KB because the developer serialized 2,400 reviews into the schema. That single script tag added 1.2 seconds to the page's time-to-interactive.

Select a representative sample. Include your most recent reviews, and make sure the sample includes a range of ratings. If your AggregateRating is 4.3 stars, including only 5-star reviews in the Review array looks suspicious. A mix of 5-star, 4-star, and the occasional 3-star or 2-star review matches the aggregate and signals that these are genuine ratings.

Here is the structure for marking up a single review independently, which is useful when a product has exactly one review and no aggregate yet.

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Organic Rosehip Face Oil",
  "image": "https://example.com/photos/rosehip-oil.jpg",
  "brand": {
    "@type": "Brand",
    "name": "Glow Botanics"
  },
  "offers": {
    "@type": "Offer",
    "priceCurrency": "USD",
    "price": "34.00",
    "availability": "https://schema.org/InStock"
  },
  "review": {
    "@type": "Review",
    "author": {
      "@type": "Person",
      "name": "Neha R."
    },
    "datePublished": "2026-02-10",
    "reviewBody": "Absorbed quickly without leaving a greasy residue. My skin felt noticeably smoother after two weeks of daily use. The dropper dispenses the right amount each time.",
    "reviewRating": {
      "@type": "Rating",
      "ratingValue": "5",
      "bestRating": "5",
      "worstRating": "1"
    }
  }
}

When a product has only one review, use the Review property as a single object, not an array. Once you accumulate 3 or more reviews, switch to an array and add the AggregateRating property. Some developers add AggregateRating with a ratingCount of 1, which is technically valid but looks weak in search results. I hold off on the AggregateRating until there are at least 3 reviews so the displayed snippet carries credibility.

For products with zero reviews, do not add any review or rating schema. Adding AggregateRating with a ratingCount of 0 or a ratingValue of 0 is a schema error. Google will flag it in the Rich Results Test, and it violates the guideline that structured data must reflect content actually visible on the page. For how to add other value-adding structured data to product pages that do not yet have reviews, see our product page SEO guide.

5. Minimum Review Thresholds and When Stars Actually Appear

Google's official documentation states that a Product needs at least one review or rating to be eligible for the review rich result. Technically, a single review with a valid rating triggers eligibility. But eligibility and actual display are different things. Google decides whether to show the rich result based on multiple factors beyond just having valid schema.

From tracking rich result appearance across 60+ ecommerce stores over 18 months, here is what I have observed. Products with 1-2 reviews show stars roughly 30% of the time they appear in the top 10. Products with 5-10 reviews show stars about 55% of the time. Products with 20+ reviews show stars approximately 75% of the time. The correlation is not linear, and Google does not publish these thresholds. But the pattern is clear: more reviews make Google more confident in displaying the rich result.

Ranking position also matters. Rich results appear far more frequently for positions 1-5 than for positions 6-10. I have never seen a star rating display for a product page ranking below position 12. Google seems to reserve rich result real estate for pages it already considers authoritative for the query. The schema makes you eligible, but your ranking earns the display.

The practical takeaway: prioritize getting genuine reviews on your top-ranking product pages first. Adding perfect schema to a page with zero reviews produces nothing. Adding schema to a page that already has 15 reviews and ranks position 3 for a transactional keyword is where the CTR lift happens.

6. CTR Impact: What Star Ratings Actually Do to Click-Through Rates

The star rating rich result is one of the highest-impact SERP features for ecommerce because it communicates trust and social proof before the click. A plain blue link says "we sell headphones." A listing with "4.6 ★ (312 reviews)" says "312 people bought headphones from us and most of them were happy." That difference changes buyer behavior.

A 2023 Milestone Research study analyzing 4.5 million search impressions found pages with review rich results received 28% higher CTR than the same pages without stars. A separate Moz study put the range at 20-35% depending on position. My own data across client stores shows an average CTR lift of 24% for product pages ranking in positions 3-7 after star ratings began appearing.

The lift is not uniform across positions. Position 1 already captures high CTR, so adding stars improves it by roughly 12%. Positions 4-7 see the largest benefit, up to 35%, because those results are fighting for attention against multiple competitors.

Stars act as a visual differentiator that pulls clicks away from adjacent plain listings. Position 8-10 results see a smaller but still meaningful 15-20% lift.

Here is the revenue calculation for your store. Take a product page that gets 4,000 monthly impressions at position 5 with a 4.8% CTR. That is 192 clicks per month. A 24% CTR improvement brings it to 5.95% CTR and 238 clicks.

At 3% conversion rate and $65 AOV, those 46 extra clicks generate about $90 in additional monthly revenue from that single product page. Across a catalog of 300 product pages, even if only 80 earn star ratings, the cumulative impact reaches $5,000-$8,000 per month in incremental revenue. The implementation is a one-time engineering effort. The revenue impact compounds every month.

Stars also reduce the importance of ranking position. A result at position 4 with stars frequently outperforms a position 2 result without them. I tracked this on a consumer electronics store where a product page at position 4 with "4.7 ★ (89 reviews)" pulled 6.2% CTR while the position 2 result without stars received 5.8% CTR. Visual trust signals override positional advantage. For more on how structured data connects with on-page SEO factors to improve rankings and CTR, our on-page ecommerce SEO guide covers the full optimization stack.

7. Common Validation Errors in Google Rich Results Test (and How to Fix Each One)

The Google Rich Results Test at search.google.com/test/rich-results is your primary validation tool. Paste a product page URL or a JSON-LD code snippet, and it tells you whether your structured data qualifies for rich results. In my experience auditing stores, 7 out of 10 fail validation on the first test. Here are the errors I see most often and the exact fix for each.

Error: "Missing field ratingValue"

The AggregateRating type requires a ratingValue property. This error appears when the developer included the AggregateRating wrapper but forgot to populate the average rating. The fix: pull the actual average rating from your review platform's API and insert it as a string or number value.

Make sure the value falls between your worstRating and bestRating. A ratingValue of 4.6 with a bestRating of 5 and worstRating of 1 is valid. A ratingValue of 0 or a ratingValue higher than bestRating triggers this error.

Error: "Missing field reviewCount or ratingCount"

AggregateRating requires at least one of reviewCount or ratingCount. Include both when your platform provides them. If you only have one metric, use ratingCount because it is the more commonly expected property. Never set either value to 0 - that creates a logical conflict with having a ratingValue and will cause a validation error.

Error: "Missing field author" on Review

Every Review object must include an author. Google requires it as a Person or Organization type, not a plain string. The error often appears because the developer wrote "author": "Sarah K." instead of "author": {"@type": "Person", "name": "Sarah K."}. Google accepts both formats according to Schema.org, but the Rich Results Test specifically warns on plain string values. Always use the nested Person object to avoid warnings.

Warning: "Missing field bestRating"

This is a warning, not an error, but fixing it prevents ambiguity. If you omit bestRating, Google assumes a scale of 1 to 5. If your review platform uses a 1-to-10 scale and you report a ratingValue of 8 without specifying bestRating as 10, Google interprets it as 8 out of 5, which is nonsensical. Always explicitly include bestRating and worstRating on both AggregateRating and individual Rating objects.

Error: "Structured data on page does not match page content"

This is the most serious error because it can lead to a manual action. Google cross-checks your AggregateRating values against the review content visible on the page. If your schema says 4.8 stars from 500 reviews but the page shows 3.9 stars from 120 reviews, Google flags the mismatch. The fix is to generate your JSON-LD dynamically from the same data source that populates the visible review widget. Never hardcode rating values in schema markup.

// Dynamic JSON-LD generation from review data
// This ensures schema always matches page content

function generateProductSchema(product, reviews) {
  const totalRatings = reviews.length
  const avgRating = (
    reviews.reduce((sum, r) => sum + r.rating, 0) / totalRatings
  ).toFixed(1)
  const writtenReviews = reviews.filter(r => r.body && r.body.length > 0)

  return {
    "@context": "https://schema.org",
    "@type": "Product",
    "name": product.name,
    "image": product.images,
    "description": product.description,
    "sku": product.sku,
    "brand": {
      "@type": "Brand",
      "name": product.brand
    },
    "offers": {
      "@type": "Offer",
      "priceCurrency": product.currency,
      "price": product.price.toString(),
      "availability": product.inStock
        ? "https://schema.org/InStock"
        : "https://schema.org/OutOfStock"
    },
    // Only include aggregateRating when reviews exist
    ...(totalRatings > 0 && {
      "aggregateRating": {
        "@type": "AggregateRating",
        "ratingValue": avgRating,
        "bestRating": "5",
        "worstRating": "1",
        "ratingCount": totalRatings.toString(),
        "reviewCount": writtenReviews.length.toString()
      }
    }),
    // Include up to 10 most recent written reviews
    ...(writtenReviews.length > 0 && {
      "review": writtenReviews.slice(0, 10).map(r => ({
        "@type": "Review",
        "author": {
          "@type": "Person",
          "name": r.authorName
        },
        "datePublished": r.date,
        "reviewBody": r.body,
        "reviewRating": {
          "@type": "Rating",
          "ratingValue": r.rating.toString(),
          "bestRating": "5",
          "worstRating": "1"
        }
      }))
    })
  }
}

This function does two things. The schema is only generated when reviews actually exist (no empty AggregateRating errors). And the ratingValue is calculated from the same review array that populates the visible widget, which prevents the content mismatch error. Pipe this function through your server-side rendering and the JSON-LD always matches the page content.

8. Platform-Specific Implementation: Shopify, WooCommerce, and Headless

Shopify

Most Shopify themes include basic Product schema, but few include AggregateRating or Review schema by default. Your review app handles this. Judge.me, Loox, and Stamped all inject JSON-LD with review data automatically once installed. The common problem: Shopify's theme schema and the review app schema conflict. When both generate a Product schema block, you end up with two competing Product objects on the same page, and Google may read the one without reviews.

The fix is to disable the theme's built-in schema and let the review app generate the complete Product + AggregateRating + Review block. In most Shopify themes, the schema is generated in product.liquid or main-product.liquid. Search for application/ld+json in those files and wrap the entire script tag in a condition that disables it when your review app is active. Judge.me specifically has a setting to include full Product schema in its JSON-LD output - enable that and remove the theme's version.

WooCommerce

WooCommerce generates basic Product schema through its built-in structured data feature, but the review markup is minimal. If you use WooCommerce's native reviews, the schema usually includes individual Review objects but often omits AggregateRating. The Yoast WooCommerce SEO plugin adds AggregateRating to the Product schema automatically, making it the fastest fix. If you use a third-party review plugin like WP Customer Reviews or Site Reviews, check whether it outputs its own schema - and whether that schema conflicts with WooCommerce's default output.

For WooCommerce stores running custom review systems, add the schema through the woocommerce_structured_data_product filter. Hook into it, pull review data from your database, and append the aggregateRating and review properties to the Product schema array. Always validate the output with the Rich Results Test after making changes because WooCommerce's structured data system has multiple layers where plugins can override each other.

Headless (Next.js, Medusa.js, custom builds)

Headless stores have the most control and the most responsibility. No platform is generating schema for you. Build the JSON-LD as a JavaScript object in your product page component, serialize it into a script tag, and render it server-side. If you are using Next.js, place the JSON-LD in a <script type="application/ld+json"> tag inside your page's <Head> component or use a dedicated JsonLd component.

The advantage of headless is that your schema is always dynamic. Pull review data from your review API (or directly from your database if you store reviews internally), compute the aggregate on the server, and inject it into the JSON-LD before the page reaches the client. No JavaScript execution is needed for Googlebot to see your review schema. For stores using my preferred stack of Next.js + Medusa.js, the schema generation fits naturally into getServerSideProps or server components. For a deeper look at how FAQ schema and BreadcrumbList schema complement the review schema on product pages, those guides cover the additional structured data types you should pair with your Product block.

9. Review Schema Audit Checklist

Run through this checklist on your top 20 revenue-generating product pages. These are the pages where star ratings in search results have the highest dollar impact because they already get significant impressions and sit in striking distance of page-one rankings.

After fixing schema on your top 20 pages, request indexing for each URL in Google Search Console. Stars typically begin appearing within 1-3 weeks after Google recrawls the page with valid schema. Monitor the Rich Results report in Search Console to confirm that pages move from "Invalid" or "Valid with warnings" to "Valid" status.

Stars Are Free Clicks. The Schema Is the Only Barrier.

Every product page that ranks on page one without star ratings is leaving clicks on the table. The schema implementation is a one-time technical task - build the JSON-LD template, connect it to your review data source, validate it with the Rich Results Test, and deploy. The ongoing requirement is generating genuine reviews from real customers, which your business should be doing regardless of SEO.

Start with your top 20 revenue-generating product pages. Check whether they already have review schema by running them through the Rich Results Test. Fix the validation errors. Make sure AggregateRating is nested inside the Product block and dynamically generated from the same data that populates the visible review widget. Request indexing. Then watch your Search Console data over the next 3-4 weeks for CTR improvements on those URLs. The math on this is simple: 20-35% more clicks on the same impressions, from a change that takes one sprint to implement and runs forever.

If your review schema passes validation but stars still are not appearing, the issue is usually ranking position or review volume. Focus on building review count through post-purchase email sequences and on improving page authority through the on-page SEO fundamentals that push product pages into the top 5 where rich results display most frequently.