Review schema: 33 of 615 home pages declared a rating, and 14 rated their own business

What does review schema have to be attached to for a star to be possible?

Two types do the work and they are not interchangeable. schema.org/Review describes one person's verdict, with an author and usually a reviewBody. schema.org/AggregateRating describes the summary of many, and schema.org defines only three properties of its own on it: itemReviewed, ratingCount and reviewCount. Everything else it carries, including ratingValue and bestRating, it inherits from Rating. That entry, read on 27 September 2026, puts the type in the 1M to 10M domains usage band, attributed to monthly aggregations from Google web index data for August 2026, which sits oddly beside the 33 of 615 counted below and is the same order of magnitude as the sixteen schema types that reach ten million domains.

Google's requirements are narrower than schema.org's vocabulary, which is the usual relationship between the two and the reason a page can be valid markup and still earn nothing. Google's review snippet documentation, carrying Last updated 2026-09-08 UTC when it was read on 27 September 2026, requires a ratingValue on an AggregateRating, requires itemReviewed unless the rating is nested inside the item it rates, and states that at least one of ratingCount or reviewCount is required. It also fixes the arithmetic: the default scale for numbers is a five point scale where 1 is the lowest and 5 the highest, and if bestRating is omitted, 5 is assumed.

The part that decides eligibility is not a property at all, it is the type the rating hangs from. The same page lists the features a rating can produce: Book, Course list, Event, Local business, Movie, Product, Recipe and Software App, plus a further set of schema.org types including Organization, Game, MediaObject and the CreativeWorkSeries family. Two of those entries carry a parenthesis that turns out to matter more than anything else measured here. Local business is supported "only for sites that capture reviews about other local businesses", and Organization "only for sites that capture reviews about other organizations". A rating attached to anything outside the list is markup a validator will accept and a search feature will ignore, which is the same failure mode as a JSON-LD block with a syntax defect except that nothing reports it.

How many home pages declare a rating at all?

33 of the 615, which makes it the least used of the markup properties this corpus has been measured for. For comparison against runs on the same hostnames, 615 pages carried parseable JSON-LD and 313 of them put an @id on no node, 186 carried an inLanguage value and 201 of 936 interior pages declared a BreadcrumbList. A rating is rarer than all of them by a wide margin, and rarer again than the 21 of 270 video-carrying pages that declared video schema.

The 33 hosts held 73 aggregateRating nodes between them, and that total is almost meaningless without one correction: 39 of the 73 are on a single hotel chain, meininger-hotels.com, which declares a chain-level score and then a separate Hotel node with its own rating for each property. 30 of the 33 hosts declared exactly one node. Anybody reading the node count as a measure of how common this markup is would be reading one site.

Where it appears follows what the site sells rather than how large it is. The software strata account for most of it: 9 of the 88 saas hosts with parseable JSON-LD, 4 of 25 in saas-marketing, 5 of 18 Webflow sites and 3 of 35 WordPress sites. The four strata where a rating never appeared once are government at 0 of 28, education at 0 of 31, healthcare at 0 of 45 and finance at 0 of 53, which is 157 pages carrying readable markup and not one rating between them. That is not an oversight in 157 places. A public body and a bank have nothing they would put a star on, and the absence is a statement about what the vocabulary is for, not a gap in anybody's AI visibility work. The ecommerce stratum returning 1 of 40 is more surprising, given that 42 of 50 product pages declared a Product node when this corpus was walked to an add to cart control: ratings live on product pages, and a home page is not one.

Why 14 of the 33 cannot earn a star

53 of the 73 nodes sat on a LocalBusiness type or an Organization type, and on 14 of the 33 hosts every rating did. The types themselves are on Google's supported list, so a validator passes them and the Rich Results Test will draw the preview. The guideline underneath is what excludes them, and it is stated without hedging: "If the entity that's being reviewed controls the reviews about itself, their pages that use LocalBusiness or any other type of Organization structured data are ineligible for star review feature." The documentation spells out the case in the next sentence, naming a review about entity A placed on the website of entity A, either directly in their structured data or through an embedded third-party widget.

That the 14 are exactly this case was checked rather than assumed. On every one of them the rated node names the site's own business and, where it declares a url, that url is the site itself: fibilaw.com rates a LegalService named Fibi Law, thewireguyelectric.com rates an Electrician named The Wire Guy Electric, roberthalltaxes.com rates an AccountingService named Robert Hall & Associates, etobicokerehab.com rates a MedicalBusiness, fasthosts.co.uk rates a Corporation named Fasthosts Internet LTD with 21,521 reviews, and coolblue.nl and meininger-hotels.com each rate themselves through a standalone AggregateRating whose itemReviewed names the company. None of these is a review site. Each is a business publishing its own score on its own front page, which is the arrangement the guideline describes.

The remaining 19 nodes across 18 hosts sit on types the caveat does not touch: 12 on SoftwareApplication, 6 on Product and 1 on WebApplication. A software company publishing an aggregate rating of its own software is not covered by the self-serving rule, because SoftwareApplication is not an Organization type, and whether that distinction is principled is not a question this measurement can answer. One further node, on motel-one.com, hangs from a parent object that declared no @type at all, so there is no type to assess: 88 out of a bestRating of 100, attached to nothing the vocabulary recognises.

Two things this does not establish. It does not say the 14 are breaking a rule, because publishing your own rating is not prohibited, it is only ineligible for the star feature, and several of the 14 may be showing figures sourced from a third party platform in good faith. And it says nothing about what an answer engine does with any of it. Google's review snippet documentation describes a Search feature, AI Overviews eligibility is documented separately and much more thinly, and no crawler vendor publishes what it does with an aggregateRating. What was measured is the markup, the type it hangs from, and the guideline as published.

What the 33 got right, which is the part anything automated can check

The inconvenient finding for a post shaped like this one is that the mechanical requirements were met without exception. All 73 nodes carried a ratingValue. All 73 carried at least one of ratingCount or reviewCount, the property Google says at least one of is required: 62 carried reviewCount, 13 carried ratingCount and 2 carried both. Not one node omitted both. All four standalone nodes, the ones that do not nest inside the item they rate and therefore need itemReviewed, carried it.

That result is worth stating plainly because it inverts the usual shape of these runs. When this corpus was read for FAQ markup, 298 of 1,277 declared answers were not on the page. When it was read for author markup, 8 of 63 Person nodes named a brand rather than a human. Those are populations where the required fields are present and wrong. Here the required fields are present and correct, and the thing that fails is a sentence of policy in prose that no validator reads, on pages whose owners have plainly taken some care.

That asymmetry is the practical lesson and it generalises past review markup. A structured data validator checks shape. Eligibility rules are written about provenance and context: who collected the rating, who controls it, whether the page the markup sits on is the right kind of page. This site has made the same point about Google's guideline on undisclosed incentivized reviews, where none of the nine properties schema.org defines on Review records whether the reviewer was paid, so a compliant page and a non-compliant one serialise to identical markup. The rating case is the same gap from the other direction: here the markup is right and the arrangement around it is what disqualifies the page, and the tooling can see only the half that is fine. Lantad's own scoring and methodology reads shape too, and it detects none of this.

Four ratings above five, one letter grade, and two different scores for one company

Value was declared carefully and scale was not. 64 of the 73 nodes named a bestRating and 9 did not, which is defensible for a score out of five because the documentation supplies that default explicitly, and all 9 of those values do sit at or below 5. worstRating fared worse at 19 of 73, which matters less for the same reason.

Four nodes declared a value above five, and all four declared the bestRating that makes them readable: fattureincloud.it at 8.2 and coolblue.nl at 9.1 against a bestRating of 10, meininger-hotels.com at 85 and motel-one.com at 88 against a bestRating of 100. This is correct markup and it is the case most likely to be mishandled downstream, because a consumer that reads ratingValue and assumes the documented default turns 85 out of 100 into 85 stars. That is not a hypothetical about crawlers in general: it is the arithmetic the documentation itself implies for anything that skips the sibling property, and the reason bestRating exists.

Three individual results are worth naming. webnames.ca declares a ratingValue of "A+" with a bestRating of "A+" and a ratingCount of 1, which is a letter grade rather than any of the three forms the documentation names, so there is nothing for a consumer to average. coolblue.nl carries two standalone AggregateRating nodes on one page, both with an itemReviewed named Coolblue: 9.1 out of 10 across 135,966 reviews, and 3.8 out of 5 across 158,434 reviews. Converted to a common scale those are 4.55 and 3.8 out of 5, so the same page states two different scores for the same company from two different review counts, and nothing in the markup says which is current. motel-one.com's count moved between two reads on the same day, 351,442 on the first request and 351,210 on the second, which is a live figure behaving like one rather than a defect, and a reminder that any single reading of this field is a timestamp.

Across the 68 nodes on a five point scale the distribution is what anybody who has looked at published ratings would expect: the median is 4.4, 33 are 4.5 or better, 7 are below 4.0 and the lowest is 3.4. At host level, 26 of the 30 hosts with a five point rating declared 4.5 or better and 6 declared exactly 5.0. Nothing here measures whether those numbers are true, and four of the six perfect scores rest on five reviews or fewer, one of them on a single review. A rating is a claim like any other in markup a crawler reads, and the count beside it is the only thing on the page that qualifies it.

Ten sites declared a rating the served page never showed

Google's guidance on review markup asks that the marked up content be the content a person sees. On 10 of the 33 hosts, no declared rating value appeared anywhere in the visible text of the page served to this scanner: povio.com, spellbook.legal, etobicokerehab.com, evolvehealing.net, sedai.io, dropbox.com at 4.8, hubspot.com at 4.5, livechat.com at 4.6, webnames.ca and motel-one.com. 23 hosts had at least one declared value appear. Each of dropbox.com, hubspot.com, livechat.com and motel-one.com was requested a second time the same day and reproduced the result.

The same split runs through the individual reviews, and there are very few of them. 14 hosts declared a Review node, 62 between them. Every one of the 62 named an author, which is the property Google marks required, and 57 carried a reviewBody. Of those 57 bodies, 33 appeared in the text the page served and 24 did not. Only 34 of the 62 carried a reviewRating, so nearly half the individual reviews in this sample state an opinion with no score attached. 24 of the 33 hosts with an aggregate rating declared no individual review at all, and 5 hosts declared reviews with no aggregate, which is the less common and more honest of the two shapes.

One limit governs every figure in this section and it cuts the same way as it does on structured data values that are not on the page. No JavaScript was executed, so a rating written into the page during hydration counts as absent here, and on a site that renders its reviews client side it certainly is absent to a crawler that does not run scripts, which is most of them. That is a real finding about what a crawler is served and not a claim about what a human sees in a browser. If you want the same comparison on your own pages, what GPTBot sees makes the two views side by side, and the scanner identifies itself so the request is traceable in your logs.

Two further limits. One page was read per hostname, so every figure describes home pages and not sites, and a rating living on a product page or a pricing page is invisible to this run by construction. And the corpus is an editorial sampling frame assembled for platform and industry coverage, not a random draw of the web, so all of this supports statements about these 1,419 hostnames and nothing wider.