Review schema markup is the structured data that tells Google and other search engines about ratings and reviews on a page. Done correctly, review schema produces star ratings in search results, feeds AI Overviews trust signals, and connects review content to the entity it describes. Done incorrectly, it triggers manual penalties, gets stripped from rich results, or produces nothing because it’s applied to the wrong schema type. The rules around review schema have tightened sharply through 2024 into 2026. Industry analyses tracking the March 2026 Core Update reported reduced rich result eligibility for review markup on pages where reviews weren’t the primary content. Knowing which schema types still produce rich results in 2026 (and which don’t) is where the implementation work starts.
Review schema sits on the page alongside the visible content:
The structured data lives in code on the page, alongside the visible content rather than replacing it. A page that displays customer reviews and shows an average rating can include JSON-LD code that exposes the same information in machine-readable format. Google reads both surfaces and uses the structured data to understand the relationships, verify the visible content, and decide whether to display rich result features.
The schema vocabulary comes from Schema.org. The most relevant types for local businesses are Review (a single review of something), AggregateRating (a summary of multiple reviews into an average rating and count), and the parent entity types (LocalBusiness, Product, Service, Organization) that the review describes. The parent entity decides what kind of rich result the page is eligible for.
The format Google prefers is JSON-LD (JavaScript Object Notation for Linked Data) embedded in the page head. Microdata and RDFa still work, but JSON-LD is cleaner, easier to maintain, and Google’s documented recommendation. All implementation in 2026 defaults to JSON-LD unless a specific technical constraint prevents it.
The value of review schema isn’t just rich snippets. AI Overviews and Gemini-powered search features read review schema as a trust signal during answer synthesis. Businesses with properly implemented review markup give those systems verifiable structured signals that businesses with reviews displayed only as visible content don’t expose, which makes citation easier even when the visible content is similar.
LocalBusiness schema with review markup no longer produces star snippets:
Google discontinued review rich snippets for LocalBusiness schema in 2019 and has not reinstated them. A local business that adds AggregateRating or Review markup to its LocalBusiness schema gets the trust signal benefit but not the visible star rating in search results.
The change matters because outdated guidance still circulates online recommending review markup directly on LocalBusiness schema for star ratings. That implementation produces no visible stars in 2026, which leads businesses to think the schema isn’t working when it is just doing trust-signal work rather than rich-snippet work. The signal still flows. The rich snippet just doesn’t appear.
LocalBusiness schema with review markup retains value for AI Overview eligibility, entity-graph trust signals, and Knowledge Graph reinforcement. The visible-stars goal needs a different schema choice, but the structured data still does work that matters at the entity layer.
Product or Service schema produces star ratings for service pages:
Local service businesses wanting visible star ratings apply Service schema (or Product schema for tangible offerings) to individual service pages, with review markup nested under that schema. A plumber with a “Drain Cleaning” service page applies Service schema with AggregateRating, and the page becomes eligible for star ratings in search results.
Here is what a working Service schema with AggregateRating and individual Review entries looks like for an HVAC company’s AC repair service page:
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Service",
"serviceType": "AC Repair",
"name": "AC Repair in Atlanta",
"description": "Same-day AC repair service for residential and light commercial customers across metro Atlanta. Diagnostic, refrigerant recharge, compressor replacement, and full system repair.",
"provider": {
"@type": "LocalBusiness",
"name": "Peach State HVAC",
"telephone": "+1-404-555-0182",
"address": {
"@type": "PostalAddress",
"streetAddress": "1450 Howell Mill Rd NW",
"addressLocality": "Atlanta",
"addressRegion": "GA",
"postalCode": "30318",
"addressCountry": "US"
}
},
"areaServed": {
"@type": "City",
"name": "Atlanta"
},
"aggregateRating": {
"@type": "AggregateRating",
"ratingValue": "4.8",
"reviewCount": "247",
"bestRating": "5",
"worstRating": "1"
},
"review": [
{
"@type": "Review",
"author": {
"@type": "Person",
"name": "Marcus T."
},
"datePublished": "2026-03-14",
"reviewBody": "Called at 7am with no AC, had a technician at the house by 10. Diagnosed a bad capacitor, replaced it on the spot, system back running in under an hour.",
"reviewRating": {
"@type": "Rating",
"ratingValue": "5",
"bestRating": "5"
}
},
{
"@type": "Review",
"author": {
"@type": "Person",
"name": "Renee D."
},
"datePublished": "2026-02-28",
"reviewBody": "Honest pricing, no upsell pressure. Tech walked me through what was failing and what could wait. Scheduled the larger repair for the following week.",
"reviewRating": {
"@type": "Rating",
"ratingValue": "5",
"bestRating": "5"
}
}
]
}
</script>
The Service schema requires several properties to qualify: a service name, a description, the provider entity (which connects back to the LocalBusiness), the area served, and the review or AggregateRating data. Schema-content alignment matters more than property correctness, and the next section covers it on its own terms.
The AggregateRating implementation includes ratingValue (the average rating, typically 1-5), reviewCount (the total number of reviews), bestRating (the maximum possible, usually 5), and worstRating (the minimum, usually 1). Numbers must match real data. Inflated counts or invented ratings violate policy and trigger manual actions when caught.
Individual Review markup goes deeper, including author name, datePublished, the review body text, and the individual reviewRating value. Including 3-5 individual reviews alongside the aggregate provides Google with content to verify and gives AI Overviews concrete review excerpts to surface in responses.
The trade-off with Service schema is that not every local business has natural service pages. A restaurant, a salon, a retail store, or a dental practice can build service pages for the services or treatments it offers. A general-practitioner business with a single primary service has less natural surface area for Service schema and benefits more from focusing on LocalBusiness trust signals.
| Schema combination | Visible star rating | AI Overview trust signal | Best for |
|---|---|---|---|
| LocalBusiness + AggregateRating | No (since 2019) | Yes | Trust signal building, entity graph |
| Service + AggregateRating | Yes | Yes | Local service businesses with service pages |
| Product + AggregateRating | Yes | Yes | E-commerce, physical products |
| Organization + AggregateRating | No | Limited | General brand-level rating reference |
| Review (standalone) | Limited | Yes | Editorial reviews, comparison content |
Self-serving reviews violate policy and get rich results stripped:
Google’s policy prohibits self-serving review markup: a business marking up reviews about itself, written by the business owner, employees, or anyone with a conflict of interest. The policy distinguishes legitimate review content (customer-written reviews displayed publicly) from manufactured reviews used solely for rich snippet purposes.
The detection mechanism cross-references the schema content with multiple signals:
- Source of the reviews (third-party platform versus only on the business’s own site)
- Review patterns (real customer feedback versus marketing copy)
- Timestamps and author information
- Consistency between schema content and visible page content
Enforcement tightened in 2026. Following the March 2026 Core Update, SEO practitioners reported that sites displaying five-star reviews entirely on their own pages, with no third-party verification, lost rich result display. The visible content remained, but the star ratings disappeared from search results because the algorithm flagged the implementation as self-serving.
The legitimate path is displaying real customer reviews that originate from customer-written content, ideally with some path back to verifiable third-party sources (Google Business Profile reviews, Yelp reviews, industry-platform reviews). Embedding reviews from the GBP onto the website with proper attribution (the reviewer’s first name and last initial, the review date, a link back to the source review on Google) gets the trust benefit without violating policy because the source can be verified.
Markup has to match primary page content:
After the March 2026 Core Update, industry observers documented a sharper enforcement of content-schema alignment: the structured data on a page has to match the primary content topic of the page, not peripheral or supplementary content. Review schema on pages where the reviews aren’t the primary content got demoted or stripped of rich results.
The change affected several common implementations. Editorial comparison posts had included AggregateRating markup for the products being compared, even though the post itself was an article rather than a product page; those posts lost rich result eligibility after the update. FAQ schema on pages where FAQs were supplementary rather than the main content lost visibility. How-To schema on pages where the steps weren’t the primary topic lost rich result display.
For local businesses, the alignment requirement means review schema lives on pages where reviews are visibly central: dedicated review pages, service pages with prominent customer testimonials, GBP-driven landing pages where the reviews are part of the conversion content. Schema on pages where reviews are decorative or supplementary doesn’t produce rich results regardless of correctness.
The diagnostic for alignment is straightforward: if a user reading the page would describe its primary content as something other than reviews and ratings, review schema as the primary structured data doesn’t fit. Either the schema has to move to a more aligned page, or the schema strategy has to use a different type (LocalBusiness for trust signal without rich snippet expectation, Article schema for editorial content).
Aggregate ratings mirror what crawlers see:
The review schema has to reflect what’s on the page in a way Google can verify. AggregateRating values that don’t match displayed review summaries trigger mismatch detection. Rich results get stripped when the mismatch persists. Reviews hidden behind tabs, loaded by JavaScript after page load, or displayed only to logged-in users create alignment problems because the crawler doesn’t see what the schema describes.
The implementation that holds up renders the reviews and ratings in the page’s initial HTML, visible to the crawler, accessible to users. JavaScript-loaded reviews that appear correctly to users but aren’t in the initial render fail the crawl-match test even when the visible experience is correct.
The aggregate calculation has to come from real data. A business with 100 reviews averaging 4.3 stars should mark up reviewCount=100 and ratingValue=4.3. Inflated counts (claiming 100 reviews when 50 exist) or boosted ratings (claiming 4.9 stars when 4.3 is accurate) violate policy and trigger penalties when caught.
For local businesses syndicating GBP reviews to their website, the aggregate data should come from the GBP’s review count and average rather than from invented numbers. Some review platforms (Birdeye, Podium, NiceJob) automate this with embedded widgets that handle the schema correctly while displaying the reviews visibly. Manual implementations work too but require ongoing maintenance to keep the aggregate values accurate as new reviews accumulate.
Individual Review markup adds depth beyond the aggregate:
Adding individual Review markup alongside AggregateRating provides Google with verifiable content rather than just summary numbers. Each Review entry includes author, datePublished, reviewBody, and reviewRating. The algorithm gets concrete data to compare against the visible content and across the web. The summary alone is thinner signal.
The implementation pattern that works includes 3-5 individual reviews alongside the aggregate, with each review representing a real customer interaction. The review body text should be substantive (a sentence or two minimum), authentic (sounds like a real customer rather than marketing copy), and include enough detail to be verifiable as a real review.
For local businesses, the natural source of individual review content is the GBP profile itself. Customers who wrote reviews on Google can have their reviews syndicated to the website with proper attribution, schema markup, and a link back to the GBP profile. The syndication respects the customer’s review while exposing it as structured data on the business’s own surface.
Author names in individual Review markup should be real names from real reviewers rather than generic labels like “Happy Customer” or “Anonymous Reviewer.” Vague author attribution flags the review as manufactured. First names with last initials (the format GBP uses for public review display) work as legitimate attribution.
Photo and date fields strengthen review schema credibility:
Beyond the required properties, several optional fields strengthen the credibility signals of review schema. The datePublished field shows when the review was created, which lets Google evaluate recency. The author field with proper attribution shows the review came from a real person. The image field, when applicable, can include photos the reviewer attached to their review.
For 2026 ranking purposes, review recency has become more important than total volume alone. A business with steady recent reviews (datePublished values in the past 30-90 days) signals active customer engagement; a business with old reviews and no recent activity signals declining engagement even at high aggregate counts. The datePublished field in individual Review markup feeds this recency signal alongside the visible content.
The reviewBody field deserves substantive text rather than placeholder language. Reviews marked up with one-word descriptions (“great”) or generic phrases (“excellent service”) provide less signal than reviews with descriptive content about the actual experience. Match what the customer wrote. Not a summary or edit.
Validation tools catch implementation errors before they ship:
Google provides validation tools that check review schema for correctness before deployment. The Rich Results Test examines a specific URL and reports which rich result types the page is eligible for, which schema is detected, and what errors or warnings exist.
The Schema Markup Validator provides a broader check against Schema.org standards, identifying structural errors, missing required properties, and conformance issues. The Schema Markup Validator catches issues that aren’t strictly Google-specific but still indicate implementation problems.
Common errors the validators catch include missing required properties (an AggregateRating without ratingValue), invalid value types (a reviewCount with non-numeric content), and structural problems (Review markup that doesn’t nest properly under a parent entity). The validation catches these before deployment so the implementation works correctly when it goes live.
The validators don’t catch policy violations. Self-serving reviews, fake aggregate counts, and schema-content mismatches aren’t technical errors. Policy compliance requires editorial discipline beyond what automated validation can check.
Implementation priorities for local businesses in 2026:
The implementation pattern that produces value for local businesses in 2026 combines several schema layers strategically. LocalBusiness schema with AggregateRating on the home page or location pages provides entity-level trust signal and AI Overview eligibility, without expecting visible star ratings. Service schema with AggregateRating on individual service pages provides visible star rating eligibility for service-specific queries. Individual Review markup nested under either schema type adds depth and verification signals.
The maintenance commitment matters as much as the initial implementation. Aggregate values have to update as new reviews accumulate. New individual reviews replace older ones. The schema content has to keep matching what’s visible on the page. Set-and-forget implementations degrade as the visible content evolves and the schema falls behind.
For agencies and consultants implementing review schema across client sites, the audit cadence is quarterly: verify schema is still present, validate against current Google tools, check aggregate values for accuracy, confirm visible content still matches structured data. The maintenance work isn’t visible to users, but the missing maintenance shows up as lost rich results and degraded AI Overview citation.
What changed in 2026 isn’t the underlying schema standards but the enforcement aggressiveness around alignment, authenticity, and policy compliance. The implementations that game the system through inflated counts, self-serving reviews, or schema-content mismatches get caught faster and lose visibility more completely. The implementations that follow the standards honestly accumulate trust signals over time. Those signals compound across rich snippets, AI Overviews, and entity recognition.