Google's review guideline asks for something the markup cannot record

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 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 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, 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 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 rather than emit a confident wrong one, and why the 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 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: what a browser assembles and what an AI crawler receives are two different documents, and seeing what a crawler receives 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, 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 and for 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.

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 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 enumerates, and whether your text is present without JavaScript. Our notes on getting cited in AI Overviews start from those rather than from schema, and the research page carries the aggregate view of what we have measured across scanned sites. We publish what our own crawler sends 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.