Ecommerce product schema is structured data that describes what you sell in a format search engines can parse. When implemented correctly, it helps Google understand your product name, price, availability, and related facts on the product page itself. That clarity supports eligibility checks for product-related search features, but it does not guarantee any specific visual treatment in results.
This guide covers Product JSON-LD, Offer properties, ratings, breadcrumbs, return policies, variants, and how on-page schema differs from Merchant Center feeds. For broader discovery strategy, pair it with ecommerce SEO in 2026 and how to get products on Google for free.
Important: Valid structured data is a technical requirement Google may use when evaluating product pages. Google still decides whether and how to show rich results, merchant listing experiences, or price hints. Treat schema as accurate page metadata, not a ranking shortcut or a promise of enhanced snippets.
What product structured data does
Product structured data marks up a product detail page so crawlers can read consistent facts without guessing from layout alone. Google documents supported properties in Product structured data on Google Search Central. The underlying vocabulary comes from Schema.org Product and nested Offer objects.
Well-formed markup aligns with visible page content. If your JSON-LD says in stock at $29 but the page shows sold out at $39, Google may ignore the markup or flag inconsistencies in Search Console. Accuracy matters more than adding every optional field.
Why JSON-LD is the default format
Google recommends JSON-LD in a <script type="application/ld+json"> block. A baseline Product object includes @context, @type, name, image, description, and an offers block with price and availability. Validate output in the Rich Results Test after template changes.
Core Product and Offer properties
Think in two layers: Product describes the item; Offer describes the commercial terms for that item on your site.
| Property | Purpose | Common mistakes |
|---|---|---|
| name | Product title search systems should associate with the page | Different from the visible H1 or stuffed with keywords |
| image | Primary product images crawlable over HTTPS | Broken URLs, logos instead of product photos, or tiny thumbnails |
| description | Factual summary matching on-page copy | Marketing slogans that do not describe the specific SKU |
| sku | Your internal stock keeping unit | Missing SKU when the page shows one, or duplicate SKUs across unrelated products |
| brand | Brand object with a clear name | Store name used as brand for every SKU regardless of manufacturer |
| offers.price | Numeric sell price for the default offer | String prices with currency symbols, or stale sale prices |
| offers.priceCurrency | ISO 4217 currency code | Currency that does not match checkout |
| offers.availability | Schema.org availability URL such as InStock or OutOfStock | Always InStock while inventory is zero |
| offers.url | Canonical product URL for the offer | Homepage or category URL instead of the product page |
Price, currency, and availability
The Offer block is where most validation errors appear. Google expects price as a number, priceCurrency as a three-letter code, and availability as a full schema.org URL, not a plain English label.
Sale pricing must reflect checkout totals for the selected variant, and availability should track inventory changes. Currency must match the localized page; feed-style mismatches are covered in our Google Shopping feed errors guide.
SKU, brand, and product identifiers
SKU helps tie structured data to your catalog operations. Brand helps Google group products from known manufacturers. On many sites, brand is optional for private-label goods, but it should still be truthful when present.
GTIN (UPC, EAN, ISBN) and MPN are critical for branded catalog matching in Merchant Center and for some Google product features. Schema.org supports gtin, gtin8, gtin12, gtin13, gtin14, and mpn on Product objects when you have verified values from packaging or suppliers.
Never invent identifiers to pass validation. Incorrect GTINs cause disapprovals in feeds and can undermine trust in on-page markup. If no global identifier exists, follow Google's identifier_exists guidance for feeds and omit false GTIN fields from JSON-LD.
AggregateRating and Review markup
AggregateRating summarizes verified reviews on the product. Google allows star-related display only when ratings follow Review snippet guidelines: real reviews visible on the page, correct counts, and no self-serving fabricated scores.
Individual Review objects are optional when reviews are visible on the page. Never mark up scores from surveys or marketplaces you do not publish on the storefront.
BreadcrumbList for product navigation
BreadcrumbList markup describes the category path to the product and is often added alongside Product JSON-LD. Labels and URLs must match visible navigation. Breadcrumb display in search, like product enhancements, is optional and never guaranteed.
MerchantReturnPolicy and shipping details
Where Search Central documents them, MerchantReturnPolicy and shipping properties can reflect return windows and delivery facts stated on your site. Many merchants still configure shipping in Merchant Center while keeping on-page Offer markup focused on price, currency, availability, and seller. Any return or shipping schema must match checkout and policy pages exactly.
Variants: Offer vs AggregateOffer
Single-SKU products typically use one Offer with a single price. Products with multiple purchasable variants can use AggregateOffer with lowPrice, highPrice, and offerCount, or separate Product/Offer pairs per variant URL depending on your URL strategy.
The critical rule is consistency with the landing page. If the URL shows one selected variant, Offer price should match that variant. If the URL represents the whole product family, AggregateOffer should span the variant price range actually available to buy.
| Pattern | When it fits | Watch for |
|---|---|---|
| Single Offer | One SKU per URL, no variant selector | Forgetting to update price after sales |
| AggregateOffer | One URL with multiple in-stock variants | Range includes unavailable variants or draft SKUs |
| Variant-specific URLs | Each size or color has its own canonical URL | Each URL needs its own accurate Offer, not parent aggregate data |
Merchant listings, rich results, and feeds
On-page Product JSON-LD helps Google verify landing page content and may support product-related rich results where eligible. Merchant Center feeds power free listings and ads at catalog scale. You need both layers aligned: valid JSON-LD does not replace a clean feed, and a perfect feed does not excuse inaccurate page markup.
JSON-LD: page-level price, availability, and product facts at crawl time
Merchant Center feed: GTIN, categories, shipping labels, and bulk catalog fields
Both must agree on price, availability, and titles wherever both include them
KODEEFY storefronts also expose Google Shopping data at /feeds/google-shopping.xml on the live store domain. Treat that XML feed and on-page JSON-LD as complementary: identifiers in the feed, Offer accuracy in the product template.
Common product schema errors
These issues appear repeatedly in Search Console and the Rich Results Test.
| Error pattern | Typical cause | Fix |
|---|---|---|
| Price mismatch | Sale ended but JSON-LD cached old price | Regenerate markup from live pricing on each request or after cache bust |
| Missing offers | Product schema without Offer object | Add Offer or AggregateOffer with required price fields |
| Invalid availability value | Plain text instead of schema.org URL | Use full URLs like https://schema.org/InStock |
| Rating without visible reviews | AggregateRating added for marketing | Remove markup unless on-page reviews exist |
| Multiple conflicting Product blocks | Theme plus app both output JSON-LD | Consolidate to one authoritative Product graph per page |
| Identifier fiction | Placeholder GTIN copied across catalog | Remove false GTIN; supply real values in feeds where required |
Validate with the Rich Results Test
Run every template change through Google's Rich Results Test. Test the live URL when possible so cookies, geo pricing, and variant defaults match real shoppers.
Open the Rich Results Test and enter a public product URL.
Confirm exactly one primary Product item is detected unless you intentionally use variant-specific graphs.
Expand Offer details and compare price, currency, and availability to the visible page.
Review warnings separately from errors; warnings often signal optional improvements or policy-sensitive fields.
After fixes, request indexing in Search Console for high-traffic templates and monitor the Enhancement reports.
A passing test means Google could parse the markup, not that your page will show stars, price extensions, or merchant labels on the next search.
Implementation checklist
Use this checklist when launching a new theme, app integration, or headless storefront.
Product JSON-LD with @context and @type Product on every purchasable URL
Offer or AggregateOffer with numeric price, priceCurrency, and schema.org availability
Visible title, images, description, and SKU match structured data
Sale pricing and inventory rules reflected in Offer fields
AggregateRating only when on-page reviews exist
BreadcrumbList URLs mirror visible navigation
Variant strategy consistent sitewide (Offer vs AggregateOffer vs per-variant URLs)
Merchant Center feed price and availability match the landing page and JSON-LD
Rich Results Test and Search Console enhancements reviewed after deploy
How KODEEFY handles product JSON-LD
KODEEFY storefronts emit Product JSON-LD from live catalog data: name, description, images, canonical URL, SKU, brand, category, and Offer or AggregateOffer with price, currency, availability, and seller. Single-SKU products get one Offer; variant catalogs get AggregateOffer with lowPrice, highPrice, and offerCount. AggregateRating appears only when real review data exists. The builder does not emit GTIN or MPN in on-page JSON-LD; use the XML feed at /feeds/google-shopping.xml on your store domain for identifier-heavy Shopping fields. See KODEEFY features for platform capabilities.
Frequently asked questions
Does product schema guarantee rich results in Google Search?
No. Valid Product structured data makes your page eligible for parsing and may support product-related enhancements when Google chooses to show them. Rankings and display formats depend on query, competition, data quality, and policies. Always align markup with visible content instead of chasing guaranteed snippets.
Do I need JSON-LD if I already submit a Google Shopping feed?
Yes, for most storefronts both layers help. Feeds supply catalog-scale data for Merchant Center programs. On-page JSON-LD helps Google verify each landing page. Price, availability, and titles should match across both. See our guides on free listings and feed error fixes for the feed side of the workflow.
Should I add GTIN to JSON-LD for every product?
Only when you have a verified GTIN for that exact SKU. Incorrect identifiers hurt trust. Many sites keep GTINs in Merchant Center feeds while omitting them from JSON-LD if the page template does not manage them. KODEEFY's built-in Product JSON-LD does not output GTIN or MPN today; use the Google Shopping feed for identifier-heavy catalog fields.
When should I use AggregateOffer instead of Offer?
Use AggregateOffer when one product URL represents multiple purchasable variants with different prices and you show a range on the page. Use a single Offer when the URL represents one SKU or a default variant selection with one price. The chosen pattern must match what the shopper can buy from that URL.
Can I mark up reviews from email surveys not shown on the product page?
No. Review and AggregateRating markup must reflect reviews visible on the same product page. Hidden surveys do not qualify and may trigger manual actions or loss of rich result eligibility sitewide.
Final thoughts
Ecommerce product schema is foundational metadata for modern search: clear Product and Offer objects, honest availability, disciplined ratings, and breadcrumbs that mirror real navigation. Pair on-page JSON-LD with a healthy Merchant Center feed, validate with Google's tools, and treat rich results as a possible outcome of good data, not a checkbox that forces visibility.