Product Schema

TL;DR — Product schema is code you add to a product page that labels the product details for search engines — “this is the name,” “this is the price,” “this is in stock,” “these are the review stars.” Adding it correctly makes the page eligible for the richer search listings you see on shopping results (price, availability, star ratings). It does not guarantee those extras show up, and it is not the same thing as uploading a product feed to Google Merchant Center.

What Product schema is

When you look at a product page, you can tell the price from the product name from the “In stock” label just by reading. A search engine sees plain text and has to guess. Product schema spells it out in code, using the shared schema.org vocabulary — it tags each piece of the page with what it actually is: the name, an image, the price and currency, whether it’s InStock, and any review ratings.

It’s almost always written as JSON-LD — a small block of code that sits in the page without changing how the page looks.

Why it’s worth doing

The payoff is rich results: the enhanced search listings on product queries. Two kinds:

• ⭐ Product snippets — star ratings and a price under a normal product page.
• 🛒 Merchant listings — the fuller, shopping-style result (price, availability, sometimes shipping and returns) on pages where the item can be bought right there. Evidence for this claim Google uses Product structured data for product snippets and merchant listing experiences when applicable requirements are met. Scope: Google Search Product documentation; eligibility does not guarantee display. Confidence: high · Verified: 2026-07-14 Google: Product structured data

A more eye-catching listing can earn more clicks. There’s also a growing practitioner theory — not something Google documents — that AI shopping tools read this same markup to understand your products. It’s unproven, but getting the markup right costs nothing extra, so it’s worth doing regardless.

The four things you almost always need

To be eligible for the lighter product snippet experience, you need the product’s name and at least one of these three: an offer (price info), a review, or an aggregate rating (an average star score). The stricter merchant listing experience always needs an offer — it isn’t optional there the way it is for a snippet. In practice most stores include all four:

• name — the product’s name.
• image — a good product photo (required for the shopping-style listing).
• offers — with a price and priceCurrency (like USD) and an availability (like InStock or OutOfStock).
• review / aggregateRating — if you have genuine customer ratings.

The thing most people get wrong

Product schema and a Google Merchant Center feed are not the same thing. The schema goes on your page. A Merchant Center feed is a separate file you submit to Google. They influence overlapping shopping results, and Google cross-checks them — but they’re validated separately, and fixing one doesn’t fix the other. More on that in the Advanced tab.

Two more beginner traps:

• Valid markup ≠ guaranteed rich result. It makes you eligible; Google still decides whether to display it.
• Only mark up what’s really on the page, and keep the price and stock in your markup matching what a shopper actually sees. Mismatches get flagged.

Want the full version — the snippet-vs-merchant-listing split, the availability values, the feed relationship, and how to fix Search Console errors? Switch to the Advanced tab.

TL;DR — schema.org/Product markup (usually JSON-LD) makes a product page eligible for two distinct Google experiences: product snippets (price/reviews on any product page — priceCurrency only recommended, price: 0 allowed) and merchant listings (transactional pages — require image, offers, and a price > 0 with priceCurrency). Minimum for a product snippet: name + at least one of offers/review/aggregateRating — a merchant listing needs offers outright, not as one option among three. The biggest trap is conflating this on-page markup with a Google Merchant Center feed — separate system, separate validator; Google reconciles them, and price/availability must match across markup, feed, and checkout or Google flags a mismatch. Valid markup only earns eligibility; Google’s systems still decide whether to show the result. Whether this article’s implementation angle or the broader ecommerce-SEO angle is what you’re here for, both live in the same place — this topic is cross-listed under structured data and under ecommerce SEO for exactly that reason.

What Product schema does — two experiences, not one

Most guides flatten “Product schema” into a single requirements list. Google actually splits it into two rich-result experiences with different strictness, and knowing which one you’re aiming for is half the battle:

• Product snippets — for non-transactional or general product pages, emphasizing reviews and price. Lighter requirements.
• Merchant listings — for pages where the product can be purchased directly, emphasizing full shopping details (price, availability, shipping, returns). Stricter requirements. Evidence for this claim Google documents separate product snippet and merchant listing experiences with different property requirements. Scope: Google Search Product documentation; validate against the intended experience. Confidence: high · Verified: 2026-07-14 Google: Product structured data

Google’s own framing: “Two markup types exist: Product snippets for non-purchase pages, emphasizing reviews, and Merchant listings for purchase pages, highlighting product details like sizing and shipping.” Same schema.org/Product vocabulary underneath — the difference is which properties Google requires for each.

Required vs. recommended properties

The minimum for a product snippet — Google’s lighter of the two experiences: Product.name, plus at least one of offers, review, or aggregateRating. That “one of three” flexibility is specific to product snippets. A merchant listing always needs offers — Google’s own required-property table lists name, image, and offers as required, full stop, with no either/or. And a scoping rule worth internalizing — Google: “product rich results only support pages that focus on a single product (or multiple variants of the same product).” A category page (“shoes in our shop”) is not a product; for a line of variants, reach for ProductGroup markup instead (a direct sibling topic).

ProductGroup should describe genuine variants in the catalog, not every theoretical configuration a selector could calculate. A variant should have a stable identity, real attributes, a reachable or selectable state, and an offer the commerce system can keep current. Emitting the Cartesian product of every option can produce valid-looking markup that invents products shoppers cannot select or buy. The detailed inclusion rules live in Product Variant SEO.

Product level

Offer level (offers, an Offer object)

The two rules people miss most: for merchant listings, “merchant listing experiences require a price greater than zero” (product snippets tolerate 0), and priceCurrency is required for merchant listings but only “currently recommended” for basic product snippets.

The availability property and its enum values

availability isn’t strictly required for eligibility, but treat it as essential — it drives the “In stock” / “Out of stock” label users see, and it’s a key field Google matches against your Merchant Center feed. It takes a schema.org enum, and passing a plain string like "in stock" instead of the URL/enum value is one of the most common validation errors.

The full set Google documents for Product:

For the SEO handling of out-of-stock and discontinued items — whether to keep, redirect, or noindex them — the out-of-stock products article in the ecommerce cluster goes deeper than the markup alone.

The ecommerce availability contract

availability is not a direct copy of a warehouse quantity. A product can physically exist but be unsellable in a market, unavailable for a selected variant, restricted to pickup, unable to reach a postcode, or temporarily blocked at checkout. Reconcile the whole decision chain:

Choose an authoritative commerce service for the underlying decision, then map its states deliberately into the smaller vocabularies required by schema.org, Google or Microsoft feeds, and agentic-commerce integrations. Do not let each template and feed invent its own translation of available, backorderable, pickup-only, or discontinued. Evidence for this claim Google treats on-page Product structured data and Merchant Center feeds as separate, complementary ways to provide product data. Scope: Google Search ecommerce guidance; the systems can be reconciled but are validated separately. Confidence: high · Verified: 2026-07-14 Google: Share product data

Postcode-dependent fulfillment needs two levels of truth. The landing page, markup, and feed should state the generally published offer accurately; after a customer supplies a location, the page and checkout can show the more specific fulfillment outcome. Do not publish InStock merely because one warehouse has a unit when the represented market cannot buy it, and do not mark the entire parent product OutOfStock because one size, store, or delivery method is unavailable. The Product Variant SEO URL contract applies when availability changes with the selected SKU.

Validate at least these representative states after catalog, template, feed, or fulfillment changes:

• an ordinary in-stock SKU;
• a temporarily unavailable or backorderable SKU;
• one unavailable variant inside an otherwise available product group;
• a postcode-restricted delivery with an available pickup or store option;
• a discontinued item;
• a recently restocked item before and after feed refresh.

For each one, capture the visible selection, raw and rendered markup, feed row, cart line, and checkout result. A passing Rich Results Test proves markup eligibility; it does not prove feed freshness, personalized fulfillment, or purchase success.

Product schema vs. Google Merchant Center feeds — validated separately

This is the confusion I most want to kill. Product schema markup and a Merchant Center product feed are two separate systems. Google reconciles them, but they are not one submission and they are not validated together.

Google spells out the three options: “To provide rich product data to Google Search you can add Product structured data to your web pages, upload data feeds with Google Merchant Center and opt into free listings within the Merchant Center console, or both.” Evidence for this claim Google treats on-page Product structured data and Merchant Center feeds as separate, complementary ways to provide product data. Scope: Google Search ecommerce guidance; the systems can be reconciled but are validated separately. Confidence: high · Verified: 2026-07-14 Google: Share product data And on why you might do both: “Providing both structured data on web pages and a Merchant Center feed maximizes your eligibility to experiences and helps Google correctly understand and verify your data. Some experiences combine data from structured data and Google Merchant Center feeds if both are available. For example, product snippets may use pricing data from your merchant feed if it’s not present in the structured data on the page.”

Read that carefully: they’re combined when available, which is exactly why people assume they’re the same system. The practical consequences:

• Two validators. Markup is checked with the Rich Results Test and monitored in Search Console; the feed is checked with Merchant Center diagnostics. Passing the Rich Results Test says nothing about whether your feed is valid, and vice versa.
• You don’t need a feed to earn a merchant listing. On-page structured data alone can produce merchant-listing rich results. As John Mueller framed it, there’s also “the possibility to submit a feed to your merchant center account, to show products there.” The feed is an additive path, not a prerequisite.

Keep price and availability consistent across markup, feed, and checkout

The Merchant Center spec is explicit that merchants must “accurately submit the product’s price and currency, and match with the price from your landing page, structured data, and at checkout.” So price and availability have to agree in three places: your on-page Offer, your Merchant Center feed, and the actual checkout. If they diverge, Google can flag a mismatch or suspend the item even when your JSON-LD validates cleanly. Clean markup is necessary; consistency is what keeps the listing live. If you sell on Bing too, the same discipline applies to Microsoft Merchant Center — its feed system is the Bing-side equivalent of Google’s. For variants, reconcile the entire selected offer—not only price and stock. Product identity, SKU, group ID, selected attributes, price, currency, and availability should refer to the same sellable item on the visible PDP, in the rendered JSON-LD, in the feed, and through cart and checkout.

Reviews and ratings — and the self-serving-review myth

review and aggregateRating remain documented, eligible Product properties for star ratings — nothing about that changed. Two rules to get right:

• Reviewer names must be a person or team, not promotional text. Google’s examples: “Not recommended: ‘50% off on Black Friday’. Recommended: ‘James Smith’ or ‘CNET Reviewers’.”
• Pros and cons structured data is editorial-only. Google: “Only editorial product review pages are eligible for the pros and cons appearance in Search results.” A merchant describing its own product can’t use it.

Now the myth I want to correct precisely, because it gets mangled constantly:

“Google killed review stars for product pages the same way it did for business reviews.” — False, and the distinction matters.

The self-serving-reviews restriction is scoped to LocalBusiness / Organization markup, not Product. Google’s wording: “If the entity that’s being reviewed controls the reviews about itself, their pages that use LocalBusiness or any other type of Organization structured data are ineligible for star review feature.” That policy dates to September 2019 and targets a business rating itself. Product review/aggregateRating are still eligible.

What has tightened is genuine-review enforcement more broadly — Google’s Reviews System, the Product Reviews updates, and site-reputation-abuse policy increasingly discount manipulated or incentivized ratings even where the markup validates. So the correct statement is: Product review stars are still eligible, but the ratings must be genuine, user-sourced, and about the product — not a blanket structured-data ban. Also don’t aggregate ratings from other sites into your own markup; Google’s guidance is a flat “Don’t aggregate reviews or ratings from other websites.” The deeper eligibility discussion lives in the Review schema and AggregateRating schema siblings rather than here.

Identifiers and trust signals: sku, gtin, mpn, brand

These are “recommended,” not “required,” in Search’s own spec — but they carry real weight on the Merchant Center / shopping side, where product matching against the global catalog depends on them:

• gtin — the global identifier (UPC/EAN/ISBN). The strongest matching signal; supply it whenever the product has one.
• mpn — manufacturer part number, for products without a GTIN.
• brand — the manufacturer/brand name (brand.name).
• sku — your own internal identifier.

Fill these in even though Search calls them optional; incomplete identifiers are a common reason a product is technically eligible yet underperforms in shopping surfaces where matching depends on them.

Return policy and shipping

For merchant listings, hasMerchantReturnPolicy and shippingDetails are recommended. Google’s steer: define the return policy once at the Organization level, not per-offer — “We recommend you provide a global return policy for your business under Organization markup instead… Only if some of your products have specific return policies… use this property under Offer.” That’s where the Organization schema sibling comes in — the site-wide return policy belongs there, with per-Offer overrides reserved for exceptions.

On images, Google recommends “multiple high-resolution images (minimum of 50K pixels when multiplying width and height) with the following aspect ratios: 16x9, 4x3, and 1x1.”

Why your valid markup still shows no rich result

Eligibility is not display. Mueller listed what it takes: “It requires that the page be indexed, that the page has valid structured data on it, and that our systems have determined that it’s worth showing this structured data.” That last clause is the one people forget — you can do everything right and Google can still decide not to surface the enhancement. Getting the markup correct only puts you in the running.

JSON-LD and the AI-shopping angle

Use JSON-LD — it’s Google’s recommended format and by far the most maintainable at ecommerce scale (it isn’t interleaved with your HTML and can be injected by your platform). Beyond classic rich results, there’s a growing practitioner theory that complete Product schema also helps AI shopping tools read and recommend products — worth flagging as an open, unverified angle rather than something Google’s Product structured-data documentation establishes or promises. Getting the markup right costs nothing extra either way, so treat it as a reasonable bet, not a guaranteed payoff.

For where Product schema sits in the wider structured-data picture, see the broader Schema Markup and Structured Data hubs this article nests under; for the full product page, see the product page SEO work in the ecommerce cluster.

AI summary

A condensed take on the Advanced version:

• What it is: schema.org/Product markup (usually JSON-LD) that labels a product page’s name, image, price, availability, identifiers, and reviews so search engines can produce shopping-style rich results.
• Two experiences, different strictness: product snippets (any product page; reviews/price; priceCurrency only recommended; price: 0 allowed) vs. merchant listings (transactional pages; require image, offers, and price > 0 with priceCurrency).
• Minimum for a product snippet: name + at least one of offers/review/aggregateRating. That’s snippet-specific — a merchant listing requires offers outright, not as one of three options. Only single-product (or variants-of-one) pages qualify; use ProductGroup for a variant line.
• Feed vs. markup (the key confusion): Product schema (on-page, validated via Rich Results Test / Search Console) is a separate system from a Google Merchant Center feed (submitted, validated via Merchant Center diagnostics). Google reconciles them and can borrow feed pricing; a feed is additive, not required. Price/availability must match across markup, feed, and checkout or Google flags a mismatch even if the JSON-LD is valid.
• availability enum: InStock, OutOfStock, PreOrder, PreSale, BackOrder, OnlineOnly, InStoreOnly, LimitedAvailability, Discontinued, SoldOut. Passing a plain string instead of the enum is a common error.
• Reviews: review/aggregateRating still eligible on Product; reviewer names must be a person/team, pros-and-cons is editorial-only. Myth corrected: the self-serving-review ban is scoped to LocalBusiness/Organization, not Product — but genuine-review enforcement (Reviews System, Product Reviews updates) discounts manipulated ratings regardless of markup validity.
• Identifiers: gtin (strongest match) > mpn > brand > sku — “recommended” in Search but load-bearing for shopping/Merchant Center matching.
• Return policy: default hasMerchantReturnPolicy at Organization level; per-Offer only for exceptions.
• Eligibility ≠ display: valid markup + indexed page + Google deciding it’s “worth showing.” Clean markup only makes you eligible.
• AI angle (unverified): some practitioners believe complete Product schema helps AI shopping tools read and recommend products — Google’s own documentation doesn’t establish this, so treat it as an open question, not a documented mechanism.

Official documentation

Primary-source documentation from the search engines.

Google — structured data (the markup side)

• Intro to Product structured data — the two experiences (product snippets vs. merchant listings) and the “structured data, feed, or both” relationship.
• Product snippet (Review, AggregateRating, Offer) structured data — required/recommended properties for the lighter product-snippet experience.
• Merchant listing structured data — stricter requirements, the price-greater-than-zero rule, return-policy and image guidance.
• Review snippet (Review, AggregateRating) structured data — the self-serving-review scope (LocalBusiness/Organization) and the “don’t aggregate” rule.
• Rich Results Test — validate the markup and check rich-result eligibility.

Google — the feed side (Merchant Center)

• Product data specification — required feed attributes and the price/currency consistency requirement across landing page, structured data, and checkout.
• Set up structured data for Merchant Center — how structured data and the feed relate on the Merchant Center side.

Bing / Microsoft

• Marking up your site with structured data — Bing’s general structured-data support (schema.org, JSON-LD recommended).

Quotes from the source

On-the-record statements from Google. Where a source page exposes the text, the link is a deep link that jumps to the quoted passage.

Google docs — the two experiences

• “Two markup types exist: Product snippets for non-purchase pages, emphasizing reviews, and Merchant listings for purchase pages, highlighting product details like sizing and shipping.” Jump to quote
• “Currently, product rich results only support pages that focus on a single product (or multiple variants of the same product).” Jump to quote

Google docs — structured data vs. Merchant Center feed

• “To provide rich product data to Google Search you can add Product structured data to your web pages, upload data feeds with Google Merchant Center and opt into free listings within the Merchant Center console, or both.” Jump to quote
• “Providing both structured data on web pages and a Merchant Center feed maximizes your eligibility to experiences and helps Google correctly understand and verify your data… product snippets may use pricing data from your merchant feed if it’s not present in the structured data on the page.” Jump to quote

Google docs — merchant listing rules

• “Unlike product snippets, merchant listing experiences require a price greater than zero.” Jump to quote
• “We recommend you provide a global return policy for your business under Organization markup instead… Only if some of your products have specific return policies… use this property under Offer.” Jump to quote
• “For best results, we recommend providing multiple high-resolution images (minimum of 50K pixels when multiplying width and height) with the following aspect ratios: 16x9, 4x3, and 1x1.” Jump to quote

Google docs — reviews

• On reviewer names: “Not recommended: ‘50% off on Black Friday’. Recommended: ‘James Smith’ or ‘CNET Reviewers’.” Jump to quote
• On pros and cons: “Only editorial product review pages are eligible for the pros and cons appearance in Search results.” Jump to quote
• On self-serving reviews (scoped to LocalBusiness/Organization): “If the entity that’s being reviewed controls the reviews about itself, their pages that use LocalBusiness or any other type of Organization structured data are ineligible for star review feature.” Review snippet docs
• “Don’t aggregate reviews or ratings from other websites.” Review snippet docs

Google — Merchant Center consistency

• Merchants must “accurately submit the product’s price and currency, and match with the price from your landing page, structured data, and at checkout.” Product data specification

John Mueller, Google (via Search Engine Journal)

• “It requires that the page be indexed, that the page has valid structured data on it, and that our systems have determined that it’s worth showing this structured data.” SEJ coverage
• “There’s also the possibility to submit a feed to your merchant center account, to show products there.” SEJ coverage

Product schema cheat sheet

The minimum for a product snippet

Product.name + at least one of offers / review / aggregateRating. A merchant listing always needs offers — that flexibility doesn’t apply there. Single-product pages only (use ProductGroup for a variant line).

Snippet vs. merchant listing — where they differ

availability enum values

InStock · OutOfStock · PreOrder · PreSale · BackOrder · OnlineOnly · InStoreOnly · LimitedAvailability · Discontinued · SoldOut

Markup vs. Merchant Center feed

Identifiers, by matching strength: gtin > mpn > brand > sku.

Fast facts

• Format: JSON-LD (recommended, most maintainable at scale).
• Valid markup = eligible, not guaranteed to show.
• Return policy: default at Organization level; per-Offer only for exceptions.
• Self-serving-review ban = LocalBusiness/Organization only, not Product.
• Images: multiple, min 50K px (w×h), aspect ratios 16x9 / 4x3 / 1x1.

Do I need Product schema, a Merchant Center feed, or both?

Work down the questions:

1. Is the page a single product (or one product’s variants)?

• No — it’s a category/collection page → Product schema isn’t eligible. Consider ProductGroup for a variant line, or breadcrumb/collection markup instead.
• Yes → continue.

2. Can the product be bought directly on that page?

• No (it’s an informational or editorial product page) → aim for a product snippet: name + offers and/or review/aggregateRating. priceCurrency recommended; price: 0 is allowed for free items.
• Yes → aim for a merchant listing: add image, offers with price > 0 and priceCurrency (required), plus availability, itemCondition, and ideally shippingDetails.

3. Do you want your products in Google Shopping / free listings and to maximize eligibility?

• Add a Google Merchant Center feed in addition to the on-page markup. It’s a separate system, but Google combines both and it broadens your eligibility. Not required to earn an on-page merchant listing — it’s additive.
• Keep it markup-only if you just want the on-page rich result and don’t need the Shopping surfaces.

4. Whichever path — before you ship:

• Validate the markup with the Rich Results Test and watch Search Console.
• If you have a feed, validate it separately in Merchant Center.
• Confirm price, priceCurrency, and availability match across markup, feed, and checkout. This is the step that keeps listings live after they validate.

Rule of thumb: on-page Product schema is the baseline for everyone selling a product; the Merchant Center feed is the additional layer for anyone who wants the Shopping/free-listings surfaces or maximum eligibility.

Product schema myths and mistakes to avoid

Myth: “Adding Product schema guarantees a rich result.” It only makes the page eligible. Per Mueller, the page also has to be indexed and Google’s systems have to decide the result is “worth showing.” Valid ≠ displayed.

Myth: “Product schema and my Merchant Center feed are the same submission.” They’re two systems with two validators. Google reconciles them (and can borrow feed pricing for a snippet), but fixing your JSON-LD does nothing for a broken feed, and a passing Rich Results Test says nothing about feed validity.

Myth: “Google killed review stars on product pages like it did for business reviews.” The self-serving-review ineligibility is scoped to LocalBusiness / Organization (a business rating itself, per the September 2019 policy) — not Product. Product review/aggregateRating are still eligible. What’s tightening is genuine-review enforcement (Reviews System, Product Reviews updates), which discounts manipulated or incentivized ratings even when the markup validates. Don’t conflate a content-quality crackdown with a structured-data ban.

Myth: “priceCurrency is always required.” It’s required for merchant listings but only “currently recommended” for basic product snippets.

Myth: “You need Merchant Center to get Shopping-style results.” On-page structured data alone can produce a merchant-listing rich result. The feed is an additive path, not a prerequisite.

Myth: “Any price format works as long as there’s a number.” Currency symbols, thousands separators, or a mis-nested priceSpecification routinely break validation. Keep price a bare number/string and priceCurrency a separate ISO code.

Mistake: marking up a category page as a Product. Product rich results only cover single-product (or single-product-variant) pages.

Mistake: fabricating or importing reviews. Reviewer names must be a person/team (not “50% off”), pros-and-cons is editorial-only, and you must not “aggregate reviews or ratings from other websites.”

Mistake: markup that doesn’t match the page. If the price/availability in your JSON-LD disagrees with the landing page, feed, or checkout, Google can flag a mismatch or suspend the item — even with valid markup.

Clean vs. broken Product JSON-LD

A clean merchant-listing-ready snippet

Single product, price greater than zero, correct currency, a proper availability enum URL, and a genuine aggregate rating:

{
  "@context": "https://schema.org/",
  "@type": "Product",
  "name": "Trailhead 30L Hiking Backpack",
  "image": [
    "https://example.com/img/backpack-1x1.jpg",
    "https://example.com/img/backpack-4x3.jpg",
    "https://example.com/img/backpack-16x9.jpg"
  ],
  "description": "Lightweight 30-liter pack with a ventilated back panel.",
  "sku": "TH-30L-GRN",
  "gtin": "0192341567890",
  "brand": { "@type": "Brand", "name": "Trailhead" },
  "offers": {
    "@type": "Offer",
    "url": "https://example.com/backpacks/trailhead-30l",
    "price": "129.00",
    "priceCurrency": "USD",
    "availability": "https://schema.org/InStock",
    "itemCondition": "https://schema.org/NewCondition",
    "priceValidUntil": "2026-12-31"
  },
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.6",
    "reviewCount": "218"
  }
}

The same snippet, broken

Every line flagged below is a real, common Search Console failure:

{
  "@context": "https://schema.org/",
  "@type": "Product",
  "name": "Trailhead 30L Hiking Backpack",
  "offers": {
    "@type": "Offer",
    "price": "$1,129.00",
    "priceCurrency": "dollars",
    "availability": "in stock"
  },
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.6"
  }
}

What’s wrong:

• price: "$1,129.00" — a currency symbol and thousands separator break the numeric parse. Use "1129.00".
• priceCurrency: "dollars" — must be a valid ISO 4217 code: "USD".
• availability: "in stock" — not a valid enum; use the URL form "https://schema.org/InStock". This produces the classic Invalid enum value in field “availability” error.
• No image — required for a merchant listing (it would fall back to a product snippet at best).
• aggregateRating with no reviewCount/ratingCount — an aggregate rating needs a count to be valid.

Common Search Console errors → fixes

Test yourself: Product Schema

Five quick questions on schema.org/Product, the two rich-result experiences, and the feed-vs-markup distinction. Pick an answer for each, then check.

Resources worth your time

My writing on this topic

I haven’t published a standalone Product schema guide of my own — so rather than point you at something that doesn’t exist, the honest move is to send you to the primary sources below and to the related structured-data work on this site. For the broader vocabulary and where Product fits, see the Schema Markup and Structured Data hubs; for the AI angle, Schema Markup for AI.

From around the industry

• Intro to Product structured data (Google Search Central) — the authoritative reference for the two experiences and the feed relationship.
• Merchant listing structured data (Google) — the stricter transactional requirements, return-policy and image guidance.
• Product snippet structured data (Google) — the lighter product-snippet property set and reviewer-name rules.
• Product data specification (Google Merchant Center Help) — the feed-side attributes and the price-consistency requirement across landing page, structured data, and checkout.
• Google Says How To Get More Product Rich Results (Search Engine Journal) — the Mueller quotes on eligibility vs. display and the feed option.
• What Is Schema Markup? How to Add It & Why It Matters (Ahrefs) — a general schema guide with a useful AI-agent/product-discovery angle.

Product Schema

Product schema (schema.org/Product) is structured data that tells search engines a page's product name, price, availability, and reviews so it can appear in Shopping-style rich results. It's separate from a Google Merchant Center feed, though Google reconciles the two.

Related: Schema Markup, Structured Data, Rich Results, ProductGroup Schema

Product Schema

Product schema is the schema.org/Product structured-data vocabulary you add to a product page — usually as JSON-LD — so search engines can read the product’s name, image, description, brand and identifiers (sku, gtin, mpn, brand), and nested Offer data (price, priceCurrency, availability), plus review/aggregateRating. Google uses it to power two distinct rich results: product snippets (star ratings and price on any product page) and merchant listings (fuller shopping-style results on pages where the item can be bought).

The most important thing to keep straight: Product schema markup and a Google Merchant Center product feed are two separate systems. The markup lives on your page and is validated with the Rich Results Test; the feed is a file you submit and Google checks with Merchant Center diagnostics. Google reconciles them (and can borrow feed pricing when your markup lacks it), but passing one validator says nothing about the other.

The minimum bar for any product rich result is name plus at least one of offers, review, or aggregateRating. Merchant listings are stricter — they require image, offers, and a price greater than zero with priceCurrency. Adding valid markup only makes a page eligible; Google still decides whether to show the enhancement.

Related: Schema Markup, Structured Data, Rich Results, ProductGroup Schema

Changelog