TL;DR: Google requires that any rating you put in aggregateRating is visible on the same page, and that the count matches. If your JSON-LD says reviewCount: 1247 but the page shows 32, Google logs a review issue and pulls your star chip. Fastest fix: feed reviewCount and ratingValue from the same source that renders the visible reviews, set bestRating/worstRating to match your visible scale, re-test in the Rich Results Test, and request re-indexing. Star chips usually return within 2-4 weeks (as of June 2026).
Your product page used to show a five-star rating chip in SERPs. Last week the chip vanished, even though nothing about the page seems to have changed. Search Console quietly flags an issue on the affected URL under Merchant listings (for pages with offers) or Product snippets (for review-only pages) — the two enhancement reports Google split product data into. Pulling up View Source confirms the bug: aggregateRating declares 1,247 reviews at 4.8 stars, but the visible “Reviews” section lists only the 32 reviews stored in your own database.
Google enforces a strict rule here — and it is unusually blunt in the docs: “Don’t aggregate reviews or ratings from other websites,” and the aggregate rating you mark up must be visible to users on the same page. Cross-site review counts, third-party widgets that haven’t rendered, and “global” rollups all break this rule. The star chip is suppressed silently; there is rarely a hard error, just a missing rich result.
Which bucket are you in?
Run one check first: load the page, open View Source (raw HTML, not the rendered DevTools Elements panel), find reviewCount, then compare it to the visible review count after the page fully renders. The gap tells you which cause to read.
| What you observe | Most likely cause |
|---|---|
Same reviewCount on many unrelated products | Site-wide aggregate asserted per page (cause 1) |
| Visible reviews vanish with JavaScript off, JSON-LD count stays high | Widget renders reviews, server renders schema (cause 2) |
| Count includes Amazon / Google Shopping / partner reviews | Off-domain reviews in the aggregate (cause 3) |
reviewCount matches yesterday’s number, visible count dropped | Stale schema cache (cause 4) |
| Every size/color variant shares one count | Parent rating asserted on each variant (cause 5) |
Visible “4.8 / 5” but bestRating is "10" | Wrong rating scale (cause 6) |
Common causes
Ordered by how often each tripped up real teams.
1. Reviews aggregated across the entire site, asserted on one page
Your platform aggregates ratings from every store, marketplace, and locale into one global number. The template then asserts that global number on every product page, even though each page only shows its own reviews.
How to spot it: reviewCount is the same on dozens of unrelated product pages. The visible reviews are a small subset of that count.
2. Third-party widget shows reviews; JSON-LD comes from a different source
The visible reviews load from a Yotpo / Trustpilot / Bazaarvoice widget. The JSON-LD on the page is generated server-side from your own database. The two never agree.
How to spot it: Disable JavaScript and reload. If the visible review count drops to zero but JSON-LD still asserts hundreds, the widget is the only source of visible reviews.
3. Off-domain reviews counted in aggregateRating
Reviews from Amazon, Google Shopping, or a partner site got pulled into the aggregate. They are not on the page Google is crawling, so Google rejects the rating. This violates Google’s explicit rule: “Don’t aggregate reviews or ratings from other websites.”
How to spot it: Your review system has an “include external sources” toggle that is on. Disable it, recompute, compare to JSON-LD output.
4. Stale cache: visible reviews refreshed, JSON-LD still old
Reviews were moderated and deleted, dropping the visible count. The JSON-LD generator caches reviewCount for 24 hours and still reports the pre-deletion number.
How to spot it: reviewCount is exactly what it was yesterday. Visible count is now lower. Cache TTL matches the gap.
5. Multi-variant product, one rating asserted per variant
A parent product has 6 size / color variants. Each variant page asserts the parent’s aggregate rating (1,247 reviews) but only shows that variant’s slice (say, 18 reviews).
How to spot it: All variants share the same reviewCount. Visible review count differs per variant.
6. bestRating / worstRating lies about the scale
JSON-LD declares a 10-point scale ("bestRating": "10") but visible reviews are on a 5-point scale. Google interprets a 4.8 as 4.8/10 and the rating chip turns to a low score.
How to spot it: The visible UI says “4.8 / 5” but JSON-LD has "bestRating": "10". Note Google’s default: if you omit bestRating it assumes 5, and if you omit worstRating it assumes 1. So the bug only appears when you set the wrong scale explicitly — when in doubt on a 5-point UI, omit both and let the defaults apply.
Not a cause: “self-serving reviews” on Product
A common false lead: the “self-serving reviews” restriction (an entity reviewing itself on its own site) only makes LocalBusiness and Organization schema ineligible for star chips. It does not apply to Product — first-party product reviews you host yourself are eligible, provided they are visible on the page and the counts match. If your star chip disappeared on a product page, the mismatch is the cause, not the self-serving rule.
Before you start
- Capture a baseline screenshot of the SERP rich result before changing anything. You will compare it after the fix.
- Open Search Console and check both Merchant listings and Product snippets under the left-nav (Google split product reporting into these two; pages with
offersland in Merchant listings). Note whether the URL is flagged as an error/invalid item or a warning — warnings still serve the chip, errors usually do not. - List every component on the page that could surface review data: server-rendered JSON-LD, third-party widget, microdata, RDFa.
- Decide your source of truth — typically the same source as the visible widget.
Information to collect
- Exact
reviewCount(orratingCount),ratingValue,bestRating,worstRatingvalues from raw HTML. - Visible review count on the page after JavaScript fully renders.
- Source system for visible reviews (Yotpo, Trustpilot, in-house database, etc.).
- Whether multi-variant pages share one schema block or have one per variant.
- Search Console screenshot showing the issue name verbatim (for the email/escalation trail).
Step-by-step fix
Ordered ROI-first.
Step 1: Confirm the mismatch with a direct comparison
curl -s https://example.com/products/widget | \
grep -oE '"(reviewCount|ratingCount)":\s*"?[0-9]+"?' | head -2curl gives you the raw server HTML — the exact bytes Googlebot fetches before running JavaScript. Compare that number to what the page visibly says after it fully renders in a browser. If they differ by more than rounding, you have the bug. (Do not trust the DevTools Elements panel for the schema value; it shows the post-JavaScript DOM, which can hide a server/widget split.)
To see what Google itself extracts, paste the URL into the Rich Results Test and read the parsed reviewCount it reports back.
Step 2: Identify the single source of truth
Decide: do you want JSON-LD to mirror what users see on the page, or do you want to surface your global aggregate? Google requires the former. Pick the source that powers the visible widget and route JSON-LD through the same call.
Step 3: Strip cross-source aggregation from the schema
// before — aggregates all sources
const reviewCount = totalReviewsAcrossPlatforms(productId);
// after — only reviews actually rendered on this page
const reviewCount = visibleReviewsOnPage(productId, locale, variant);If the visible widget shows 32 reviews, reviewCount must be 32.
Step 4: Align variants
For variant pages, scope schema to the variant:
{
"@type": "Product",
"name": "Widget — Red, Large",
"sku": "WID-RED-L",
"aggregateRating": {
"@type": "AggregateRating",
"ratingValue": "4.7",
"reviewCount": "18",
"bestRating": "5",
"worstRating": "1"
}
}Each variant URL gets only its own review aggregate. If a variant has no reviews, omit aggregateRating entirely — do not fall back to the parent.
Step 5: Lock the rating scale
Set bestRating and worstRating to match the visible UI, or omit both on a standard 5-point scale (Google assumes bestRating: 5 and worstRating: 1 when they are absent). The danger is asserting a wrong scale, not leaving it implicit:
"aggregateRating": {
"@type": "AggregateRating",
"ratingValue": "4.8",
"reviewCount": "32",
"bestRating": "5",
"worstRating": "1"
}If you count ratings without written text (stars only), use ratingCount instead of — or alongside — reviewCount; Google requires at least one of the two. Don’t report 32 reviewCount if only 8 of those 32 have review text and the rest are bare stars: that split is exactly what a mismatch check looks for.
Step 6: Cache-invalidate when reviews change
Wire the JSON-LD cache key to a content version that flips when a review is moderated or added. A short TTL alone is not enough — a 24-hour TTL means up to a day of stale rich results.
Step 7: Re-validate and request re-indexing
- Run the Rich Results Test on the corrected URL; verify the parsed
reviewCountnow equals the visible count and there are no review warnings. - Use URL Inspection → Test Live URL, confirm the fix, then Request Indexing on 5-10 high-priority product URLs.
- Watch the Merchant listings and Product snippets enhancement reports in Search Console; warnings should drain over 2-4 weeks as Google recrawls.
Verify
- Rich Results Test reports “Valid” with no warnings on
aggregateRating. - Visible review count on the page exactly equals
reviewCountin JSON-LD. - The star-rating chip returns to SERPs within 2-4 weeks (track impressions in Search Console).
- Variant pages each show their own aggregate, not the parent’s.
Long-term prevention
- Document the rule team-wide: “Every number in JSON-LD must be visible on the same page.”
- Pull schema review fields from the same API call that powers the visible widget — never from a separate “global” source.
- Add a CI assertion that crawls a sample of product pages and compares
reviewCountin JSON-LD against the visible count. - For sites with external reviews, do not aggregate cross-domain ratings into a single page-level schema; cite them separately or not at all.
- Bake variant-awareness into your schema generator so parent ratings never leak into child URLs.
Common pitfalls
- “Borrowing” reviews from a popular variant to make a long-tail variant look reviewed — Google can detect duplicates and flag the entire product line.
- Reporting a
ratingValueto two decimals when the visible UI rounds to one (“4.85” vs “4.9”). Match visible precision exactly. - Leaving an
aggregateRatingon the page after all reviews have been moderated out. IfreviewCountis 0, omit the block entirely. - Counting an internal “thumbs up / down” widget as reviews. Google requires actual review content.
- Submitting fictional
bestRating/worstRatinglike 10 or 100 when the visible scale is 5. Google reinterprets the rating and shows a low score.
FAQ
Q: Can I keep my global review count visible somewhere else, like “Over 1,200 reviews across all stores”?
Yes — as prose in the page body, not in aggregateRating. Schema must mirror what is on the same page. Brag about totals in copy, keep schema honest.
Q: How long until the star chip returns after the fix?
Typically 2-4 weeks. Google re-evaluates structured data on crawl; high-traffic product URLs recrawl fastest. Request indexing on your top revenue pages to speed this up.
Q: We have only a handful of reviews per page. Should we even ship aggregateRating?
Technically aggregateRating needs a non-zero count, so even one review qualifies. But a chip backed by two or three ratings rarely earns trust and can look thin; if the count is very small, it is usually fine to omit the schema and let the page rank without a rating chip until you have a more meaningful sample. Never pad the number to clear an imagined threshold.
Q: Can I include review snippets from Trustpilot embedded as iframes?
No. Reviews must be on the same page in crawlable HTML. Iframe content is not part of the parent page, so Google does not credit it toward the page’s review markup. Either render the review text server-side into the page, or do not assert those reviews in schema.
Q: My count matches but the chip still hasn’t returned. What now?
First confirm the page is actually being recrawled: check the URL’s last-crawl date in URL Inspection. If it crawled after your fix and the Rich Results Test is clean, the chip is eligible but not guaranteed — Google chooses when to show review snippets. Make sure the page also has the required Product name and an offers or review block, since an incomplete Product can suppress the whole rich result even when the rating is valid.
Related
- Structured Data Rich Results Warning
- Structured Data Became Invalid After a Template Change
- FAQ Schema Invalid
- Article Date and JSON-LD Date Mismatch
- Website JSON-LD Inconsistency
External references:
- Google: Review snippet (Review, AggregateRating) structured data — the authoritative rules, including “Don’t aggregate reviews or ratings from other websites” and the
bestRating/worstRatingdefaults. - Google Rich Results Test — paste a URL to see the exact
reviewCountGoogle parses.
Tags: #SEO #Troubleshooting #Structured data #product-schema #aggregaterating