Price and Star Ratings in Search Snippets

Two adjacent search results look very different: one shows just a title and description, the other shows "from $19," yellow stars and "47 reviews." The second one wins the click. This isn't magic, and it isn't a paid Google feature — it's Schema.org structured data, which the search engine reads from your HTML and may choose to display in the snippet. Let's break it down like engineers: which markup types produce price and stars, what's mandatory, where the trick fails, and which penalties hit people who decide to "draw" fake reviews. No fluff — so you can check your own page today.

What a rich snippet buys you

A rich snippet is when the result shows more than text under the title: price, star rating, review count, availability, sometimes breadcrumbs and FAQ. The source is structured data on the page — a machine-readable layer on top of regular HTML. The dominant vocabulary is Schema.org, understood by both Google and Yandex. Technically there are three ways to add it: JSON-LD (a separate script block — recommended and easiest), Microdata (attributes inside tags) and RDFa. Both engines prefer JSON-LD, and nearly all new markup is written that way.

Get the division of roles straight up front. Markup does not directly affect your ranking — it doesn't push you up the results. It affects how you look at the position you already hold. That, in turn, helps indirectly: price and stars raise click-through rate (CTR), and a more clickable snippet earns a behavioral edge over time. So markup is a CTR lever, not a position lever.

One more foundational point: markup is a request, not a command. You tell the engine, "this page has a product at this price with this rating." Whether to show it in the snippet is the algorithm's call. Correct markup therefore doesn't guarantee stars in the SERP. But without it, you'll get none for sure. The rest of this guide is about making that request as valid as possible.

Price in the snippet: Product + Offer

Price reaches the snippet through the Offer type, nested inside Product (for goods) or inside a service or local business. The minimum working product markup is a Product object with the required name and offers, and inside offers an Offer with price, priceCurrency and availability. Currency uses ISO 4217 (RUB, USD); price is a number with no spaces or currency symbol — 19, not "$19." For a price range, use AggregateOffer with lowPrice and highPrice — that produces "from $19" on a category card with multiple variants.

A minimal JSON-LD looks like this: type Product, a name field, an image URL, and an offers block of type Offer with price, priceCurrency "USD" and availability "https://schema.org/InStock." It's worth adding priceValidUntil — the date the price is valid through — since Google sometimes warns in the validator without it. For online stores the url inside Offer matters, pointing to the purchase page.

The rule that trips up half of all sites: the price in markup must match the price visible on the page. If JSON-LD says 19 and the visitor sees 24, that's a markup-vs-visible-content mismatch, and the engine will either ignore the markup, lower its trust in it, or hand you a manual action. Same with currency and availability: "in stock" in markup while the page says "out of stock" is a direct path to losing the rich snippet.

For services (lawyers, professional training, repairs, B2B) there's often no physical Product — use Service and expose price through offers with an Offer just like a product, or through LocalBusiness with priceRange. Stars and price appear less often and more reluctantly for services than for physical goods: engines are more cautious with YMYL topics like legal and education. Assume markup is a foundation for services, not a guarantee of stars.

Star ratings: AggregateRating and Review

Yellow stars come from two types: AggregateRating (an averaged score across many reviews) and Review (a single review with author and score). For stars under a product you need AggregateRating inside Product: required fields are ratingValue (the average, e.g. 4.7) and one of ratingCount or reviewCount (how many ratings or reviews). Without a count there are no stars — the engine needs to know how many people the score is based on.

A hard requirement from both Google and Yandex: the rating must apply to a specific entity on the page — a product, service or organization — and those reviews must be visible on that page. You cannot put a site-wide AggregateRating on a single product page. You cannot mark up a rating that isn't in the visible content. Google states it plainly: reviews reflected in markup must be available to the user on that same page. Hide reviews in the footer, or strip them from the layout while keeping the markup, and the stars get pulled.

A separate subtlety is the organization rating. You used to be able to self-assign stars to your own company via self-serve markup, but in 2019 Google banned self-serve and third-party reviews in markup for the LocalBusiness and Organization types. Google now pulls the organization rating in the snippet from its own sources (Google Business Profile, aggregators), not your markup; Yandex pulls it from Yandex Business and review sites. Bottom line: you can no longer "draw" organization stars via Schema.org in Google — only product and service AggregateRating with real, on-page reviews works.

Common mistakes and penalties

The most expensive mistake is fake reviews and inflated ratings. Putting ratingValue 5.0 and reviewCount 200 on a page with zero visible reviews isn't a "hack" — it's grounds for a Google manual action (Spam structured data) and the loss of rich snippets across the whole site, not just one page. Recovery means removing the deception, filing a reconsideration request and waiting weeks. Not worth it.

The second classic failure is markup that doesn't match visible content: price, availability or rating in JSON-LD differs from what a person sees. The third is incomplete markup: Product without offers, AggregateRating without a count, price as the string "$19" instead of a number, currency as "dollars" instead of "USD." The fourth is markup on the wrong page type: AggregateRating on a category page instead of a product card, or a Review without itemReviewed. Validators catch all of these as errors or warnings.

The fifth, subtler mistake is marking up content that isn't in the current version of the page. For example, JSON-LD is server-rendered while the reviews block loads via JS and the engine doesn't see it on first crawl — formally deceptive, in practice a desync. Hence a simple rule: everything in the markup must exist in the visible HTML served at the same URL. Before publishing we reconcile three values — the price in markup, the price in the layout and the price the server returns — because they tend to drift apart unnoticed.

How to validate and how long it takes

Validation is mandatory and free. For Google: the Rich Results Test (search.google.com/test/rich-results) shows which rich results are eligible for a page and highlights errors and warnings; the Schema Markup Validator (validator.schema.org) checks Schema.org syntax in general. Once the page is indexed, Google Search Console reports (Enhancements → product snippets, reviews) show site-wide validity and error history. For Yandex, use the Structured Data Validator in Yandex Webmaster: paste a URL or code and it shows the recognized entities and fields.

The order is: 1) add JSON-LD to the page; 2) run it through the Rich Results Test and the Yandex validator until you hit zero errors (warnings are tolerable but better closed); 3) reconcile markup values against visible content; 4) wait for a recrawl. A rich snippet doesn't appear instantly: the bot must recrawl the page first (a few days to a couple of weeks, depending on how often it visits), then the algorithm decides whether to show the enriched view. On actively crawled sites stars and price appear in 1–3 weeks; on rarely crawled ones, longer.

Honestly about timelines and guarantees: even perfectly valid markup doesn't obligate the engine to show stars. Google and Yandex show rich snippets selectively — by query type, site authority, SERP competition. Sometimes the price shows but the stars don't, even though both types are marked up correctly. That's not a markup bug, it's an algorithm decision. Your job is to make the request flawless; display is on the engine's side.

How we do this in practice

Commercial markup with price is regular work for us on building-materials sites and in catalogues. The typical setup: a catalogue of a few hundred items, each product card carrying Product + Offer with current price and availability, categories carrying AggregateOffer with a "from" range. For local business we add LocalBusiness with address, price range and contacts (including Telegram as a channel) — that helps both the snippet and the local map pack.

With programmatic page generation the markup isn't placed by hand on each card but via a template: price, availability and ratingValue are pulled from the same data that renders the visible layout — so markup and content physically cannot diverge. That's the engineering answer to the markup-vs-visible mismatch: a single source of truth for both representations. At a scale of hundreds to thousands of pages it's the only reliable approach.

We add ratings only where real, on-page reviews exist — no inflation. If there are no reviews, we don't "draw" stars; we first build review collection, then mark it up. Slower, but the only path without penalty risk. Price and availability, unlike rating, are almost always available — which is why we can give nearly any catalogue a commercial price snippet within the first month.