Product schema markup is structured data (in JSON-LD format) that you add to product pages so search engines can read price, availability, ratings, and shipping at a glance. A valid Product object, with nested Offer, AggregateRating, and shipping/return details, makes your pages eligible for rich results like price snippets and review stars in Google Search and Shopping.
It won’t guarantee rankings, but it changes how your listing looks and can lift click-through. The real work is generating correct JSON-LD for every product, keeping it in sync with on-page values, and validating it before you ship. Below we walk through the exact properties Google requires, a copy-ready template, the errors that bite people, and how to roll it out across a large catalog.
What product schema markup is (and what it actually does)
Schema markup is a shared vocabulary, maintained by Schema.org, that lets you label the meaning of content on a page. Instead of leaving a search engine to guess that “$49.99” is a price, you spell it out: this is the price, in this priceCurrency, for this Product, currently InStock.
The most common (and most recommended) way to deliver this is JSON-LD: a small block of JSON inside a <script type="application/ld+json"> tag. Google’s own documentation favours JSON-LD over Microdata or RDFa because it sits in the page head or body without tangling into your visible HTML, which makes it far easier to template and maintain.
Three things to be clear-eyed about:
- It enables eligibility, not ranking. Valid markup makes you eligible for rich results. Whether Google actually shows them is its call, and it can change.
- It must match what users see. Marking up a price or rating that differs from the visible page violates Google’s structured data guidelines and can trigger a manual action.
- It is for products, not categories. Use
Productmarkup on pages where a specific item is the main entity, which usually means your product detail pages (PDPs).
The required and recommended properties
Google’s product structured data has a small set of required fields and a longer list of recommended ones that unlock more of the rich result. Getting the required set right is non-negotiable. The recommended set is where you win real estate.
| Property | Status | What it carries |
|---|---|---|
name | Required | The product title |
image | Recommended (effectively required for rich results) | One or more high-res image URLs |
offers → price | Required for the snippet | Numeric price, no currency symbol |
offers → priceCurrency | Required | ISO 4217 code, e.g. USD, EUR, INR |
offers → availability | Recommended | Schema.org URL, e.g. https://schema.org/InStock |
aggregateRating | Recommended | Average score + review count (star eligibility) |
review | Recommended | Individual review objects |
brand | Recommended | Manufacturer or brand name |
sku / gtin / mpn | Recommended | Identifiers that disambiguate the product |
shippingDetails | Recommended | Shipping cost and delivery time |
hasMerchantReturnPolicy | Recommended | Return window and method |
Google’s guidance has been rewarding richer offer data lately. Shipping cost, delivery time, and return policy can now surface directly in product results, which is why they’ve moved from “nice to have” to “do this if you sell physical goods.”
Identifiers matter more than people think
A GTIN (the number encoded in a barcode) or MPN helps search engines match your product to the global catalog and to other sellers. If you sell branded goods, include the GTIN. For private-label or unique items, a stable SKU is fine. Inconsistent or missing identifiers are a frequent cause of Merchant Center disapprovals downstream, and that’s the part that stings: the markup passes validation, but the same gap quietly tanks your Shopping listings weeks later.
A copy-ready JSON-LD template
Here’s a realistic, minimal-but-complete Product block. Swap the placeholder values for dynamic fields from your platform’s template engine. Don’t hard-code them per page.
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Product",
"name": "Merino Wool Crew Sweater",
"image": [
"https://store.example.com/img/sweater-front.jpg",
"https://store.example.com/img/sweater-back.jpg"
],
"description": "Lightweight 100% merino crew-neck sweater.",
"sku": "MWC-CREW-NVY-M",
"gtin13": "0123456789012",
"brand": { "@type": "Brand", "name": "Northfield" },
"offers": {
"@type": "Offer",
"url": "https://store.example.com/p/merino-crew",
"priceCurrency": "USD",
"price": "89.00",
"availability": "https://schema.org/InStock",
"itemCondition": "https://schema.org/NewCondition"
},
"aggregateRating": {
"@type": "AggregateRating",
"ratingValue": "4.6",
"reviewCount": "214"
}
}
</script>A few notes that save you a support ticket later. price is a string or number with no currency symbol and a dot decimal separator. availability is a full Schema.org URL, not the bare word “InStock”. And every value here has to be present and identical in the visible page HTML.
How to add schema across a real catalog
One product is easy. Ten thousand SKUs that change price and stock daily is the actual problem. The pattern that holds up is to generate the JSON-LD from the same data source that renders the page.
Step 1: Bind markup to your product template, not the page
Inject the JSON-LD from your PDP template using the product object already in scope. Because the markup reads the same variables the visible page does, price and availability can’t drift out of sync.
Step 2: Map your stock states to Schema.org values
Build one mapping from your internal inventory states to the canonical Schema.org URLs (InStock, OutOfStock, PreOrder, BackOrder). Centralise it so a new state gets handled in one place. The trap here is the long tail: a “discontinued” or “made to order” status that nobody mapped will silently fall through to whatever your default is, and you won’t notice until a customer lands on an out-of-stock page that still claims InStock.
Step 3: Handle variants honestly
If a product has variants at different prices, either mark up the specific selected variant or use an AggregateOffer with lowPrice and highPrice. Don’t claim a single low price for a page that actually sells a range. That’s a mismatch.
Step 4: Validate before and after deploy
Run representative templates through Google’s Rich Results Test and, for vocabulary-level checks, the Schema.org validator. Then watch Search Console’s structured data reports for errors that only show up at scale. Google’s own guidance lives in the product structured data documentation, and that’s the source of truth when behaviour changes.
On Wcart-built stores we treat schema as a platform-level concern: PDP templates emit valid JSON-LD by default, so individual merchants and marketplace vendors inherit correct markup without editing code. It’s the same principle we cover for visible on-page elements in our product page SEO guide.
JSON-LD vs Microdata vs RDFa
| Format | Where it lives | Maintainability | Recommended? |
|---|---|---|---|
| JSON-LD | Separate <script> block | High, decoupled from HTML | Yes, Google’s preference |
| Microdata | Inline HTML attributes | Low, entangled with markup | Supported, not preferred |
| RDFa | Inline HTML attributes | Low | Supported, rarely needed |
For nearly every ecommerce team, JSON-LD is the right call. It templates cleanly, it’s easy to validate, and it doesn’t break when designers restyle the page.
Common errors and how to avoid them
- Marked-up value differs from visible value. The single most common manual-action trigger. Generate markup from the same source as the page.
- Fake or sitewide reviews. Don’t apply one global rating to every product, and never invent reviews. Review markup must reflect genuine, product-specific reviews.
- Currency symbol in
price. Use89.00pluspriceCurrency, not$89. - Bare availability strings. Use the full
https://schema.org/InStockURL. - Missing images. Rich results lean heavily on imagery; include high-resolution, crawlable image URLs.
- Schema on non-product pages. Putting
Productmarkup on category or listing pages confuses parsing. For those pages, manage crawl scope instead. See our faceted navigation SEO guide.
Schema correctness only survives platform changes if you protect it during replatforming. We cover that in the ecommerce migration guide.
Frequently asked questions
Does product schema markup improve my Google rankings?
Not directly. Structured data does not boost rankings, but it makes pages eligible for rich results (price snippets, star ratings, stock status) which can raise click-through. Higher CTR can correlate with better performance over time, but the markup itself is an eligibility signal, not a ranking factor.
What is the difference between Product schema and a Google Merchant Center feed?
Product schema is structured data on your web page that powers organic rich results. A Merchant Center feed is data you submit to Google for Shopping ads and free listings. They overlap in content but are separate channels; doing both, with consistent identifiers like GTIN, gives you the widest coverage.
Should I use JSON-LD or Microdata?
Use JSON-LD. Google recommends it, and it lives in a self-contained script block that’s easy to template and validate without touching your visible HTML. Microdata and RDFa still work but are harder to maintain at scale.
How do I handle products with multiple price variants?
Either mark up the specific selected variant with its exact price, or use an AggregateOffer with lowPrice and highPrice to represent the range. Never advertise a single low price on a page that actually sells across a range. That’s a value mismatch.
Can I add review stars to every product?
Only for products that have genuine, product-specific reviews. Applying one sitewide rating to all products, or inventing reviews, violates Google’s guidelines and risks a manual action. Use aggregateRating backed by real review data, and consider including individual review objects.
How do I check that my product schema is valid?
Run the page through Google’s Rich Results Test for rich-result eligibility and the Schema.org validator for vocabulary correctness. After deploying at scale, monitor the structured data reports in Google Search Console, which surface errors that only appear across many URLs.
Do I need shipping and return markup?
If you sell physical goods, it’s increasingly worth it. Google can surface shipping cost, delivery time, and return policy directly in product results, so shippingDetails and hasMerchantReturnPolicy have moved from optional extras to a competitive edge.
Leave a Reply