Eligibility brief · Review snippets
Three decisions before keeping stars in your markup
Google's July 2026 clarification turns review provenance and disclosure into an explicit quality gate, not a schema-cleanup detail.
- Verify genuine experience before syntax
A valid rating object cannot rescue a review that was not based on real use of the product or service.
- Expose every material benefit prominently
Money, discounts, vouchers and free products are named examples. A disclosure that is hidden or separated from the review leaves the snippet at risk.
- Treat rich-result testing as only one gate
The Rich Results Test can confirm structure. Google's quality rules can still make syntactically valid markup ineligible or subject to manual action.
On 24 July 2026, Google added a direct rule to its review snippet documentation: pages and structured data must not include fake reviews or incentivized reviews whose incentive is not clearly disclosed. The examples are concrete. A review must reflect a genuine experience, and benefits such as money, discounts, vouchers or free products must be disclosed clearly and prominently.
This is an eligibility rule for review snippets, not an announcement that every incentivized review is forbidden. The operational question is whether a publisher can prove the experience, identify the benefit and place the disclosure where a reader can understand it before trusting the rating.
Start with how the review was obtained and what the reviewer received. Only then test the visible review, rating fields and structured data.
The rule reaches beyond the JSON-LD block
Google's wording covers fake or undisclosed incentivized reviews both on the page and in the structured data markup. Removing a questionable review from JSON-LD while leaving it visible in the aggregate does not solve the provenance problem. Nor does marking up only a cleaner subset when the page presents a broader rating picture.
The general structured data guidelines already require marked-up information to match visible content and prohibit misleading markup. The July addition makes the review-specific boundary easier to audit. It also aligns with Google's recommendation to accept ratings that include a review comment and an author's name, because a rating with attributable context is easier to examine than an unexplained score.
This narrow scope matters. Google's separate reviews system rewards in-depth analysis and original research in editorial review content. Review snippet eligibility asks a different question: whether the review and rating data presented to Search are genuine, visible and policy-compliant.
A review provenance chain that can survive an audit
The strongest implementation does not begin with schema properties. It begins with a traceable chain from the experience behind a review to the exact rating included in the page's aggregate and markup.
Review Evidence Chain
Every link must remain attributable. A broken disclosure link invalidates the trust claim before markup is tested.
Purchase, use, attendance or another verifiable encounter with the reviewed item.
Money, discount, voucher, free product or another material exchange is retained with the review record.
The incentive is clear and prominent beside the review, not hidden in a remote policy page.
The displayed rating, included reviews and structured data describe the same evidence set.
Technically perfect schema remains exposed when the benefit is missing from the reader's view or the underlying experience is not genuine.
Publishers do not need to expose private order details publicly. They do need an internal record that lets them answer who submitted the review, what item or service was experienced, whether compensation existed, where the disclosure appears and whether the review contributes to the aggregate rating.
This is also why scraping or importing ratings from another website is unsafe for review snippets. Google's review snippet rules say not to aggregate reviews or ratings from other sites. Provenance cannot be outsourced to a number copied from a marketplace widget or feed.
Three review states need different treatment
The new language creates a practical triage. Incentive alone is not the only variable; experience and disclosure determine whether a review can remain in the eligible evidence set.
Retain when the experience is real, visible review content matches the markup and no undisclosed material benefit exists.
Record the benefit and place a clear, prominent disclosure with the review. Recheck every aggregate that includes it.
Remove the review from the page, aggregate and markup when genuine experience cannot be supported or the incentive remains undisclosed.
“Prominent” is not defined by a pixel value in the review snippet guide. A defensible implementation places the disclosure in the same visual context as the review, before or alongside the rating and endorsement. A generic affiliate statement in the footer, terms page or collapsed sitewide policy does not tell the reader which specific review was incentivized.
For local businesses and organizations, another boundary still applies. Pages controlled by the entity being reviewed are ineligible for the star review feature when they use LocalBusiness or another Organization type for self-serving reviews, including embedded third-party widgets. The July rule does not replace that restriction.
Schema validity and policy eligibility are separate gates
Google explicitly notes that quality guidelines are not easily testable with automated tools. The Rich Results Test can detect missing required properties or malformed JSON-LD. It cannot interview a reviewer, verify a purchase or decide whether a voucher disclosure is prominent.
The supported type is used, required properties exist, the rating scale is coherent and the marked-up review is visible on the page.
The experience is genuine, incentives are disclosed, ratings are not imported from another site and local-business markup is not self-serving.
A green technical test therefore proves only the first gate. Google may withhold a rich result even from valid markup, and guideline violations can lead to a structured data manual action. Such an action affects eligibility for the rich result; it does not automatically remove the underlying page from ordinary web search.
The same measurement discipline applies when teams read newer Search Console surfaces. Our guide to the Generative AI performance report explains why a reported event should not be allowed to stand in for evidence the tool cannot observe. Here, a passing parser cannot stand in for review provenance.
Repair the evidence set before regenerating markup
When an audit finds a provenance gap, editing the JSON-LD first can preserve the wrong aggregate and create a second mismatch. Repair the underlying evidence set in a fixed order.
Identify its source, reviewer, item, incentive status and whether it contributes to an aggregate.
Update the visible page and recalculate the aggregate before touching schema output.
Use plain language that names the material benefit where the review is read.
Confirm counts, values, authors and reviewed items match the visible content exactly.
Use the Rich Results Test for structure, URL Inspection after deployment and a human provenance review for the policy gate.
Template changes should then be monitored in Search Console. An increase in invalid items may reveal a broken deployment. A drop in valid items without matching invalid items can indicate that markup disappeared or ceased to qualify. Neither pattern identifies hidden incentives on its own, so the provenance record remains necessary.
Teams that already track rendering and extraction failures can add the policy audit to the same release discipline. The technical debugging approach in our guide to Googlebot link extraction is useful for deployment checks, but it must remain separate from the human evidence review.
The narrow conclusion
Google has made review origin and incentive disclosure an explicit review snippet boundary. The safest response is not a new schema property. It is a review evidence chain that can prove genuine experience, surface material consideration and keep the visible page, aggregate rating and markup synchronized.
Questions teams should settle before release
Are all incentivized reviews ineligible for review snippets?
Google's new rule targets fake reviews and incentivized reviews that do not clearly and prominently disclose the incentive. The review still needs to reflect a genuine experience and satisfy all other review snippet guidelines.
Will the Rich Results Test detect an undisclosed voucher?
No. It can validate markup structure, but Google's quality guidelines are not fully testable by automated tools. Provenance and disclosure require a separate human audit.
Can a business mark up reviews about itself?
Pages controlled by the reviewed local business or organization are ineligible for the star review feature when using LocalBusiness or Organization markup for self-serving reviews, including embedded third-party review widgets.
Primary sources
Google documentation checked 15 August 2026
- Latest Google Search documentation updates — records the 24 July 2026 review snippet guideline addition.
- Review snippet structured data — technical, quality and local-business eligibility rules.
- General structured data guidelines — visibility, accuracy, manual actions and non-guaranteed rich-result appearance.
- Google Search reviews system — separate guidance for editorial review quality and original research.
- Product snippet structured data — how review and aggregate rating markup is nested for products.
- Review snippet reports in Search Console — official reporting and search appearance context.
