Most guidance on review schema still promises the same thing: add the markup, get gold stars in search results. For a local business marking up reviews about itself, that promise has been false since 2019. Google discontinued self-serving review stars for LocalBusiness schema that year and has never brought them back. The markup still runs, the validator still passes, and no stars appear. The gap between what the code does and what shows up in search is where most review-schema effort gets wasted.
Review schema is the structured data that describes ratings and reviews to search engines. Used within the rules, it feeds trust signals and, in a narrow set of cases, produces the visible star rating. Used against them, it produces nothing, or gets rich results stripped, or draws a manual action. The rules tightened through 2024 into 2026, so the first job is knowing which schema still earns rich results and which quietly does not.
Where review schema lives and what it is made of #
The structured data sits in code on the page, alongside the visible content rather than replacing it. A page that shows customer reviews and an average rating can include JSON-LD that exposes the same information in machine-readable form. Google reads both surfaces, cross-checks the structured data against the visible content, and decides whether the page qualifies for a rich result feature.
The vocabulary comes from Schema.org. The types that matter for local businesses are Review (a single review of something), AggregateRating (multiple reviews summarized into an average and a count), and the parent entity the review describes: LocalBusiness, Product, Organization, or Service. The parent entity decides what kind of rich result, if any, the page is eligible for, and that is the point most implementations get wrong. Google’s documented format preference is JSON-LD embedded in the page; Microdata and RDFa still work, but JSON-LD is cleaner to maintain and is the recommendation Google states in its own structured-data documentation.
LocalBusiness review markup no longer produces stars #
Google stopped showing review stars for LocalBusiness and Organization schema when the entity controls the reviews about itself. That change dates to September 2019 and remains in force in 2026. A local business that adds AggregateRating or Review markup to its own LocalBusiness schema gets no visible star rating in search results.
The reason outdated advice persists is that the markup does not error. It validates, it deploys, and nothing visible happens, so businesses assume the schema is broken when the policy is doing exactly what it was designed to do. Per Google’s review snippet documentation, LocalBusiness and Organization are eligible for review stars only on sites that capture reviews about other businesses or organizations, not about themselves.
The self-serving definition is broad. It covers reviews on the reviewed entity’s own site whether they sit directly in the structured data or arrive through an embedded third-party widget, including Google Business Profile or Facebook review widgets. Syndicating your own GBP reviews onto your own site does not escape the rule: if you control the entity being reviewed, that path does not produce stars.
Which parent types can still earn a visible star rating #
Google’s review snippet documentation lists the types eligible for review rich results: Book, Course, Event, LocalBusiness, Movie, Product, Recipe, SoftwareApplication, and Organization, plus several creative-work types. For a local business, the practical route to a visible star rating is Product schema on a specific product, because Product is explicitly documented and reliably rendered.
Service schema is the tempting shortcut, and it needs a caveat the older guidance skips. Service is valid at Schema.org and can carry aggregateRating, but Google does not document Service in its review snippet guidelines the way it documents Product. Review snippets on Service markup may appear, but they are not guaranteed and Google could stop showing them without notice. If a visible star rating is the goal and it needs to hold up, Product schema on a concrete offering is the dependable choice; Service is a maybe, not a mechanism.
| Schema combination | Visible star rating | Trust signal for AI answers | Best used for |
|---|---|---|---|
| LocalBusiness + AggregateRating (own reviews) | No, since 2019 | Yes | Entity-graph trust, not rich snippets |
| Product + AggregateRating | Yes, documented | Yes | Specific products a business sells |
| Service + AggregateRating | Sometimes, not guaranteed | Yes | Service pages, with expectations set low |
| Organization + AggregateRating (own reviews) | No | Limited | Brand-level reference only |
| Third-party listing site (Yelp, directories) | Yes | Yes | The reliable star path for the business name itself |
For the business name itself, the dependable way to surface stars in search is a claimed listing on a third-party platform such as Yelp or an industry directory, because those sites capture reviews about other businesses and remain eligible. That is a different lever from on-site schema, and it is worth naming plainly rather than promising on-site markup will do a job it cannot.
Self-serving reviews get rich results stripped #
The self-serving rule is not only a LocalBusiness limitation; it is an enforcement target. Google’s policy separates legitimate review content, meaning customer-written reviews displayed publicly, from reviews a business manufactures about itself for snippet purposes. Detection cross-references several signals: whether reviews originate on a third-party platform or only on the business’s own site, whether the language reads like real customer feedback or marketing copy, timestamp and author information, and consistency between the schema and the visible page.
The durable rule here predates any recent update: since 2019, review rich results have not been eligible for self-serving markup, meaning star ratings a business places on its own pages about itself. Some practitioners reported additional star-display losses around the March 2026 core update for pages relying on self-hosted five-star reviews, but Google confirmed only that March 2026 was a broad core update and made no statement about review schema specifically. Those reports are unconfirmed observation, not an established rule, and should be weighed as such. Either way, the durable path is real customer reviews that trace to verifiable sources, and when the business itself needs the star rating in search, the eligible surface is the third-party platform, not its own domain.
Markup has to match the primary content of the page #
A second principle here is long-standing Google guidance, not a recent shift: structured data has to represent the primary content of the page, not peripheral content, so review markup on pages where reviews are not the main content may be ignored or dropped from rich results. Some practitioners reported that enforcement of this alignment tightened after the March 2026 core update; that timing is unconfirmed practitioner observation, but the underlying rule (match markup to the page’s main topic) is documented and durable regardless.
The reported effects fell on predictable implementations. Editorial comparison articles that carried AggregateRating for the products they discussed lost eligibility, because the page is an article, not a product page. FAQ and How-To markup on pages where those elements were supplementary rather than the main topic lost visibility too.
For local businesses, alignment means review schema belongs on pages where reviews are visibly central: a dedicated reviews page, a service or product page with prominent customer testimonials, a landing page where the reviews are part of the conversion content. The diagnostic is simple. If a visitor would describe the page as being about something other than reviews and ratings, review schema as the page’s primary structured data does not fit, and the schema should either move to a page where reviews lead or switch to a matching type such as Article for editorial content.
Aggregate ratings have to mirror what crawlers see #
The schema has to reflect what is on the page in a way Google can verify. AggregateRating requires ratingValue plus at least one of ratingCount or reviewCount, and those numbers have to match the reviews visible on the page. Values that contradict the displayed summary trigger mismatch detection, and rich results get stripped when the mismatch persists. Rendering matters as much as accuracy: reviews hidden behind tabs, injected by JavaScript after load, or shown only to logged-in users create alignment problems, because the crawler does not see what the schema claims. The implementation that holds up renders the reviews and the rating in the initial HTML.
The aggregate has to come from real data. A business with 100 reviews averaging 4.3 marks up a count of 100 and a value of 4.3. Inflating the count or boosting the rating violates policy and draws manual action when caught. For businesses pulling from a GBP profile, the count and average should come from that profile rather than from invented numbers, and the values need ongoing maintenance as new reviews arrive.
Individual reviews, credibility fields, and validation #
Including a handful of individual Review entries alongside the aggregate gives Google verifiable content rather than summary numbers alone. Each entry carries author, datePublished, reviewBody, and reviewRating, and Google’s documentation notes that when you include individual reviews you should also include an aggregate rating of them. Three to five real reviews with substantive body text provide more signal than the aggregate by itself. Author names should be real, in the first-name-plus-last-initial form used publicly, not generic labels like “Happy Customer,” which flag a review as manufactured. The datePublished value also lets Google gauge recency, which has grown in weight relative to raw volume; steady recent reviews signal an active business more clearly than a large but stale count, and the reviewBody deserves the customer’s real words rather than a one-word “great.”
Google’s validation tools catch the technical faults before deployment. The Rich Results Test reports which rich result types a URL is eligible for and which schema is detected; the Schema Markup Validator checks conformance against Schema.org standards more broadly. Between them they catch missing required properties, invalid value types, and broken nesting. What they do not catch is policy. Self-serving reviews, inflated counts, and content mismatch are not validation errors, so passing the validators says nothing about whether the implementation complies. That part takes editorial discipline.
What actually works in 2026 #
The pattern that produces value combines layers with honest expectations for each. LocalBusiness schema with AggregateRating on the home or location pages builds entity-level trust and feeds AI-driven search features, with no expectation of visible stars. Product schema on specific products carries the reliable path to a visible star rating on-site. A claimed third-party listing carries the star rating for the business name itself. Individual Review entries add depth wherever they sit.
Maintenance matters as much as setup, because aggregate values drift as reviews accumulate and the schema has to keep matching the visible page. A sensible cadence for agencies managing this across sites is quarterly: confirm the schema is present, revalidate against current tools, check the aggregate for accuracy, and verify the visible content still matches. What changed in 2026 was not the schema standards but the aggressiveness of enforcement around alignment, authenticity, and self-serving policy. Implementations that game the system get caught faster; the honest ones accumulate trust that compounds across rich snippets, AI answers, and entity recognition. If you do one thing first, confirm which of your review pages are even eligible under the self-serving rule before writing a line of markup.