You have reviews from a sampling campaign, loyalty offer, discount program, or product giveaway, and some of them feed the rating marked up on your site. The question is not simply whether an incentive existed. You need to know whether the review reflects a real experience, whether the benefit was disclosed clearly, and whether your page and structured data present the same record.
Treat the published review, its disclosure, the visible aggregate rating, and the JSON-LD as one system. Fixing only the schema can leave the underlying policy problem in place.
The rule draws two separate lines
A review snippet is a review excerpt or rating that can appear in Google Search, often as an aggregate drawn from multiple reviewers. Following the applicable guidelines makes a page eligible for review-snippet features; it does not guarantee that Google will display them.
Google’s rule is explicit: fake or undisclosed incentivized reviews should not appear on the page or in its structured data markup. That creates two distinct tests:
- A fake review is not based on a genuine experience with the product or service. Adding a compensation disclosure does not turn it into a valid review.
- An undisclosed incentivized review may describe a genuine experience, but it hides or inadequately presents the benefit the reviewer received. The problem is the missing disclosure as well as the way the review is represented.
Incentives can include money, discounts, vouchers, or free products. The wording matters: the prohibition names fake reviews and incentivized reviews that are not clearly and prominently disclosed. It is narrower than a blanket statement that every incentivized review is forbidden, but it is not an automatic approval for every disclosed review. All other review-snippet requirements still apply.
For implementation, treat clear and prominent as a reader-facing standard. The person reading a specific review should be able to see that review’s incentive without opening a policy page, following another link, or hunting through fine print. A practical placement is directly beside the reviewer details, rating, or review text. Disclosure inside JSON-LD alone is not a reader-facing disclosure.
Classify each review before changing the markup

Do not apply one decision to an entire campaign until you have separated the reviews into meaningful cases. One campaign can contain valid organic reviews, properly disclosed incentivized reviews, undisclosed reviews, and reviews with no evidence of genuine experience.
| Review situation | Markup decision | Page action |
|---|---|---|
| No genuine product or service experience | Exclude it from individual review markup and every marked-up aggregate that counts it. | Remove it rather than trying to repair it with a disclosure. |
| Genuine experience, but an incentive is hidden or not clearly disclosed | Do not include it while it remains undisclosed. Correct any aggregate rating or count that incorporates it. | Pause or remove it, add a truthful and prominent disclosure if appropriate, and reassess it before republishing or re-enabling markup. |
| Genuine experience with a clear, prominent incentive disclosure | The new prohibition does not categorically reject this case, but the disclosure does not override other review-snippet rules. | Keep the disclosure attached to the review wherever that review is displayed or reused. |
| Genuine experience with no incentive | Evaluate it under the normal review-snippet requirements. | Maintain ordinary editorial and data-quality controls. |
The difficult row is the disclosed incentivized review. Do not turn the wording into either an unconditional ban or an unconditional pass. Verify the genuine experience, preserve the exact disclosure, and check the rest of the applicable review rules before counting the review in structured data.
Audit the visible rating and JSON-LD together

The fastest reliable audit starts with the reviews that feed your aggregate rating, not with a schema validator. A validator can tell you whether markup is technically readable. It cannot establish that a reviewer had a genuine experience or that an incentive was properly disclosed to a human reader.
- Inventory every review surface. Include product pages, service pages, category templates, testimonials, imported review widgets, archived campaign pages, and any other page that publishes or aggregates reviews.
- Trace each displayed aggregate to its underlying review records. Record which reviews contribute to the rating value and review count rather than assuming the visible list is the complete data set.
- Create an audit field for genuine experience. If the basis is unknown, put the review into a hold state instead of treating missing information as proof that the review is organic.
- Create a separate incentive field. Record the actual benefit, such as money, a discount, a voucher, or a free product. Do not rely on campaign names that obscure what the reviewer received.
- Inspect the rendered disclosure. Check the live desktop and mobile presentation, template variants, collapsed content, and reused excerpts. The disclosure needs to remain attached to the review in the version a visitor actually sees.
- Remove or quarantine failures before recalculating the aggregate. Excluding an individual Review node is not enough if its rating still influences a marked-up AggregateRating.
- Publish the corrected review set, visible aggregate, review count, and structured data as one coordinated change. Then inspect the rendered HTML to confirm that cached templates or client-side scripts did not restore stale values.
A compact review ledger makes this manageable. Give every review a stable internal ID and track its experience status, incentive type, disclosure text, publication status, aggregate inclusion status, and last audit decision. That record lets your editorial, reputation, and technical SEO teams make the same decision when a review is copied to another page or imported into a new template.
Four partial fixes still leave you exposed
Most implementation mistakes come from treating review markup as an isolated technical layer. The policy explicitly reaches both the page and the structured data, so these shortcuts do not resolve the underlying issue.
- Removing only the individual Review markup: If the incentivized review still affects a marked-up rating value or review count, it remains part of the structured-data claim indirectly.
- Leaving the review visible but omitting it from JSON-LD: That does not resolve a fake or undisclosed incentivized review on the page. The page itself is within the rule.
- Adding the disclosure only to JSON-LD: Structured data is written for machines. It does not make an incentive clear and prominent to the person reading the review.
- Using one generic campaign disclaimer: A disclosure at the bottom of a page or in a separate policy can become detached when an individual review is filtered, syndicated, quoted, or moved. Bind the disclosure to the review record and render them together.
Disclosure also cannot cure fabrication. If the reviewer did not genuinely experience the product or service, a label explaining the incentive addresses the wrong problem. Remove the review and every aggregate contribution derived from it.
Build the disclosure into review collection
Retrofitting disclosure after reviews reach production creates avoidable uncertainty. Collect the information before a review enters the publishing queue, and keep publication approval separate from markup eligibility.
- Ask whether the reviewer received any benefit and store the exact type of benefit as structured data in your CMS or review platform.
- Require a genuine-experience check before editorial approval. Do not let a completed form or imported star rating substitute for that decision.
- Generate a truthful review-level disclosure from the stored incentive field. A usable template is: This reviewer received [specific benefit] in exchange for providing this review. Adapt the wording to what actually happened rather than using a vague sponsored label.
- Keep separate controls for published, included in the visible aggregate, and eligible for structured data. A review may need to remain on hold while its origin or disclosure is investigated.
- Preserve the disclosure when reviews are exported, syndicated, translated, excerpted, or moved between templates. Treat a review without its disclosure as an incomplete record.
- Default uncertain records to excluded. Re-enable them only after someone has documented the genuine experience, incentive status, and live disclosure.
This workflow prevents a marketing campaign from silently changing an SEO claim. It also gives you a defensible answer when a rating changes after disqualified reviews are removed: the new value reflects the review set you can actually stand behind.
Key takeaways
- A review must be based on a genuine product or service experience. Disclosure does not rescue a fabricated review.
- An incentivized review must not be presented without a clear and prominent disclosure of the benefit.
- The rule applies to both the visible page and the structured data, including aggregates that incorporate affected reviews.
- A disclosed incentive is not automatically disqualified by this specific clause, but disclosure alone does not establish full review-snippet eligibility.
- Your safest control is a review-level ledger connecting experience, incentive, disclosure, publication, and aggregate inclusion.
Start with the reviews behind your current aggregate rating. Quarantine anything fake, undisclosed, or uncertain; recalculate the visible and marked-up values from the remaining set; and make incentive disclosure a required field before the next campaign begins.

Leave a Reply