SEO and GEO
Product schema guide for ecommerce product pages

In short
Product schema marks up the name, image, price, availability and ratings on a product page in JSON-LD so Google can read them reliably. On pages where shoppers can buy, use merchant listing markup: name, image and an offer with price and priceCurrency are required. Validate with the Rich Results Test and keep the markup identical to what visitors see.
Contents
- What is Product schema for ecommerce product pages?
- What is the difference between merchant listings and product snippets?
- Which Product schema properties are required and which are recommended?
- Required properties
- Recommended properties
- What does a JSON-LD example look like?
- How do you add structured data to product pages?
- How do you test Product structured data?
- What are the most common Product schema mistakes?
- How does structured data relate to your Merchant Center feed?
- Key takeaways
What is Product schema for ecommerce product pages?
Product schema is structured data that describes a product page in the schema.org vocabulary: its name, images, price, stock status, reviews and shipping terms. Google uses it to understand the page with certainty and to make it eligible for rich results such as price, availability and star ratings. JSON-LD is the recommended format, and it must match the visible page.
Without markup, Google has to infer meaning from your HTML. A shopper instantly knows that "$89.90" next to a crossed out "$119.00" is a sale price. A crawler has to guess which number is current, which is the old price and which might be an installment. Structured data removes that guesswork.
One expectation to set early: Google does not guarantee that structured data will produce a rich result. Markup makes a page eligible, and the search engine decides what to display. Still, a product page with missing or broken markup has a much lower chance of appearing in those richer shopping experiences.
What is the difference between merchant listings and product snippets?
Google documents two separate use cases for product structured data. Which one applies depends on a simple question: can people buy the product directly on this page?
| Criteria | Merchant listing | Product snippet |
|---|---|---|
| Right page type | Product page where the item can be purchased | Review, comparison or editorial page |
| Required properties | name, image, offers (price and priceCurrency) | name plus at least one of review, aggregateRating or offers |
| Where it can appear | Shopping experiences, Google Images, product knowledge panels | Text results with ratings, price and availability |
| Search Console report | Merchant listings | Product snippets |
For an online store the rule of thumb is clear. Build every product detail page to meet merchant listing requirements, because that markup largely covers what product snippets need as well. A blog roundup such as "the 5 best running shoes" is different: nothing is sold on that page, so product snippet markup is the right fit.
Which Product schema properties are required and which are recommended?
Required properties
For merchant listings, Google requires:
- name: the product name, matching the title on the page.
- image: one or more image URLs. Supplying several aspect ratios is a good habit.
- offers: an Offer object that includes price and priceCurrency (an ISO 4217 code such as USD, EUR or TRY).
Recommended properties
Required fields only get you through the door. The details that make a listing compelling live in the recommended properties:
- availability: InStock, OutOfStock, PreOrder and similar values.
- brand, gtin, sku, mpn: product identifiers. A GTIN helps Google match your item to the same product sold elsewhere.
- itemCondition: new, refurbished or used.
- shippingDetails: shipping cost and delivery time.
- hasMerchantReturnPolicy: return window, method and fees.
- aggregateRating and review: genuine customer reviews.
- description, color, size, material: product attributes.
For products with variants such as sizes and colors, Google also supports the ProductGroup type with properties like hasVariant and variesBy. If your catalog relies heavily on variants, plan that structure deliberately rather than bolting it on later.
What does a JSON-LD example look like?
Here is an example merchant listing for a single backpack. The brand, barcode, price and URLs are made up for illustration. The block sits on the page inside a script tag whose type is application/ld+json.
{
"@context": "https://schema.org/",
"@type": "Product",
"name": "Example Brand Leather Backpack 20 L",
"image": [
"https://www.example-store.com/images/backpack-1x1.jpg",
"https://www.example-store.com/images/backpack-4x3.jpg",
"https://www.example-store.com/images/backpack-16x9.jpg"
],
"description": "Water resistant leather backpack with a padded 15 inch laptop sleeve.",
"sku": "BPK-20-BLK",
"gtin13": "0012345678905",
"brand": { "@type": "Brand", "name": "Example Brand" },
"aggregateRating": {
"@type": "AggregateRating",
"ratingValue": 4.6,
"reviewCount": 87
},
"offers": {
"@type": "Offer",
"url": "https://www.example-store.com/products/leather-backpack-20-l",
"price": 89.90,
"priceCurrency": "USD",
"availability": "https://schema.org/InStock",
"itemCondition": "https://schema.org/NewCondition",
"shippingDetails": {
"@type": "OfferShippingDetails",
"shippingRate": { "@type": "MonetaryAmount", "value": 0, "currency": "USD" },
"shippingDestination": { "@type": "DefinedRegion", "addressCountry": "US" },
"deliveryTime": {
"@type": "ShippingDeliveryTime",
"handlingTime": { "@type": "QuantitativeValue", "minValue": 0, "maxValue": 1, "unitCode": "DAY" },
"transitTime": { "@type": "QuantitativeValue", "minValue": 2, "maxValue": 5, "unitCode": "DAY" }
}
},
"hasMerchantReturnPolicy": {
"@type": "MerchantReturnPolicy",
"applicableCountry": "US",
"returnPolicyCategory": "https://schema.org/MerchantReturnFiniteReturnWindow",
"merchantReturnDays": 30,
"returnMethod": "https://schema.org/ReturnByMail",
"returnFees": "https://schema.org/FreeReturn"
}
}
}
A few details matter here. Write the price without currency symbols or thousands separators and use a dot as the decimal separator, so 1299.00 rather than "$1,299.00". Enumerated values such as availability and condition use schema.org URLs instead of free text. Rating fields must reflect reviews that are actually displayed on the page.
How do you add structured data to product pages?
- Audit what already exists. Run a handful of product URLs through the Rich Results Test to see whether your theme or platform already outputs Product markup. Most themes ship a basic version and leave many recommended properties empty.
- Pick one source of truth. When the theme, an SEO app and a reviews app each output their own Product block, Google receives conflicting data. Consolidate into one block.
- Implement at template level. Add the markup to the product page template and pull values dynamically from your catalog, never by hand per product.
- Mirror the visible page. Price, stock, rating and review count must equal what the shopper sees. During a sale, the marked up price is the price the customer pays today.
- Validate, then ship. Test sample URLs on staging first, then again on the live site.
- Monitor continuously. Add the Merchant listings and Product snippets reports in Search Console to your weekly routine.
How do you test Product structured data?
Three tools complement each other. The Rich Results Test tells you whether a page qualifies for Google rich result types and which properties are missing. The Schema Markup Validator checks generic schema.org syntax without Google specific rules. The rich result reports in Search Console cover the whole site: they group valid items, warnings and errors, and let you start validation once a fix is live.
Testing one URL is never enough. Check an out of stock product, a discounted product, a product with variants and a product with no reviews at all. Most bugs hide in those edge cases, not in your best seller.
What are the most common Product schema mistakes?
- Price mismatch: the markup shows the old price while the page shows the sale price. If you use Merchant Center, this can also affect product approvals.
- Invisible data: marking up ratings or reviews that never appear on the page goes against Google's structured data guidelines and can lead to a manual action.
- Duplicate blocks: a theme and an app emitting two different Product objects for the same page.
- Product markup on category pages: a listing page represents many items, not one. Product markup belongs on the product detail page.
- Hardcoded values: templates that keep sending InStock after the item sells out.
How does structured data relate to your Merchant Center feed?
Structured data and your Merchant Center product feed describe the same items through two different channels. Google notes that Merchant Center can use the structured data on your site to verify and update product information. Keeping price and availability consistent across both keeps free listings and Shopping ads aligned. If the feed side needs work, our Performance Max product feed optimization guide is a practical next step, and our category page SEO guide covers the listing pages that sit above your products.
If you would like a second pair of eyes on your product markup and feed consistency, the Performetic team offers a free growth analysis.
Key takeaways
- Product schema lets Google read product data with certainty and makes pages eligible for rich results, with no guarantee of display.
- Use merchant listing markup on purchasable product pages and product snippet markup on reviews and comparisons.
- Required properties are name, image and an offer with price and priceCurrency. Recommended properties such as availability, GTIN, shipping and return policy are where listings win.
- Generate markup from a single source, at template level, with dynamic values.
- Test edge cases with the Rich Results Test and the Schema Markup Validator, and monitor Search Console reports weekly.
Frequently asked questions
Does Product schema improve rankings?
Structured data is not a ranking boost on its own. It helps Google understand your page precisely and makes it eligible for rich results such as price, availability and star ratings. Those richer results take up more space on the results page and can lift click through rate, but Google never guarantees they will be shown.
Does my ecommerce theme already add Product schema?
Most modern ecommerce themes output basic Product markup, but they often leave out recommended properties such as GTIN, shipping details and return policy. Test a few product URLs in the Rich Results Test. You will quickly see which properties are missing and whether apps are adding duplicate Product blocks.
Should I use JSON-LD or Microdata?
Google supports both, but recommends JSON-LD wherever possible. Because JSON-LD lives in a single script block separate from your HTML, it survives theme changes better, is easier to maintain and is simple to generate dynamically. If working Microdata is already in place, migrate gradually and validate each step.
What should the markup say when a product is out of stock?
If the product page stays live, keep the markup and change availability to OutOfStock. That way Google has current information and shoppers are not misled. If the product is discontinued for good, decide separately what happens to the page, for example a redirect to the closest alternative or removal.