# Google's review guideline asks for something the markup cannot record > Google's review snippet documentation, carrying Last updated 2026-07-24 UTC, tells site owners not to include fake or undisclosed incentivized reviews in the page or in the structured data markup. Of the nine properties schema.org defines specifically on Review, none records whether the reviewer was paid. The rule is about provenance and every automated check reads shape. - Canonical page: https://lantad.co/blog/review-authenticity-is-not-in-the-markup - This file: https://lantad.co/blog/review-authenticity-is-not-in-the-markup.md - Last substantive update: 2026-08-08 ## Key facts - **Published:** 2026-08-08 - **Category:** Findings - **Author:** Lantad - **Length:** 3216 words - **Takeaway 1:** Google's documentation changelog records a 24 July 2026 entry adding a new guideline to the review snippet documentation about fake and undisclosed incentivized reviews, and the review snippet page carries Last updated 2026-07-24 UTC. - **Takeaway 2:** The guideline states: do not include fake or undisclosed incentivized reviews on your page or in your structured data markup, and names as examples reviews not based on a genuine experience and reviews written in exchange for a benefit without clear and prominent disclosure. - **Takeaway 3:** Of the nine properties schema.org defines specifically on the Review type, read on 8 August 2026, none records whether a reviewer was compensated, incentivized or verified, so a compliant page and a non-compliant page can serialize to identical markup. - **Takeaway 4:** The same Google page states that if the entity being reviewed controls the reviews about itself, its pages using LocalBusiness or any other type of Organization structured data are ineligible for the star review feature. - **Takeaway 5:** Lantad's schema check recognises five types by name, Organization, Product, Article, FAQPage and BreadcrumbList, and Review is not among them, so a page whose only structured data is review markup is capped at the typeless score of 0.4 in the schema sub-score. That is a configured setting, not a measurement. ## Summary A rule that a machine cannot check is a different kind of rule, and search documentation rarely says which kind it is publishing. On 24 July 2026 Google's [documentation changelog](https://developers.google.com/search/updates) recorded that it had added a new guideline to the review snippet documentation about fake and undisclosed incentivized reviews. The [review snippet documentation](https://developers.google.com/search/docs/appearance/structured-data/review-snippet) itself, read on 8 August 2026, carries the line Last updated 2026-07-24 UTC and the new guideline reads: do not include fake or undisclosed incentivized reviews on your page or in your structured data markup. Read as policy, that is unremarkable and overdue. Read as a specification, it is the most interesting sentence Google has added to a [structured data](https://lantad.co/glossary/structured-data) page this year, because it asks about something the document does not contain. Every property in review markup describes the rating, the reviewer's name and the thing reviewed. None of them describes how the review came to exist. A page that markets honestly and a page that pays for its five star ratings can serialize to byte identical JSON-LD, and no parser reading that JSON-LD can tell them apart. This post reports what Google added, what the markup can and cannot carry, and what Lantad's own schema check does with review markup, which is less than a reader might assume. Lantad has not measured how many sites carry review markup, has not audited anyone's reviews, and has run no study of review snippet eligibility. Everything below is a reading of two vendor documents and a description of settings in our own repository. ## What Google added to the review snippet documentation on 24 July 2026 The changelog entry is one line: added a new guideline to the review snippet documentation about fake and undisclosed incentivized reviews. The guideline on the page itself is three sentences and worth quoting rather than summarising, because the second half is where the obligation actually sits. It states: do not include fake or undisclosed incentivized reviews on your page or in your structured data markup. It then gives two examples. The first is reviews that are not based on a genuine experience of a product or service. The second is reviews written in exchange for a benefit, such as money, discounts, vouchers or free products, that do not clearly and prominently disclose the incentivization. Two details in that wording carry the weight. The first is the scope, which names the page and the structured data markup as separate places the rule applies. A site that shows a disclosure to a human reader in a paragraph beneath the star rating, and emits markup carrying only the rating and the author, has satisfied one half of the sentence and not the other. The second is that the second example forbids a category of review conditionally. An incentivized review is not prohibited. An incentivized review without clear and prominent disclosure is. That conditional is the part with no home in the vocabulary, which the next section takes up. It is worth being precise about what kind of statement this is. It is a guideline in documentation, not a change to any format. Nothing about the required properties changed on 24 July, and a page that validated on 23 July still validates today. What changed is the stated basis on which Google may decide a page is not eligible for the feature, which is a different lever from validation and one no local check can anticipate. This blog has looked at that gap between a scored signal and a shown feature before, when [Google deleted the FAQ rich result documentation](https://lantad.co/blog/faq-rich-result-gone-faqpage-still-scored) and the markup carried on parsing perfectly into a feature that no longer existed. The direction is the same here. Markup validity and feature eligibility are two systems, and only one of them runs on your server. ## A validator reads shape, and the guideline is about provenance Google's page lists what review markup must contain to be eligible. For a Review it names author, itemReviewed if the review is not nested, the name of the item reviewed, reviewRating and reviewRating.ratingValue. For [AggregateRating](https://schema.org/AggregateRating) it names itemReviewed or the parent item name, ratingValue, and at least one of ratingCount or reviewCount. Those are shape requirements. Every one of them is a question about whether a key is present and holds a usable value, which is exactly the class of question an automated check can answer from the document alone. Now look at the vocabulary underneath. [Schema.org's Review type](https://schema.org/Review), read on 8 August 2026, defines nine properties of its own: associatedClaimReview, associatedMediaReview, associatedReview, itemReviewed, negativeNotes, positiveNotes, reviewAspect, reviewBody and reviewRating. None of them records whether the reviewer was paid, given a free product, or verified as a purchaser. Review also inherits the general CreativeWork properties, which we did not enumerate one by one, and none of the nine that are specific to Review carries provenance. There is no property to put a disclosure in, so there is no property for a checker to read it out of. That asymmetry is the whole finding. A structured data test tells you whether the document is well formed and complete against a type's requirements. Google's [Rich Results Test](https://search.google.com/test/rich-results) answers that question for a URL. Neither it nor any other reader of the same bytes can answer the new one, because the fact the guideline is about was never written into the bytes. The enforcement therefore has to happen somewhere else: in human review, in a signal Google derives from outside the page, or not at all. The documentation does not say which, and we are not going to guess. For anyone building or buying an automated check, this is the useful distinction to hold onto, and it applies well beyond reviews. Machine readable is not the same as true. A scanner that reads a page can tell you that a claim is present, formatted correctly and extractable by a machine that does not run JavaScript. It cannot tell you the claim is accurate. We have written the same caution into our own product, which is why the report [withholds a letter grade](https://lantad.co/blog/why-we-withhold-a-grade) rather than emit a confident wrong one, and why the [methodology](https://lantad.co/methodology) page states what a scan does not measure before it states any result. ## The restriction on reviews an entity controls about itself The same page carries a second restriction that is older than the July guideline and that a lot of sites appear to run into by accident. It states that if the entity being reviewed controls the reviews about itself, its pages that use LocalBusiness, or any other type of Organization structured data, are ineligible for the star review feature. Read carefully, that is a rule about who operates the review collection rather than about the reviews themselves. A company that gathers genuine, unpaid, fully disclosed testimonials from real customers, and publishes them on its own site with its own moderation, is describing exactly the arrangement the sentence names. The reviews may be entirely honest. The markup may be complete. The page is still ineligible for stars against those two types, because Google has decided that self operated review collection is not the evidence the feature is meant to show. This one is closer to checkable than the incentivization rule, but only from outside the document. Nothing in the JSON-LD says who runs the review pipeline. What a reader can establish is the type, and the type is where the trap sits: the restriction is written against Organization and any other type of Organization, which sweeps in LocalBusiness and every other subtype. A site that marked itself up as LocalBusiness because that is what a plugin emitted, and then added its own testimonials, has assembled the exact combination named. There is a small structural echo of this in how any type system handles subtypes, and it is worth naming because it affects what a scan can report. Lantad's own schema check canonicalises subtypes to a parent before it checks requirements: NewsArticle, BlogPosting, TechArticle and ScholarlyArticle are checked against Article, and LocalBusiness and Corporation are checked against Organization. That mapping is a setting in our repository, chosen so a page is not penalised for using a more specific type. It happens to place LocalBusiness and Organization in the same bucket that Google's restriction places them in, which is coincidence rather than design, and it is the reason our reports talk about the parent type when your markup names the child. If you want the identity side of this rather than the ratings side, [entity confidence](https://lantad.co/glossary/entity-confidence) is the signal that covers whether the page states who the business is at all. ## What Lantad's schema check recognises, and why Review is not on the list Since this is a post about the limits of automated checks, the honest thing is to state ours. Lantad's schema check recognises five types by name and holds the required properties for each as data: Organization needs name and url, Product needs name, Article needs headline, FAQPage needs mainEntity, and BreadcrumbList needs itemListElement. Six subtypes map onto two of those parents, as described above. That list is a configured setting in our repository, not a finding about what matters, and nothing about it was derived from measuring outcomes. Review is not on the list, and neither is AggregateRating. Neither string appears anywhere in the scoring library, verified on 8 August 2026. The practical consequence is specific rather than vague. An entity carrying a type we hold no requirements for is not penalised at the entity level, because there is nothing further we can require of it. But a page whose entire JSON-LD is types we do not recognise is capped at the typeless score, which the scoring config sets at 0.4, on the grounds that such a page carries structured data conveying no business fact the scan can validate. So a page whose only markup is review markup lands at that cap, and a page carrying Product or Organization alongside its reviews is unaffected. Reading that in the direction a site owner cares about: our score neither rewards nor punishes review markup, and it certainly does not assess whether your reviews are real. If reviews are the only structured data on the page, the schema sub-score reports a page with nothing recognised on it, which is a true statement about our list rather than a judgement about your reviews. Schema is 10 points of the 100 point composite, so the effect is bounded, and the weight itself is a decision somebody made rather than a measurement anybody took. One more setting is worth stating because it changes the number more than the type list does. Markup that exists only after JavaScript runs is scored at a quarter of its value, a cap set at 0.25 in the config. Review widgets are a common place for that to bite, because a third party ratings script frequently injects its JSON-LD client side. This is the same underlying problem as [prose parity](https://lantad.co/glossary/prose-parity): what a browser assembles and what an [AI crawler](https://lantad.co/glossary/ai-crawler) receives are two different documents, and [seeing what a crawler receives](https://lantad.co/tools/what-gptbot-sees) is the one request that settles it for a URL. We have measured that gap elsewhere on this blog when [structured data was measured twice](https://lantad.co/blog/structured-data-measured-twice), once in the raw response and once in the rendered page. ## What to check on your own review markup this week Four checks follow, and only the first is about the new guideline. First, read your own disclosures against the wording. If any review on your site was written in exchange for money, a discount, a voucher or a free product, the guideline requires that the incentivization be disclosed clearly and prominently. Decide where that disclosure lives and whether a reader meets it before they meet the rating. The markup will not carry it for you, and no test will tell you it is missing, which makes this the rare item on a technical checklist that only a person can close. Second, find out whether your review markup is in the served HTML or arrives later. Ratings widgets from third parties are usually script driven, and a JSON-LD block that only exists after the bundle runs is a block that a fetch only client never sees. If you are on a framework that renders on the client by default this is worth checking rather than assuming, and our stack notes for [Next.js](https://lantad.co/fix/nextjs) and for [Shopify](https://lantad.co/fix/shopify) cover where the markup tends to end up on each. Fetching the page as a plain client is the fastest answer and needs no tooling beyond one request. Third, check which type your review markup is attached to. If your pages emit LocalBusiness or another Organization subtype and you also publish testimonials you collect yourself, Google's page states those pages are ineligible for the star review feature regardless of how genuine the testimonials are. That is worth knowing before you spend a sprint on markup that cannot produce the result it was added for, and it is the same class of mistake as marking up a feature that has been retired, which we counted across the ecosystem when [sixteen schema types reached ten million domains](https://lantad.co/blog/sixteen-schema-types-reach-ten-million-domains). Fourth, keep the ambition proportionate. Review markup is an eligibility signal for one Google feature. It is not a general purpose credibility channel, and no vendor documentation we have read states that an answer engine treats a ratingValue as evidence. If the goal is [AI visibility](https://lantad.co/glossary/ai-visibility) rather than stars in a blue link, the questions upstream of markup matter more: whether the crawlers you care about are allowed in, which our [AI crawlers reference](https://lantad.co/tools/ai-crawlers) enumerates, and whether your text is present without JavaScript. Our notes on [getting cited in AI Overviews](https://lantad.co/how-to-get-cited/google-ai-overviews) start from those rather than from schema, and [the research page](https://lantad.co/research) carries the aggregate view of what we have measured across scanned sites. We publish [what our own crawler sends](https://lantad.co/bot) for the same reason we published a post about the limits of our schema list: a tool asking you to check your markup should be checkable itself. ## Questions and answers **What did Google change about review snippets in July 2026?** Google added a guideline to its review snippet documentation about fake and undisclosed incentivized reviews. The documentation changelog records the entry on 24 July 2026 and the review snippet page carries Last updated 2026-07-24 UTC. The guideline states that you should not include fake or undisclosed incentivized reviews on your page or in your structured data markup, and gives two examples: reviews not based on a genuine experience of a product or service, and reviews written in exchange for a benefit such as money, discounts, vouchers or free products that do not clearly and prominently disclose the incentivization. No required property changed, so markup that validated before the update still validates. **Can a structured data validator detect a fake review?** No. Of the nine properties schema.org defines specifically on the Review type, read on 8 August 2026, none records whether a reviewer was compensated, incentivized or verified as a purchaser. A compliant review and a paid undisclosed review can therefore serialize to identical markup, and any checker reading that markup, including Lantad's, is reading the same bytes in both cases. Validation answers whether the required properties are present and usable. It cannot answer whether the review happened. **Does Lantad score Review or AggregateRating markup?** No. Lantad's schema check holds required properties for five types, Organization, Product, Article, FAQPage and BreadcrumbList, plus six subtypes mapped onto Article and Organization. Review and AggregateRating appear nowhere in the scoring library, verified on 8 August 2026. A page whose entire JSON-LD is types we hold no requirements for is capped at the typeless score of 0.4 in the schema sub-score, so review markup alone lands at that cap while review markup beside a Product or Organization block does not. Those are configured settings, not findings. **Why are my pages with reviews not eligible for star ratings?** One documented reason is self operated reviews. Google's review snippet page states that if the entity being reviewed controls the reviews about itself, its pages using LocalBusiness or any other type of Organization structured data are ineligible for the star review feature. That applies however genuine the reviews are, because the restriction is about who operates the collection rather than about the content. Other reasons exist that Lantad has not measured and cannot observe from a page, including the guidelines added on 24 July 2026, which describe facts that are not recorded anywhere in the markup. --- Lantad measures whether AI crawlers can actually read a page: it fetches as a non-rendering crawler, renders as a browser, and reports the gap. Free scan, one URL, no signup. Method and weights: https://lantad.co/methodology | All pages as markdown: https://lantad.co/md | Crawler policy: https://lantad.co/bot