No. Google has specific, actively enforced policies governing aggregateRating and Review structured data, and how the underlying review data was collected matters directly to whether the rich snippet is eligible to display at all. The rating has to reflect genuine, verifiable reviews of the specific item being marked up. Google’s review snippet guidelines explicitly prohibit self-authored or editorial ratings being marked up as if they were aggregated customer reviews, and violations can result in a manual action, not just a quiet non-display. “Star ratings present in the markup” and “star ratings Google will actually show as a rich snippet” are not the same thing.
Why review data sourcing determines rich snippet eligibility
Google’s structured data guidelines for review snippets are built around a specific integrity requirement: the aggregate rating must represent real reviews of the actual entity being marked up, collected in a way Google can trust reflects genuine user sentiment, not a business’s own promotional or editorial assessment of itself. Google’s documentation is explicit that self-authored or editorial ratings marked up as if they were third-party customer feedback are ineligible for LocalBusiness and Organization structured data specifically; Google hasn’t published that identical language for Product schema, but the same underlying integrity principle, that a rating has to reflect genuine review data for the specific entity it’s attached to, is the standard its review-snippet policies are built around generally, and applying an aggregate rating collected for a different or broader entity (a whole brand’s average rating, for instance) onto a specific product page it doesn’t actually correspond to runs against that same principle even where Product isn’t named as explicitly.
This is a genuinely enforced policy area, not a passive technical validation. Google states it takes manual action against sites that violate review-snippet policies, meaning the consequence isn’t limited to the rich result simply failing to appear, a site can face a manual action affecting its broader search presence if the pattern is flagged as a violation rather than an honest mistake.
A related and frequently confused case is third-party review widgets. Many sites embed a review-collection widget or plugin that generates its own structured data automatically, and the site owner often doesn’t fully audit what that third-party script is actually outputting. If that widget’s aggregate figure blends reviews left on a different product variant, rolls up reviews across an entire catalog into a single site-wide number applied to every product page, or otherwise doesn’t correspond one-to-one with the specific item on that specific page, the site is still responsible for the resulting markup even though a vendor’s script generated it. “The plugin did it automatically” isn’t a defense Google’s enforcement recognizes, since the guideline is about what the markup claims relative to the entity it’s attached to, not about who technically authored the JSON-LD.
The reason this misconception is common is that syntactic validity (correctly formed aggregateRating JSON-LD with a ratingValue, reviewCount, etc.) is easy to achieve and easy to test, and site owners naturally assume passing validation is the whole story. But the policy layer sits above the syntax layer entirely: markup can be perfectly valid schema.org JSON-LD and still violate the review-snippet content policy if the underlying rating doesn’t represent genuine, appropriately sourced review data for that specific item.
There’s also a scope-mismatch variant of this problem that’s easy to miss because it doesn’t involve anything editorial or self-authored at all. A retailer selling the same product across multiple sizes, colors, or configurations sometimes applies one aggregate rating, gathered across all variants combined, to every individual variant page. Even when every underlying review is completely genuine, this can still misrepresent the specific item on a given page if that variant’s actual review profile would look meaningfully different in isolation (a color variant with a defect complaint pattern, a size that runs oddly, a configuration with a known compatibility issue). The reviews are real, but the aggregation boundary doesn’t match the entity the markup claims to describe, which is the same underlying problem as an editorial rating in a different guise: the number on the page doesn’t correspond to genuine sentiment about that specific thing.
How to source and audit aggregateRating markup correctly
Before implementing aggregateRating or Review markup, confirm the review data genuinely originates from real customers reviewing that specific product or service, collected through a legitimate review-gathering process (verified purchase reviews, a recognized third-party review platform’s data via a documented, permitted integration), not editorial staff opinions, marketing copy reframed as reviews, or an aggregate figure borrowed from a different, broader entity.
Never mark up a business’s own self-authored or promotional description as a “review,” even if it’s phrased favorably and includes a number; this is precisely the pattern Google’s guidelines name as a violation, not a gray area.
If aggregating reviews from multiple sources, make sure the aggregation methodology is transparent and the individual reviews are genuinely verifiable or traceable back to real users, since Google’s guidance is oriented around authenticity and traceability, not just numerical validity.
Audit any third-party review widget or plugin actually rendering on the page, don’t assume a vendor’s default configuration maps ratings one-to-one with the product they’re displayed against. Check the widget’s own settings for whether it’s showing a per-product figure or a rolled-up site-wide or category-wide average, and check the rendered JSON-LD directly (view-source alone often isn’t enough if the widget injects markup client-side) rather than trusting the vendor’s marketing description of how the integration works.
Where the site legitimately has both self-authored editorial content (a staff writeup, a buying guide with an opinionated score) and genuine aggregated customer reviews, keep the schema markup for each separate and don’t let an editorial score bleed into aggregateRating. A Review type authored by the publication itself, clearly attributed as such, is a different and legitimate pattern from marking up an editorial opinion as if it were crowd-sourced customer sentiment, the distinction is in whether the markup is honest about the source of the rating, not in whether editorial content can be marked up at all.
Regularly check Search Console’s structured data and manual actions reports, since if review markup is ever the subject of enforcement, that’s where it would surface, and catching it early is far better than discovering a lost rich result was actually a policy violation rather than a simple display gap.
