Product schema and rich results

Two stores sell the same headphones and both rank on the first page. One result shows the price, "In stock" and a row of stars under the title; the other is a plain blue link. The shopper clicks the one that already answered their first two questions. The difference is a block of code the shopper never sees, and this lesson is about getting it right.

What structured data does, and what it doesn't

Structured data is a small block of JSON-LD (a machine-readable format Google reads from a <script> tag in your page) that states plainly what the page is about: this is a Product, this is its name, this is its price, it is in stock. Google uses it to understand the page and, for some types, to decorate the result.

Product is one of the types that still earns a visible feature. Google's search gallery documentation, the list of structured data types that currently produce rich results, includes Product alongside Review snippet, and it is the source for this lesson. A type that is not on that list produces nothing in results, however valid the markup. FAQ and HowTo rich results were retired, per Google's Search Central announcements, so a theme that still injects FAQPage markup onto product pages is adding weight for no return.

Two things it does not do. It does not raise your ranking: Google describes structured data as a way to help it understand a page and qualify for features, not as a ranking signal. And it does not guarantee the feature: Google's documentation says valid markup makes a page eligible, and Google decides for each search whether to show it.

Merchant listings and product snippets

Google's Product structured data documentation describes two experiences. Merchant listings are for pages where the shopper can buy the product, your product pages. Product snippets are for pages that discuss a product without selling it, such as a review. Markup written for a merchant listing also qualifies the page for product snippets, so a store only needs to get the first one right.

For a merchant listing Google's documentation requires three things on the Product: a name, an image, and an offer, where the offer carries a price and a currency. It then recommends availability, a SKU, a GTIN (the barcode number, which lets Google match your listing to the same product elsewhere), the brand, shipping details and the return policy. Google's advice is to supply as much of this as you have without worrying which feature will use it. A minimal valid block looks like this:

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Ridgeline 3 trail running shoe",
  "image": "https://example.com/images/ridgeline-3-navy.jpg",
  "sku": "RL3-NVY",
  "brand": { "@type": "Brand", "name": "Summit Outfitters" },
  "offers": {
    "@type": "Offer",
    "price": "129.00",
    "priceCurrency": "GBP",
    "availability": "https://schema.org/InStock"
  }
}

The same documentation says merchant listing markup belongs on pages about a single product. A collection page that lists many products is not a merchant listing, and marking it up as one earns nothing.

Stars come from shoppers, not from you

The stars in a result come from an aggregateRating inside the Product, and Google's review snippet guidelines are strict about where that comes from. Ratings must be sourced directly from users, the reviews must be readily visible on the marked-up page, and the markup must describe that specific product. Markup in which a business rates itself on its own pages is the self-serving review Google's guidelines rule ineligible, which is why a homepage with five stars in its code never shows them.

So the path to stars is the unglamorous one: collect genuine product reviews, show them on the product page, and let your review app or platform emit the aggregateRating from the reviews it shows. A rating in the code with no reviews on the page is exactly the mismatch the guidelines rule out. Reviews, UGC and brand signals covers how to collect them.

Keep the code and the page telling one story

Google's structured data guidelines require the markup to reflect what the page shows and to stay current. The price in the code must be the price on the page; availability must change when stock changes; the image must be the product, not a logo. Platforms and apps get this wrong in predictable ways:

• A theme emits one Product block and a review app emits a second, with a different price or an extra rating. Two blocks with different values are conflicting claims about one page; keep one block per product.
• A sale ends but the page is cached and the markup still carries the old price.
• The block is injected by JavaScript after the page loads, so the crawler sometimes reads the page before the block exists. Put it in the HTML the server sends.

Google's Product documentation also recommends sending the same data through a Merchant Center feed, because the two sources let Google verify each other. Product feeds and free listings covers that side.

What to take away

• Product markup makes a result eligible to show price, availability and stars; it does not make the page rank higher and the feature is never guaranteed.
• A merchant listing needs a name, an image and an offer with a price and currency, per Google's documentation, and belongs on single-product pages where the shopper can buy.
• Stars come from genuine, visible product reviews marked up on that product's page; self-serving or invisible ratings are ineligible.
• The markup must match the page today: one block, the live price, the current stock status, served in the HTML rather than added by a script.

Next

Google also needs to see the product, and it reads the photo through the text around it. Continue with Product images and alt text.