Product Schema for E-commerce: Prices, Reviews, and Rich Results

What it is and how it works

Product schema is a Schema.org vocabulary that tells search engines a page represents a specific product. You embed it as JSON-LD in the page source, where a parser reads the properties without needing to interpret your HTML layout. Google then uses that data to decide whether the page is eligible for product rich results and for free listings in Merchant Center.

The core properties are straightforward. name, image, description, and brand identify the item. sku and a global identifier such as gtin or mpn tie it to a catalog entry. The commercial details live in a nested offers object: price, priceCurrency, and availability are the load-bearing fields. Ratings, when genuinely present on the page, go in aggregateRating and individual review objects. If you are mapping how all of this fits the wider standards picture, our machine-readable web standards pillar sets the context.

The SEO and visibility angle

Here is the honest version. Product schema is not a ranking factor. It will not move a page up the results for a competitive query by itself. What it does is change how an already-ranking result can appear: price and availability can surface in the snippet, star ratings can render beneath the title, and a valid feed can place the product in free listings and the Shopping experience. That visual difference can lift click-through, which is the real prize. Treat schema as an eligibility key, not a rankings lever, and you will set expectations your stakeholders can actually trust.

Use cases: who benefits most vs least

Retailers selling distinct products with clear prices, stable identifiers, and on-page reviews benefit most: every field maps cleanly and the rich result has real substance. Single-product brands and direct-to-consumer stores gain quick wins because their offers are simple. The benefit thins out where there is no genuine price (quote-only B2B), where reviews do not exist on the page, or where one URL covers a sprawling family of variants without distinct offers. In those cases, force-fitting Product schema invites more policy risk than reward.

Implementation

A minimal but complete single-product example looks like this. Note that aggregateRating is included only because the rating is assumed visible on the page.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Trailhead 30L Hiking Backpack",
  "image": [
    "https://example.com/img/backpack-front.jpg",
    "https://example.com/img/backpack-side.jpg"
  ],
  "description": "Lightweight 30-litre pack with ventilated back panel and rain cover.",
  "brand": {
    "@type": "Brand",
    "name": "Summitline"
  },
  "sku": "SL-BP-30",
  "gtin13": "0123456789012",
  "mpn": "SLBP30-GRY",
  "offers": {
    "@type": "Offer",
    "url": "https://example.com/products/trailhead-30l",
    "priceCurrency": "USD",
    "price": "129.00",
    "availability": "https://schema.org/InStock",
    "itemCondition": "https://schema.org/NewCondition"
  },
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.6",
    "reviewCount": "212"
  },
  "review": {
    "@type": "Review",
    "reviewRating": {
      "@type": "Rating",
      "ratingValue": "5"
    },
    "author": {
      "@type": "Person",
      "name": "Dana R."
    },
    "reviewBody": "Carried it for a week on the coast path and it held up beautifully."
  }
}
</script>

Keep the offers.url, price, and currency synchronized with the live page. Many teams generate this block server-side from the same product record that renders the page, which keeps the markup and the visible content from drifting apart. The same principle applies to your supporting markup, such as breadcrumb schema for the category path.

How to validate

Run the URL through Google's Rich Results Test to confirm the Product type is detected and to read any errors or warnings. Errors block eligibility; warnings flag recommended fields worth adding. For commerce specifically, check Merchant Center: the Products and Diagnostics views show whether each item is approved for free listings and surface disapprovals tied to price mismatches, missing identifiers, or policy issues. Schema.org's own validator is useful for syntax, but Google's tools are what determine real-world eligibility.

Common mistakes and policy traps

The most frequent error is marking up an aggregateRating or review that does not appear anywhere on the page. Google requires that any rating in your structured data be visible to users on that same page. Closely related is self-serving review content: ratings of your business or its services placed on the seller's own page are not eligible for review rich results, and Google does not accept ratings aggregated from unnamed third-party sources or invented entirely. Both can lead to a structured data manual action.

On the mechanical side, watch for an offers block missing price or priceCurrency, currency given as a symbol instead of an ISO code, availability values that are not valid Schema.org URLs, and prices that disagree with the page or the Merchant feed. Each one either drops eligibility or risks a disapproval. If you also publish editorial content around products, keep that on the correct type rather than overloading Product, as covered in our article schema guide.

FAQ