Product Schema Markup: A Practical Guide
How to mark up a product page correctly: the required fields, keeping price and availability current, and the mistakes that cost rich results.
Product schema markup is structured data — usually JSON-LD — added to a product page that tells search engines the product's name, price, availability and rating in a machine-readable format, making the page eligible for rich results like star ratings and price directly in the snippet. It does not change rankings by itself, but it does change click-through rate.
That eligibility work is one piece of the larger ecommerce SEO effort, and it is one of the cheaper fixes on this list relative to what it returns, because it is largely a one-time template change rather than ongoing content work.
On this page
What is product schema markup, exactly?
It is a block of structured data, written in the JSON-LD format Google recommends, embedded in a product page's HTML that states the product's facts explicitly rather than leaving a crawler to infer them from visible text and layout [1]. Schema.org defines the vocabulary — the property names and expected value types — and Google's own documentation defines which of those properties actually unlock a rich result [2].
The distinction matters because schema.org's specification is broader than what any single search engine uses. You can mark up dozens of optional properties that schema.org defines and see no visible change in search results, because Google only rewards the specific subset it has chosen to build rich results around. Focus on that subset first, and treat the rest as optional polish.
JSON-LD is the recommended format for a reason worth understanding rather than just following: it sits in a single script tag in the page's head or body, separate from the visible HTML, which means it can be generated by a template or a data layer without touching the markup a designer or a theme controls. The older microdata and RDFa formats interleave structured data directly into visible HTML attributes, which is harder to maintain and easier to break accidentally during an unrelated template change. Nearly every modern ecommerce platform and schema plugin defaults to JSON-LD now, and there is little reason to choose otherwise on a new implementation.
It is also worth understanding what schema cannot do. It cannot make a page rank for a term the page's actual content does not support, and it cannot fix a slow or unreachable page — those are separate problems with separate fixes. Schema is narrowly about eligibility for a richer presentation of a page that would otherwise already qualify to appear in results.
What fields are actually required?
| Field | Required? | Notes |
|---|---|---|
| name | Required | The product's name, matching what is shown on the page |
| image | Required | At least one image URL; more is better |
| offers (price, priceCurrency, availability) | Required (one of offers or review) | Must reflect the live, current price and stock state |
| aggregateRating or review | Required (one of offers or review) | Must be genuine, first-party ratings — never fabricated |
| sku, gtin, brand, mpn | Recommended | Strongly improves matching, especially for Merchant Center |
| description | Recommended | Should reflect the actual on-page product description |
Google's own guidance states that at least one offer or one review is required alongside name and image [2] — a page with only name and image, no price and no rating, will not qualify for the richer snippet types even though the markup is technically valid schema.
Start with name, image, and offers
This alone qualifies most product pages for a basic price-in-snippet rich result.
Add gtin, mpn or sku wherever they exist
These identifiers matter even more for Merchant Center matching than for on-page rich results — see our guide to free Merchant Center listings.
Add aggregateRating only from real, on-site reviews
Never generate a rating from an external source the visitor cannot also see and verify on the same page.
Wire price and availability to your actual inventory system
Static, hand-written schema goes stale the first time a price changes or a product sells out.
What is the single most common mistake?
Stale data. Schema that was correct on the day it was written but never updates when price or stock changes is the most frequent cause of rich result errors in Search Console, because Google periodically re-checks marked-up pages against what it sees, and a schema price that no longer matches the visible page price is treated as unreliable. The fix is structural: generate the schema from the same live data feeding the visible price and stock display, rather than writing it once by hand.
A close second is removing schema entirely when a product goes out of stock, rather than updating the availability field to reflect that state. This throws away the eligibility the page had built and forces a rebuild once the item restocks, for no benefit over simply updating one field.
A third, subtler mistake is marking up variant products incorrectly. A product with size and color variants can be modeled several valid ways — one Product with an array of offers, or separate ProductGroup and variant entries — and mixing approaches inconsistently across a catalog, or collapsing all variants into a single price and availability that does not reflect any specific variant, produces schema that is technically present but factually wrong for whichever variant a shopper actually views.
Validate before shipping any template change, not after. Google's own Rich Results Test and Search Console's Enhancement reports both show which properties were detected and which eligibility requirements were or were not met, on a specific URL. Running a handful of representative product pages — a normal in-stock item, an out-of-stock item, and a product with variants — through validation before a template goes live catches most of these mistakes at the source, rather than discovering them weeks later as a drop in rich result impressions.
How does this connect to category and filter pages?
Product schema lives on the product page, but its effects reach further: a category page listing well-marked-up products can itself become eligible for certain aggregated rich result types, and a correctly scoped filtered view inherits the same product-level markup from whatever products it happens to display. Getting this right once at the product template level means every page that surfaces those products benefits, without any additional markup work per page or per filter combination.
How does schema tie into keyword and content strategy?
Schema is not a substitute for the words on the page — it is a structured summary of facts the page already states in prose. A product page with rich, specific on-page content that reflects the terms real buyers search for gives schema more to accurately describe, and it is worth treating schema work as a step that follows solid ecommerce keyword research and product copy, not one that substitutes for it. A page with perfect schema and thin, generic copy will still underperform a page with strong copy and no schema at all — schema amplifies a good page, it does not create one.
The description field inside schema is a useful forcing function here: Google's own guidance recommends it reflect what is actually on the page, which means writing it well requires the on-page description to already be specific and complete. Teams that build schema before writing real product copy often end up with a description field that is either empty or copied verbatim from a generic manufacturer feed, which defeats the purpose twice over — once for the shopper reading thin copy, and once for the schema meant to describe it accurately.
How often should product schema be audited?
Treat it the same way you would treat any other template-level asset: reviewed on a fixed schedule, not only when Search Console flags an error. A quarterly spot-check across a sample of products — new arrivals, best sellers, and anything recently marked out of stock — catches drift between the schema and the live page before it accumulates into a large batch of Search Console warnings.
Platform updates and app installs are the other common trigger worth watching for. A new reviews app, a redesigned product template, or a migration between platforms can each silently change or remove schema that was previously working, and the only reliable way to catch that quickly is a scheduled check rather than waiting for organic traffic or rich result impressions to visibly decline first.
Questions people also ask
Does product schema markup directly improve rankings?
Not directly — it is not a ranking factor by itself. What it does is make your page eligible for rich results (star ratings, price, availability in the snippet), which improves click-through rate, and it gives Google a structured, unambiguous read of your page's facts.
What is the minimum required to get a rich result?
Name, image, and either an offer (price, currency, availability) or an aggregate rating, at minimum. Google's documentation lists these as the required properties; everything else is recommended but optional.
Should out-of-stock products keep their schema markup?
Yes, with availability updated to OutOfStock rather than removing the markup entirely. Removing the schema alongside a temporary stock-out means rebuilding eligibility for rich results once the product is back.
Can I use the same schema fields as my Merchant Center feed?
You should aim to. Keeping product schema and your Merchant Center feed describing the same facts — price, availability, identifiers — avoids the mismatch that can trigger disapprovals or inconsistent rich results across surfaces.
Do reviews need their own schema, or are they part of Product?
Aggregate rating and individual reviews are both valid sub-properties of Product schema, but Google requires that ratings be genuine, on-site, first-party reviews — not fabricated or imported from a source not visible to a site visitor.
Sources
- Product — Schema.org Type — Schema.org (checked 23 September 2026)
- Product structured data — Google Search Central (checked 23 September 2026)
- Product data specification — Google Merchant Center Help (checked 23 September 2026)
Find out which product pages are missing rich result eligibility
Book a free 30-minute consultation with Ibrahem and Jeremy. We look at your site while we talk, and you leave with a prioritised plan.
Who wrote this
Jeremy ZavaCo-founder
Leads growth and client partnerships.
Works on: CRO, SEO
Reviewed before publishing by Ibrahem Helal, Co-founder.
- Ecommerce SEO: the complete guide for 2026Ecommerce SEO means ranking the category and product pages that sell: clean structure, controlled filters, product data, and pages worth buying from.
- Category Page SEO for Online StoresHow to make category pages rank on their own: what to put above the product grid, how to handle pagination, and when a filter needs its own URL.
- Faceted Navigation SEO: A Decision FrameworkWhich filter combinations deserve an indexable URL, which should be blocked, and how to stop faceted navigation from generating thousands of thin pages.
- Ecommerce Keyword Research That Maps to PagesHow to research keywords for a store so every term lands on a real category or product page, instead of a spreadsheet nobody ever builds against.