7 Steps to Implement Review Schema Markup for Site Owners and Marketers

Review schema is structured data that describes a review or an aggregate rating so search engines can understand it and potentially display it as a rich snippet. It applies only to pages that already show visible review or rating content to users. Google may display stars or a review count for eligible pages, but this depends on using the correct type, including required properties, and matching what readers actually see on the page.

TL;DR:

Review schema requires author, reviewRating, and itemReviewed properties to qualify for rich snippets, with ratingValue being a critical element.

Accurate matching between markup ratings and visible page content is essential; discrepancies are the leading cause of rich result rejection.

Embedding JSON-LD in server-side code simplifies maintenance, especially across large sites, and helps prevent client-side rendering issues.

Regular validation with Google's Rich Results Test, Schema Markup Validator, and Search Console ensures ongoing eligibility and catches errors early.

Maintaining review schema as a live, owned system rather than a one-time setup helps preserve rich result eligibility amid content updates and site changes.

Seohoneybadger

Turn Local Searches Into Calls

Honey Badger SEO helps local businesses improve Google visibility through hands-on SEO, website creation, and Google Business Profile management.

Explore Honey Badger SEO

What review schema is and the main types
Required and recommended properties for review markup
Code examples for JSON-LD, Microdata, and RDFa
Step-by-step implementation from schema to deployment
Testing, validating, and monitoring your markup
Common mistakes and how to fix them
Scaling review schema across a whole site
What client work has taught me about review schema
How Honey Badger SEO handles review schema for local businesses
Where to verify the rules yourself
Sources
FAQ

What review schema is and the main types

Review schema comes from Schema, which describes a single opinion about something, and its companion, AggregateRating, which summarizes many reviews into one score. The two solve different problems. A Review captures one person's written opinion, a star rating, and the item being reviewed. An AggregateRating captures a summary number, like 4.6 out of 5, based on a count of ratings or reviews. You rarely mark up an AggregateRating without reviews behind it, and you rarely need to mark up every individual review on a page with dozens of them.

Where you place the markup matters as much as which type you choose. A standalone editorial review, like a restaurant critique or a product test, can carry Review directly. A product listing or a local business page usually nests Review and AggregateRating inside the parent type, such as Product or LocalBusiness, so search engines know what the rating refers to.

Two subtypes clarify intent for more specialized markup:

UserReview applies to reviews written by regular consumers, common on e-commerce and service pages.
CriticReview applies to professional or editorial assessments, such as a journalist's evaluation of a product or venue.

Choosing the wrong subtype rarely breaks eligibility outright, but it can misrepresent the content's origin to both search engines and readers, which matters more on pages mixing consumer and editorial opinions.

Required and recommended properties for review markup

Google's structured data guidelines set a clear floor for what a Review needs to qualify, and a separate floor for AggregateRating. Getting these fields right is the difference between markup that renders as a rich result and markup that Search Console quietly ignores.

For a Review, Schema.org's Review type and Google's documentation point to three properties that carry the most weight:

author, naming the person or organization who wrote the review, since anonymous reviews are not eligible for rich results.
reviewRating, the score given, nested with its own ratingValue.
itemReviewed, the specific product, business, or creative work being reviewed, which anchors the review to something concrete.

For an AggregateRating, Schema.org's AggregateRating type requires a ratingValue plus at least one of ratingCount or reviewCount. Without one of those two counts, the aggregate has no evidence behind it and Google will not treat it as valid.

Google's structured data guidelines note that including recommended properties like datePublished and bestRating/worstRating gives search engines more context about a review's scale and timing, according to Google's review snippet documentation, which improves how confidently the result can be shown.

Beyond the required fields, a handful of recommended properties consistently improve eligibility and presentation:

datePublished signals freshness, which matters more for editorial reviews than for ongoing product ratings.
bestRating and worstRating define the scale, since a "9" means something different on a 10-point scale than a 5-point one; without them, AggregateRating defaults to a 5-point scale per Schema.org.
reviewBody supplies the actual text of the review, which strengthens the connection between markup and visible content.
positiveNotes and negativeNotes summarize pros and cons for editorial or comparison reviews, giving structured shape to what would otherwise be prose.

None of these recommended fields are mandatory, but skipping all of them tends to produce markup that technically validates while doing little to help a page stand out in results.

Code examples for JSON-LD, Microdata, and RDFa

JSON-LD is the format Google recommends and the one most CMS platforms and generators default to, since it sits in a single script block separate from the visible HTML. Microdata and RDFa embed the same properties directly inside HTML tags, which some legacy systems still rely on but which is harder to maintain at scale.

A minimal single review in JSON-LD looks like this:

{
  "@context": "https://schema.org/",
  "@type": "Review",
  "itemReviewed": {
    "@type": "LocalBusiness",
    "name": "Example Dental Clinic"
  },
  "author": {
    "@type": "Person",
    "name": "Jordan Lee"
  },
  "reviewRating": {
    "@type": "Rating",
    "ratingValue": "5",
    "bestRating": "5"
  },
  "reviewBody": "Friendly staff and a painless cleaning appointment."
}

A nested pattern combining Review and AggregateRating inside a Product or LocalBusiness is the most common real-world use case, since most pages show one aggregate score backed by many individual reviews rather than a single standalone review.

Format	Best used for	Maintenance effort
JSON-LD	New builds, CMS templates, headless sites	Low, isolated script block
Microdata	Legacy HTML templates already using itemprop attributes	Medium, tags mixed into markup
RDFa	Sites already using RDFa for other vocabularies	Medium to high, requires vocabulary alignment

Whichever format you choose, the values in the markup must match what a visitor actually sees on the page. If the JSON-LD states a 4.8 rating from 212 reviews, the page needs to display that same score and count somewhere a person can read it. This visible-content matching requirement is the single most cited reason legitimate-looking markup gets rejected.

Step-by-step implementation from schema to deployment

Adding review schema safely is less about writing correct code once and more about building a repeatable process. The steps below apply whether you are hand-coding a single page or rolling markup out across thousands of templated pages.

Identify page intent first. Decide whether the page is a product listing, a local business profile, or an editorial review, since Google applies different rules to merchant and product structured data than to independent editorial reviews.
Choose the correct type and subtype. Use Product or LocalBusiness with nested Review and AggregateRating for commercial pages, and standalone Review with CriticReview for editorial content.
Generate the JSON-LD. Hand-write it for a handful of pages, or use a generator like the free JSON-LD schema tool from BabyLoveGrowth to produce a starting template you then customize.
Embed the markup server-side. Place JSON-LD in the page's HTML at render time rather than injecting it after the page loads, since search engines process the initial server response more reliably than late client-side changes.
Run a pre-deploy checklist. Confirm the rating value, count, author name, and review text in the markup match what a visitor sees, and confirm value formats (numbers as numbers, dates in ISO format).
Test before publishing. Validate the markup and fix any errors before it goes live, not after.
Roll out incrementally. Push the markup to a small template set or a handful of URLs first, watch for errors, then expand to the rest of the site.

Pro Tip: Keep a single source-of-truth template for review markup fields across your CMS, so a formatting fix in one place updates every page instead of requiring a page-by-page patch.

For headless setups, where content is fetched via API and rendered on the client, the safest pattern is to generate the JSON-LD server-side during the build or render step rather than injecting it with client-side JavaScript after the page loads. Search engines can often process JavaScript-rendered content, but server-rendered markup removes the guesswork. Teams managing dozens of location or product pages benefit from a emulating approach: one JSON-LD template with variables pulled from a database, rather than hand-editing markup per page, which is where most inconsistencies creep in.

Testing, validating, and monitoring your markup

Three tools cover three different jobs, and mixing them up wastes time. Google's Rich Results Test checks whether a specific page qualifies for a Google-specific feature like the review rich snippet, and it shows a preview of how the result might appear. It is the right first stop for any page you expect to show stars in search results, according to Google's structured data testing guidance.

The Schema Markup Validator checks whether your structured data is syntactically correct and conforms to Schema.org's vocabulary, regardless of whether Google supports a rich result for it. It is useful for catching malformed JSON or misused properties before they reach Google's eligibility rules at all.

Search Console's structured data reports work at a different scale: instead of checking one page, they surface patterns across your whole site, flagging pages with errors or warnings after Google has crawled and processed them.

Use the Rich Results Test first, on individual pages, before and after any template change.
Use the Schema Markup Validator when you need to confirm general Schema.org correctness, independent of Google's specific feature rules.
Check Search Console weekly during an active rollout, then monthly once markup is stable, to catch regressions early.
Treat warnings as a priority queue, not noise. A recommended-property warning on thousands of pages is worth fixing even if it does not block eligibility outright.

Testing is not a one-time gate. A template change made months after your original rollout can silently break markup across every page that uses it, which is why a regression check after any release touching page templates matters as much as the initial test.

Common mistakes and how to fix them

Most review markup problems trace back to a small set of repeat offenders, and most of them are avoidable with a checklist rather than a rewrite.

Hidden markup that does not match visible content is the most damaging error. Marking up a rating or review text that a visitor cannot actually see on the page is flagged as high risk by practitioner reporting on structured data policy and is a leading cause of markup being ignored or penalized. The fix is simple in principle: every field in the JSON-LD needs a visible counterpart on the page.
Conflicting markup types, such as applying editorial review rules to a page that is really a merchant product listing, confuses which guideline set applies and often results in neither being satisfied.
Incorrect value types, like a rating value written as text instead of a number, or a missing required property such as itemReviewed, will cause outright validation failures.
Client-side rendering pitfalls show up when JSON-LD is injected by JavaScript after page load and the crawler processes the page before that script runs, leaving the markup effectively invisible.

Pro Tip: If you inherited a site with existing review markup, run a handful of pages through the Rich Results Test before changing anything. It is faster to catch a legacy hidden-content problem now than after a template update multiplies it across the site.

The fix for client-side rendering issues is usually server-side rendering or a hydration strategy that ensures the JSON-LD block exists in the initial HTML response, not one that depends on a script executing successfully in the crawler's browser environment.

Scaling review schema across a whole site

A single well-tested page is easy. Hundreds of location or product pages sharing one template are where governance problems appear. The fix is architectural: build review markup into a server-side template with defined field types (numbers stay numbers, dates stay in ISO format) so every page generated from that template inherits the same correctness instead of relying on manual entry.

Schema template replicated across pages

Paginated reviews need a decision up front: do you mark up every individual review across every page, or do you mark up only the AggregateRating on the primary page and let individual Review markup appear only where the actual review text is visible? The second approach is safer and matches how most sites actually display content.

For editorial or comparison content, populate positiveNotes and negativeNotes only when the review text genuinely supports pros and cons, since forcing that structure onto a review that does not naturally have it produces thin, repetitive summaries.

Automation should include provenance logging: which template generated the markup, when it last changed, and which pages use it, so a future audit does not start from zero.

What client work has taught me about review schema

Review schema looks like a formatting exercise until you watch a page lose its rich result because a rating count in a JSON-LD block did not match the number shown on the page. That single mismatch, easy to introduce during a routine content update, is the most common cause of markup silently going from eligible to ignored.

The teams that keep review markup working long-term treat it as a maintained system, not a one-time task. A short checklist prevents most regressions: confirm visible content still matches markup after every template edit, retest after CMS or theme updates, and never let a developer copy a review schema snippet from one page to another without updating the itemReviewed reference.

The gap between sites with reliable rich results and sites that lose them repeatedly is rarely the code itself. It is whether anyone owns the markup after launch.

— Anas

How Honey Badger SEO handles review schema for local businesses

Getting review markup right once is a coding task. Keeping it accurate as reviews accumulate, pages get redesigned, and Google Business Profile content changes is an ongoing job, and that is where most self-managed implementations quietly break. Honey Badger SEO builds and monitors review schema as part of hands-on local search work, not as a one-off checklist item.

Seohoneybadger

The work is managed directly, with no outsourced implementation, which matters for something like schema markup where a template change made without full context can break eligibility across an entire site.

Local SEO includes technical implementation like review and aggregate rating markup as part of ongoing site work. For current pricing, please see the pricing page.
Website Creation builds pages with server-rendered structured data from the start, avoiding the client-side rendering issues that break markup on many templated sites.
Google Business Profile management ties review collection strategy to the same schema and monitoring work, keeping ratings consistent between GBP and on-site markup.

If you want an audit of your current review markup, or want it built correctly the first time, the Local SEO, Website Creation, and GBP services page is the place to start.

Where to verify the rules yourself

Treat the guidance above as a starting point, not a replacement for the primary documentation. Bookmark these and check them directly when a specific implementation question comes up.

Google's review snippet documentation covers eligibility rules, required and recommended properties, and nesting patterns.
Schema and Schema define every property and subtype in detail.
Google's structured data testing tools link to the Rich Results Test and explain what each testing tool checks.

Sources

FAQ

How do I test my schema markup?

Use Google's Rich Results Test to check whether a specific page qualifies for a review rich snippet and see a preview of the result, and use the Schema Markup Validator to confirm the markup is generally correct according to Google's structured data testing guidance. Check Search Console's structured data reports afterward to catch sitewide errors the single-page tools might miss.

Is 4.2 a good Google rating?

Rating quality depends on your industry and competitors, so there is no universal cutoff for what counts as good. What matters more for review schema purposes is that whatever rating value you display matches exactly what is marked up in your AggregateRating, since Schema.org's AggregateRating type requires that value alongside a rating or review count.

What is a review schema?

Review schema is structured data based on Schema.org's Review type that describes a single opinion about a product, business, or other item, including who wrote it, what they rated it, and what they reviewed. It helps search engines understand review content well enough to potentially display it as a rich result, provided the required properties are present and match the visible page.

What are examples of a positive review?

A positive review typically includes a high rating alongside specific, genuine detail, such as praising fast service, a clean space, or a specific product feature rather than a vague compliment. For schema purposes, the actual review text can be captured in the reviewBody property, and standout points can be summarized separately using positiveNotes when the content supports it.