Review + Rating Schema: Implementation and Pitfalls

Review schema enables star rich results in the SERP. For ecommerce, this is one of the highest-CTR rich result types — users see stars, reviewer counts, and ratings before clicking, and click-through rates typically lift 15-35% compared to starless results.

The catch: review schema is heavily gamed, heavily policed, and heavily penalized when misused. Claiming 4.6 stars on a product you've never sold, aggregating third-party reviews as yours, or marking up reviews that aren't visible — all manual-action triggers. Google has dedicated quality systems for review-spam detection.

This article covers correct review schema implementation, the distinction between Review and AggregateRating, the misuse patterns to avoid, and the validation workflow.

Two related schema types

Review — a single review, with author, rating, review body.

AggregateRating — a summary across multiple reviews. Contains a rating value and review count.

These work together. On a product page with 127 reviews:

• AggregateRating summarizes ("4.6 stars from 127 reviews").
• Review array (5-10 individual reviews) represents specific reviews visible on the page.

Both contribute to star rich results. AggregateRating is what appears most prominently in SERPs.

AggregateRating for products

Standard implementation on a PDP:

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Nike Pegasus 41",
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.6",
    "reviewCount": "127",
    "bestRating": "5",
    "worstRating": "1"
  }
}

Required fields:

• ratingValue — average rating across all reviews. Decimal allowed (4.6).
• reviewCount OR ratingCount — number of reviews (or ratings without text). Either is required.
• bestRating — the highest possible rating. Defaults to 5 if omitted; include for clarity.
• worstRating — the lowest possible rating. Defaults to 1.

Rules Google enforces:

• The ratings must be for the specific product, not for the store or the brand.
• The ratings must be visible on the page.
• The count must match the actual number of reviews.
• Reviews must be from real users (not self-generated).
• Ratings can't be selectively shown (all reviews regardless of star count).

Review (individual review)

For displaying specific reviews on the PDP:

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Nike Pegasus 41",
  "review": [
    {
      "@type": "Review",
      "reviewRating": {
        "@type": "Rating",
        "ratingValue": "5",
        "bestRating": "5"
      },
      "author": {
        "@type": "Person",
        "name": "Jane Doe"
      },
      "datePublished": "2026-04-15",
      "reviewBody": "Great fit. Ran 300 miles without issues. Much better than my previous Peg 40 — the cushioning feels dialed in."
    },
    {
      "@type": "Review",
      "reviewRating": {
        "@type": "Rating",
        "ratingValue": "4",
        "bestRating": "5"
      },
      "author": {
        "@type": "Person",
        "name": "John Smith"
      },
      "datePublished": "2026-04-10",
      "reviewBody": "Solid shoe. Slightly firmer than I expected; took a few runs to break in. Would buy again."
    }
  ]
}

Per-review fields:

• reviewRating — Rating object with ratingValue and bestRating.
• author — Person with a name. Real user name (can be pseudonymous but consistent).
• datePublished — ISO 8601 date of the review.
• reviewBody — the actual review text.

Include 5-10 recent reviews representative of your rating mix (not just 5-stars). Google occasionally displays individual reviews in specific rich result layouts.

Critical: visibility requirement

Reviews must be visible on the rendered page. Schema claiming ratings that users don't see is the #1 manual-action trigger for review spam.

Compliant:

• Reviews displayed on the PDP.
• Review count visible (even if individual reviews are paginated).
• Average rating shown near the product name.

Non-compliant:

• Schema says 127 reviews; page shows 0 visible reviews.
• Reviews hidden behind CSS (display: none).
• Reviews "coming soon" with schema backfilled.
• Reviews from third-party widgets that don't actually render (JavaScript that fails to load).

Where review ratings can legitimately appear

Review schema applies to specific entities. Where it's valid:

• Product — product ratings on PDPs.
• LocalBusiness — business ratings on local pages.
• Recipe — recipe ratings.
• Book, Movie, CreativeWork — content ratings.
• Course — course ratings (limited Google support).
• Event — event ratings.

Where it's NOT valid (manual-action risk if misused):

• Organization — rating your company as a whole. Not supported for rich results.
• Service — rating a generic service. Limited support.
• Homepages — typically shouldn't have AggregateRating at the page level.

The aggregated-from-external-sources problem

Can you aggregate reviews from third-party sources (Trustpilot, Google Business Profile, Yelp) into your own AggregateRating?

No, generally. Google expects the reviews you mark up to be yours — collected on your site, submitted by your users.

Reviews aggregated from external sources:

• Are usually owned by the third party (Trustpilot, Yelp) — not transferable to your schema.
• Creating duplicate ratings across sites (Trustpilot has 127 reviews at 4.6; your schema also claims 127 at 4.6) is easy to detect and flag.
• Google has explicitly called this out as a violation in the Merchant Center policies and structured data guidelines.

Exception: genuine review aggregators who have permission to display and schema the reviews (e.g., a review-specific platform). For most retailers, aggregating external reviews into your schema is off-limits.

Fake review detection

Google's systems look for patterns that indicate manufactured reviews:

• Unnatural rating distributions — all 5-star, or a suspicious bimodal (many 5s, many 1s, no 3-4s).
• Timing patterns — many reviews in narrow time windows.
• Author patterns — authors with only one review, all first-time reviewers, suspicious similar-sounding names.
• Content patterns — similar language or phrasing across multiple reviews.
• Sudden accumulation — a product going from 0 to 200 reviews in a week.

If your review sources have these patterns, schema amplifying them increases detection risk.

Best practice: only schema reviews that are from your genuine verified customers (post-purchase email surveys, verified purchase tags).

Implementation at scale

For ecommerce with thousands of products:

1. Review collection pipeline.

Post-purchase emails inviting reviews. Verified-buyer tags. Typical response rate 2-5% of buyers; builds review corpus over time.

2. Moderation.

Profanity filters, duplicate detection, obvious fake flags. Human review for borderline cases.

3. Display logic.

Show all reviews or filtered by rating (but mark AggregateRating on all, not just the filtered visible subset). Paginate reviews per PDP when count exceeds 20-30.

4. Schema generation.

Generate Product + AggregateRating + Review array server-side. Update whenever a new review publishes.

5. Validation in CI.

Unit-test the schema generator: required fields present, rating within bounds, date format correct, author information consistent.

Review result rich result eligibility

Google displays star rich results selectively:

• Page must have valid AggregateRating schema.
• Ratings must be genuine, visible, and from real users.
• Product must be a specific product (not a generic "services offered" page).
• Page must match the general quality bar (not spammy, not thin).

Even with correct implementation, Google doesn't always show stars. Rich result eligibility ≠ guaranteed display.

Common mistakes

AggregateRating before you have reviews. "0 reviews, 0.0 stars" schema is worse than no schema — signals incomplete implementation. Wait until you have real reviews (5+ typical minimum for meaningful rating).

Marking up five-star reviews only. Google expects AggregateRating based on all reviews, not a selected subset. Show full rating spread; don't cherry-pick.

Aggregating across multiple products. AggregateRating per product, not per brand or per store. Don't aggregate "average rating across all Nike shoes" into a single schema.

Reviews from before purchase / without verification. Reviews attached to specific purchases carry quality weight; anonymous "review" from any visitor doesn't.

Reviews written by your staff. Brand employees writing reviews with public personas violates multiple guidelines. Don't.

Schema date mismatch with visible date. Schema says review published 2026-04-15; page shows "last week." Google's systems may detect; inconsistency is a mild negative signal.

Frequently asked questions

Can I use Trustpilot reviews in my schema?

Generally no. Trustpilot reviews belong to Trustpilot; Trustpilot schemas them, not you. Some Trustpilot integrations allow licensed display on your site with their own schema; that's their rich result, not yours.

What's the minimum number of reviews for AggregateRating to show?

Google has no published minimum, but typically 5-10 reviews before stars reliably appear. Below that, stars may be inconsistent or suppressed.

Should I incentivize reviews with discounts?

Disclosure matters. If you offer a discount for a review, the review must disclose that incentive. Unincentivized verified-purchase reviews are the cleaner signal; incentivized reviews should be flagged as such.

What if my reviews come from a third-party widget (Yotpo, Bazaarvoice)?

These platforms typically generate schema on your behalf. Verify: is the schema in your page's HTML (server-rendered), and does the widget's data match what users see? If both, you're fine.

How often should I regenerate schema when reviews update?

On every new review. For high-review-count products with frequent new reviews, the AggregateRating average changes slightly — regenerate on write. Don't batch nightly if new reviews publish daily.

What to read next

• E-commerce SEO Playbook — review schema in the broader ecommerce picture.
• Product schema markup — where review schema fits into product pages.
• Structured data that moves rankings — the general schema strategy.