Review Schema Markup: Where Stars Are Allowed, Where They Are Banned

Reading time: 11 minutes

Most guides to review schema open with implementation. This one opens with the rules, because the single most common structured-data mistake we find on Ontario business websites is review markup that validates perfectly and has been ineligible for stars since 2019. The code is correct. The policy killed it anyway. If you learn the eligibility rules first, the implementation is twenty minutes of work; learn them second and you may spend those twenty minutes building something Google is contractually committed to ignoring.

Review vs AggregateRating: two objects, one rulebook

Schema.org gives you two vocabulary objects for opinion data, and Google's review snippet documentation accepts both. A Review is a single opinion: it carries an author, a reviewRating (itself a Rating with a ratingValue and, ideally, bestRating), and usually a reviewBody. An AggregateRating compresses many opinions into three numbers: ratingValue, the scale, and a reviewCount or ratingCount.

The detail that trips people up is nesting. Neither object is meant to float free on a page. Google's documentation is explicit that a review should sit inside the schema of the thing being reviewed: a Product carries its aggregateRating as a property, a Course carries its reviews as properties, and so on. A standalone Review block pointing at some item defined elsewhere is the pattern Google's guidelines specifically discourage, and orphaned rating objects are one of the first things our audits flag. This whole discipline is Vector 6, Structure, in the 12 Vectors framework: the machine can only trust data whose relationships are declared, not implied.

The September 2019 rule that still decides everything

In September 2019 Google announced, on the Search Central blog, that review rich results would no longer be shown for LocalBusiness and Organization types when the reviews are "self-serving": placed on the entity's own website, about that entity, whether typed into the markup directly or piped in through an embedded third-party widget. Nearly seven years later this remains the live policy, restated in the current review snippet documentation, and it is the rule everything else in this guide hangs from.

The reasoning is hard to argue with. A rating a business publishes about itself carries no independent information. Every plumber who added stars to their own homepage chose a number between 4.7 and 5.0, so the stars stopped discriminating between good plumbers and bad ones and became pure decoration. Google removed the decoration. What stings for site owners is that validators never got the memo in a visible way: the Rich Results Test will still cheerfully approve a self-serving AggregateRating on a LocalBusiness page. Valid and eligible are different tests, and only the second one pays.

Where review markup is still allowed in 2026

Eligibility follows the type of the thing reviewed, not the type of the site. Google's current documentation lists the content types that can still produce review snippets, and the pattern is consistent: they are all items a third party could plausibly have an opinion about, rather than the publishing entity itself.

Notice what the third row implies: business reviews are not banned from schema in general. A Brantford news outlet reviewing five local roofers can mark those reviews up and earn stars, because the reviewer and the reviewed are different entities. The prohibition attaches to control, not to category. If the entity being rated controls the page carrying the rating, eligibility is gone.

For retailers, the allowed path runs straight through product pages, and it is worth real money: customer reviews marked up on individual products still generate stars in both classic results and Google's shopping surfaces. We cover the mechanics, including the offer and rating requirements, in our guide to product schema for e-commerce.

Where review markup is dead weight or worse

Three configurations show up constantly in audits, and none of them can pay off.

• Self-rating on LocalBusiness or Organization. The 2019 rule, covered above. Harmless to rankings in our experience, but it clutters the graph and signals to any human reviewer that nobody has looked at the site's structured data in years.
• Widget-injected third-party ratings. Embedding a review platform's widget so its stars land in your own page's markup is called out by name in Google's policy. The platform's domain can hold the eligible markup; yours cannot borrow it.
• Ratings that do not match the page. Even on eligible types, the marked-up numbers must reflect reviews a visitor can actually read on that page. A 4.9 in the code beside a 4.6 on the screen is the kind of mismatch that costs more than a rich result; it reads as deception to the quality systems Google has been pointing at structured data since the May 2026 core update.

There is a fourth case that is not banned but is wasted effort: marking up review content that never renders visibly. Hidden review text with visible-looking schema fails Google's basic requirement that marked-up content be present on the page. If a review matters enough to encode, it matters enough to show.

A valid example for an allowed case

Here is a complete, policy-clean block for the case that still works: a product page with genuine customer reviews displayed on it. This validates and, unlike the LocalBusiness version, remains eligible.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Hybrid Pocket-Coil Mattress, Queen",
  "image": "https://example.com/images/hybrid-queen.jpg",
  "description": "Medium-firm hybrid mattress with pocket coils and a cooling foam layer.",
  "sku": "HYB-Q-2026",
  "brand": { "@type": "Brand", "name": "Example Sleep Co." },
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.6",
    "bestRating": "5",
    "reviewCount": "187"
  },
  "review": [
    {
      "@type": "Review",
      "author": { "@type": "Person", "name": "S. Whitfield" },
      "datePublished": "2026-06-02",
      "reviewBody": "Firmer than expected for the first week, then it broke in nicely. Sleeps cool.",
      "reviewRating": {
        "@type": "Rating",
        "ratingValue": "4",
        "bestRating": "5"
      }
    }
  ],
  "offers": {
    "@type": "Offer",
    "url": "https://example.com/mattresses/hybrid-queen/",
    "priceCurrency": "CAD",
    "price": "1099.00",
    "availability": "https://schema.org/InStock"
  }
}
</script>

Points worth copying rather than improvising: the rating objects nest inside the Product; bestRating is declared so a 4-of-5 cannot be misread as 4-of-10; the reviewCount and ratingValue must equal the figures shown to shoppers on this URL; and the review is attributed to a named author because Google requires one. Swap the placeholder values for your real catalogue data and nothing else needs to change structurally.

On-site reviews vs third-party platforms: where the strategy actually lives

Once the self-serving rule sinks in, the strategic question changes shape. If your own pages cannot earn stars for your business, where do the stars a customer actually sees come from? Three places, none of which involve your markup.

First, your Google Business Profile. Its reviews power the ratings in the local pack and Maps, they were never touched by the 2019 change, and for a service business they are now the dominant rating surface. Second, third-party platforms with their own domains: review sites and directories carry eligible markup about you because they are not you. Third, and increasingly, the AI answer layer. When ChatGPT or Perplexity is asked for the best mattress store in Brantford, the models weigh review signals gathered from across those independent surfaces; there is no schema tag on your site that injects a rating into that answer. Which means review strategy in 2026 is mostly reputation operations, not markup: earning reviews steadily, distributing them across surfaces the machines already trust, and answering the bad ones properly. That last part has its own craft, and we wrote it up in how to respond to negative Google reviews; the operational side is what our review management service exists to run.

Regulated professions: when the testimonial itself is the problem

For a slice of Ontario businesses the schema question is moot, because the profession's regulator restricts the content a layer above the code. The College of Massage Therapists of Ontario is the clean example: its Standard of Practice on advertising prohibits testimonials in RMT advertising outright. A massage therapist cannot publish client endorsements on their own website at all, marked up or not. Several other health colleges, including the College of Physicians and Surgeons of Ontario, maintain similar restrictions, and law society advertising rules add their own constraints for lawyers.

The workable distinction, in CMTO's framing, is between solicited endorsements the practitioner uses in advertising, which are prohibited, and independent reviews clients post on platforms the practitioner does not control, which are generally outside the ban. That maps neatly onto the search reality described above: the compliant review presence for a regulated practitioner is the one Google already prefers, reviews accumulating on independent surfaces, with the practitioner's own site earning trust through credentials, registration numbers, and clear scope-of-practice content instead. We hit this exact constraint building out a client site for a Brantford RMT, and the honest conclusion was that the regulator's rule and Google's rule point the same direction.

Common mistakes that quietly kill eligibility

Beyond the self-serving trap, these are the recurring faults we log on pages that should qualify and do not:

• No bestRating on a non-5-point scale. Google assumes 5 unless told otherwise; a 8.7 out of 10 without the scale declared becomes nonsense.
• Missing or organizational-only authors. Reviews need a named author, and Google's guidance says the name must be a real person or team, not "Anonymous" or the business itself.
• Markup on the wrong page. Ratings summarized on a category page while the reviews live on detail pages breaks the visible-content requirement in both directions.
• Stale counts. The schema said 187 reviews in January and the page shows 240 in July because the plugin cached the block. Automate the number or audit it quarterly.
• Duplicated graphs. A theme, an SEO plugin, and a review app each emitting their own rating objects for the same item, with different values. Pick one source of truth and suppress the rest.

If you run a local business: what to build instead of stars

The unsatisfying truth is that a Brantford contractor or clinic cannot markup its way to stars on its own site, and any vendor promising otherwise is selling a 2018 tactic. What the site's structured data can still do is make the business unambiguous to machines: a complete LocalBusiness graph with exact NAP, geo coordinates, hours, and service definitions, minus the ineligible rating block. That work has real payoff in the local pack and in AI answers even though it earns no decoration, and we walk through it property by property in the local business schema guide.

Then point the persuasion budget where ratings still render: the Business Profile, the independent platforms, and the review velocity that feeds both. In our client work the sites winning local AI recommendations are consistently the ones with active, well-answered third-party review streams and clean entity data, not the ones with the fanciest on-site rating widgets. The stars did not disappear in 2019; they moved off your domain. Strategy has to move with them.

If you would rather have a person read your graph than decode Google documentation, get in touch. Structured-data cleanup is finite, unglamorous work with a clear before and after, which is exactly the kind we like invoicing for.