Review microdata: why rich snippets don't appear
Review markup is not "check a box and get stars." The search engine compares what is marked up in the code with what the user actually sees on the page.
If the markup shows a rating of 4.8 with 240 reviews, but the page displays 4.6 and 180, the rich snippet will not appear, even if the schema validation passes without errors. The robot sees the discrepancy and simply ignores the block.
The second common cause is conflicting blocks.
When a single page contains several independent sets of rating markup (for example, the store's overall rating and an individual product's rating in the same container), the search engine cannot tell which object the rating belongs to and rejects the snippet entirely.
The same story applies to nested entities: a review nested inside another review, or a rating marked up inside a product card without an explicit association to it.
Errors in the structure are almost always related to required fields. A review without an author, without a publication date, or with an empty body is an incomplete object, and the search engine does not accept it.
A rating outside the allowed range, text values instead of numbers, a date in an arbitrary format instead of the standard one — all of this breaks schema validation at a level that is not always visible in the basic validator but blocks display.
Separately, there is the check on the search engine's side: the markup may be technically flawless, but the rating will not appear in the results if the page is not indexed, is blocked in robots, or the content is loaded by a script after rendering.
We break down how this is resolved at each level — from reconciling the visible and the marked-up content to configuring data delivery.
What correct review markup gives a business
Stars in search results are not a decoration, but a separate snippet element that captures attention before the title.
When your page shows a rating and review count next to it, while a competitor has just a blue link, the snippet's click-through rate grows by tens of percent: the user already sees the rating and doesn't go to check it on a third-party site.
The share of clicks going to aggregators drops as a result — traffic stays with you, not with a platform that profits from your reputation.
The mechanics are simple: the page feeds the search engine structured data about the product or service, the rating, and the review author, and the search engine displays stars in the results.
This only works with honest data — the rating on the page, in the markup, and in the business profile must match. As soon as a discrepancy appears, the search engine removes the rich snippet from the entire domain, and getting it back is harder than getting it the first time.
Google and Yandex read markup differently: the former relies on its own rules for reviews, the latter on the general organization and offer schema.
That's why correct setup is not a single block of code on a page, but a unified rating model across the entire site: product cards, service pages, the reviews section. Then the rating is consistent everywhere, rather than "4.8 on the homepage and 3.2 in the catalog."
Reputation management here becomes an engineering task rather than a manual one. Reviews enter the markup from a single source, validation errors are caught before publication rather than after a letter from the webmaster console.
A separate class of errors — a mismatch between the microdata and the visible content — is closed at the build stage, and in the reports you see not "warnings" but an empty list.
Options for implementing review markup
Review markup can be implemented in four ways, and the choice between them is a choice between control, speed, and the amount of maintenance. Below are the real alternatives with their limitations, so you can match them against your site's current architecture.
| Option | When it fits | Limitations |
|---|---|---|
| Manual markup in the template | Single pages, reviews change rarely, full control over fields matters | Every change means editing code and a release; with dozens of pages, the risk of desync and markup errors grows |
| Auto-generation from a review database | Reviews are already collected in a database or external service, and the volume is growing | Requires a stable data structure: rating, author, date, text. Junk entries end up in the markup and break validity |
| CMS module | Content editors publish reviews themselves, without a developer | The module dictates its own field model; non-standard attributes and links to products often can't be supported |
| Hybrid approach | The template defines the structure, data is pulled from the database, and the editor fixes exceptions | Harder to set up: it requires synchronization between the template, the data source, and manual edits |
What to consider when choosing
The key limitation of review markup is search engines' requirements for authenticity. The markup must reflect real reviews on the page, not an aggregated rating out of nowhere: otherwise it doesn't produce a rich snippet and creates a risk of manual penalties.
That's why auto-generation without filtering and moderation almost always loses — things that shouldn't be there end up in the markup.
The hybrid approach in practice
Most often we build the scheme like this: the page template is responsible for the block's structure, review data comes from a database or collection service, and an editor can hide or correct an individual entry via the CMS.
This removes the main downside of manual markup — a release for every edit — and keeps control over what goes into the markup. Setup takes more time at the start, but after that maintenance comes down to working with content rather than code.
How we implement review microdata on a website
Implementation begins with a markup audit: we look at what is already being output in the code of review pages, which data types are marked up, whether there are conflicts between blocks and duplicates across different templates.
Often the opposite is found — the markup exists but does not match the visible content, and search engines simply ignore it.
- Markup audit. We collect all templates where reviews are displayed: product page, service page, general section. We record which fields are already present, where data is pulled from the database, and where it is entered manually.
- Data schema design. We determine which entities we describe — organization, product, service, individual review — and how they relate to each other. At this stage we agree on which attributes are mandatory and which are added as needed.
- Output configuration. We embed the markup into templates so that it is generated automatically from the same data the user sees. We eliminate manual duplication — otherwise, when content is updated, the markup gets out of sync.
- Validation. We run the pages through a validator and check that mandatory fields are filled in, data types are correct, and warnings do not block processing. Separately, we look at how the robot sees the markup — through the response code, not through visual rendering.
- Testing on a sample. We check several types of pages: with reviews, without reviews, with pagination. We make sure that on empty blocks the markup does not break and does not create false entities.
- Support regulations. We hand over a document: which fields are mandatory when adding a new template, how to check the markup before release, what to do when the review structure changes.
- Monitoring after launch. We track how search engines process the markup and make adjustments if errors appear on new pages.
Each stage ends with an artifact: a markup map, an approved schema, updated templates, a validation report, regulations. This order eliminates the situation where the markup is implemented but does not work — verification happens before release, not after.
What the client receives as a result of the work
Review markup is not "adding a couple of tags to a page" but a set of artifacts that remain with you after the work and live on without us.
Each item below is something that can be handed over to another contractor, checked in a search engine console, and not redone in the next release.
- Markup configuration — the rules for generating review data: which fields are required, where the author, date, and rating come from, and how empty and partially filled records are handled. The configuration is versioned together with the code, not edited by hand in production.
- Output templates — ready-made templates for the product card, service page, and review list, so that the markup does not break when the layout changes or a new page type is added.
- Review moderation policy — the rules: what gets published, what gets rejected, how complaints are handled, and how a review is taken down from publication. This directly affects whether the markup remains valid after content cleanup.
- Documentation — a description of the data structure, the mapping of fields to interface elements, and the points where the markup is assembled. Enough for a new developer to figure it out without exchanging messages with us.
- Verification instructions — a step-by-step scenario: how to run a page through the validator, what to look at in the search engine reports, which errors are critical and which can be ignored.
- Configured checks in the build — automatic validation of the markup on the test environment, so that a broken template does not make it to production.
- List of pages with markup — a list of URLs and types where the markup is already in place, with a priority note for expanding to new sections.
We do not check the result "by eye": we run the pages through the validator, verify the required fields, and look at how the search engine displays ratings in the search results.
If you want to understand what of this you already have and what will have to be done from scratch — describe the task, and we will come back with an estimate and a plan.
Case study: how review markup changed an online store's search results
An online store with a catalog of several thousand product cards came with a typical problem: reviews were on the pages, but they weren't showing up in search results.
The Product markup was in place, but the Review block wasn't included in it — the search engine saw the product without ratings.
Several thousand warnings about incomplete data were sitting in the webmaster console, and review moderation was done manually: a manager read through each one and moved it into the card.
What we did
We built a unified schema: each review gets author, datePublished, reviewRating fields and a link to the product via itemReviewed. The rating is aggregated into AggregateRating at the card level rather than being inserted manually.
Reviews without a rating or with empty text don't make it into the markup — the validator filters them out before publication.
In parallel, we closed out moderation: a review passes a spam check and lands in the card automatically, and the manager only confirms disputed cases.
Errors in the console are sorted by type — "missing field" and "invalid date format" are fixed with different edits.
What changed
The share of pages with a rich snippet grew from a few percent to the majority of catalog cards — stars and the review count are visible right in search results.
Click-through rate on product queries rose by 18–24% relative to the period before implementation, while impressions barely changed: the growth came from the snippet, not from rankings.
Errors in the console dropped by an order of magnitude — only isolated cases remained on outdated cards. Moderation time was cut by roughly threefold: manual work remained only where content judgment is needed. The schema was built according to Schema.org documentation and checked with Google's validator.
How does review markup for products differ from that for services?
The difference is determined by what the search engine requires the review to be tied to. For a product, a review is tied to a specific catalog item — a card with price, availability, and specifications.
For a service, there is no such tie: what is being rated is not an SKU but the provider or the organization as a whole, so the markup is built around the company entity rather than around an individual item.
The required fields also differ. Product markup requires an item identifier, its name, and the rating itself — without being tied to a card, the review will not be attached to anything and will be ignored.
In service markup, the key fields are the organization that owns the review, the author, and the rating; tying to a product is simply not provided for here.
If you mix up the schemas and mark up a service as a product, the search engine will discard the block entirely — outwardly the code is valid, but no rich snippet appears.
Review types add a second level of differences. For products, a rating with a numeric score and aggregation across all reviews on the card works.
For services, reviews about the organization with text and a rating are more often used, and the aggregated rating is collected at the level of the company rather than an individual service.
These types can be mixed on one page, but each block must be marked up with its own schema — otherwise the search engine will not understand what the rating refers to.
The limitations of search engines here are stricter than they seem. Both options require the review to be real and visible on the page: markup for text that is invisible or collapsed into a script is not counted.
Search engines also do not show stars for reviews placed about the organization itself on its own card — such a block remains valid, but without a visual rating in the search results.
Hence the practical conclusion: first we determine what exactly is being rated — a product or a provider — and only then do we choose the schema and the set of required fields.
Common technical concerns about review markup
Review markup doesn't break at the implementation stage, but later — when the template is updated, the review block is changed, or an external source is connected. Below are the four technical concerns that most often come up among clients before launch, and how we address them.
Can reviews collected from aggregators be marked up?
Yes, if you have the right to publish the review text itself on your page. Markup describes what the user actually sees in the HTML: if a review is loaded by a script and isn't in the source code, search engines won't see it and the markup will remain empty.
That's why we either render aggregated reviews via server-side rendering, or sync them into the database and serve them as static content. We add a link to the original source in the author field — this removes any questions about the origin of the data.
What happens to the markup when the site template changes?
A template changes the DOM structure, and markup is tied to specific selectors and classes. After a redesign, review microdata often falls off entirely or partially: the rating disappears, the "review — product" link breaks.
We move the markup into separate partial templates and cover it with checks in the build so that a change in layout doesn't silently take the data with it.
How do you avoid duplicate markup?
Duplicates appear when markup is present both in the theme and in a plugin, or when the same review block is output twice — for example, in the mobile and desktop versions. In that case, the validator shows conflicting entities. We keep a single source of markup per page and check the output at both breakpoints.
How often should validity be checked?
Validity isn't a one-time action. We check after every release that changes the product card template or the review block, and once a quarter — as scheduled maintenance.
Errors in review microdata don't bring down the site, so they're easy to miss for months, while the snippet with the rating isn't shown in search results during that time.
Let's discuss your review markup task
To come back with an estimate rather than generalities, we need to understand your current situation: what the site is built on, where reviews come from (your own form, external platforms, a marketplace), and how the product or service card layout is currently structured. Describe this in free form — we'll then ask the clarifying questions that matter.
After the review, you'll receive an implementation plan for review structured data with stages, timelines, and areas of responsibility.
The work estimate includes not only the markup code but also verification on real data: how search engines currently see your reviews and what will change after the fixes.
What the work will include:
- an audit of the current layout and markup of pages with reviews;
- a scheme for linking reviews to products, services, and the organization;
- setting up structured data for reviews and ratings on cards and in sections;
- connecting reviews from external sources, if any;
- verification through official markup validators;
- instructions for editors: how to add reviews so the markup doesn't break;
- markup support after release — we monitor changes and layout edits.
If the task is already partially solved or the markup is in place but doesn't show in search results — just say so, and we'll look into the causes. We'll discuss the task and come back with an estimate and a work plan, with no obligation on your side.
