Product Schema Markup: Which Google Variant Your Pages Actually Qualify For

You added product schema markup to every product page, the Rich Results Test comes back green, and three weeks later the listings still look like plain blue links. No price, no stars, no availability. Nothing is broken, and that is the confusing part: passing validation and qualifying for a rich result are two separate bars, and Google splits product pages into two variants that ask for different things.

Most guides hand you one property list and stop there. That list is the reason a lot of correct markup never earns anything in search.

Google reads a buyable page and a review page differently

Google documents product structured data as two distinct appearances, and which one you are eligible for depends entirely on what a visitor can do on the page. The requirements live in separate reference pages: product snippets and merchant listings.

Product snippets cover pages where a purchase is not possible: editorial reviews, comparison roundups, spec pages, buying guides. Merchant listings cover pages where a shopper can buy the item directly. Google restricts merchant listings to "only pages where a shopper can purchase a product," which is the line that quietly excludes category and collection pages no matter how well-formed their markup is.

Get the variant wrong and you optimize for an appearance you were never in the running for. A store owner adding positiveNotes to a checkout page and an affiliate site adding shippingDetails to a review are making the same mistake in opposite directions.

The required properties differ more than most implementations assume

The two variants share a type but not a bar to clear.

Two details in that right-hand column catch people out. Merchant listings require image, which product snippets do not, so a review page ported to a store template can pass one bar and fail the other. And Google requires the merchant listing price to be greater than zero, so "call for pricing," "$0.00" placeholders, and unreleased pre-orders are not eligible, whatever the validator says about syntax.

priceCurrency takes a three-letter ISO 4217 code. Writing $ or USD $ instead of USD is one of the more common silent failures.

The offer properties most stores leave empty

Required gets you eligible. Recommended is where the listing actually gets more surface area, and this is the section most product schema markup implementations skip because nothing warns you that it is missing.

• availability: an ItemAvailability value such as InStock, OutOfStock, or BackOrder. Google specifically recommends it so shoppers know before they click.

• shippingDetails: an OfferShippingDetails object carrying rates, destinations, and delivery timeframes. Google's stated reason is total cost clarity, and free shipping is the case worth marking up first.

• hasMerchantReturnPolicy: a MerchantReturnPolicy covering return window, conditions, and any fees.

• itemCondition: new, used, or refurbished. Skippable for most new-goods stores, load-bearing for resale.

• brand, description, aggregateRating, url: Google calls description strongly recommended, and it is usually already sitting in your product template.

Google also documents return policy and loyalty program markup at the organization level rather than on each product, which is worth knowing before you duplicate the same return policy block across a few thousand pages.

Why do pros and cons never show up on store pages?

Because Google restricts that appearance to editorial reviews. The positiveNotes and negativeNotes properties nest inside a Review, and Google states plainly that "only editorial product review pages are eligible for the pros and cons appearance in Search, not merchant product pages or customer product reviews."

So an ecommerce PDP can carry those properties, validate cleanly, and never render them. If you publish reviews or comparisons, this is one of the few genuinely underused wins available: you need at least two statements across the positive and negative lists combined.

The mismatch that disqualifies a page without any error

Structured data has to describe what is actually on the page. Mark up a price of 49.00 while the page displays 59.00, or claim InStock on a sold-out item, and you have a policy problem rather than a syntax problem. No validator flags it, because every validator only sees your markup, not your rendered page.

This is where dynamic pricing, regional currency switching, and stale cached JSON-LD do real damage. The markup was right the day it shipped and drifted afterwards.

Image requirements are worth a second look too: Google asks for at least 50,000 pixels from width times height, and prefers 16x9, 4x3, or 1x1 crops. Thumbnail-sized images in the image property are a quiet disqualifier on merchant listings, where the property is required rather than optional.

How do you check this across a whole catalog?

One URL at a time does not scale, and that is the practical gap in almost every product schema markup guide. The Rich Results Test checks a single page. Imagine a store with 800 SKUs across a dozen templates: you can confirm the template is right, but you cannot confirm that every variant, every out-of-stock item, and every legacy product imported three platforms ago still emits valid markup.

The failures that cost money are never uniform. They cluster in the edge cases: discontinued items with an empty price, bundles missing image, imported products where priceCurrency never got mapped.

The check worth running is crawl-wide rather than page-wise: pull every product URL, extract the JSON-LD, and group pages by which required property is missing. That turns a vague "our schema is fine" into a list of URLs with a shared cause. CrawlTide extracts and parses the JSON-LD on every page it crawls, tracks Product as a high-value type, and compares each crawl against the last, so pages that lost schema coverage or started emitting invalid blocks show up as a change rather than a page-by-page hunt.

Does product schema help with AI search visibility?

It helps assistants get your facts right, which is not the same claim as helping you rank. An AI answer that quotes a price has to get that price from somewhere, and parsing it out of rendered HTML is guesswork compared with reading a declared price and priceCurrency pair.

Nobody outside the engines can tell you how heavily structured data is weighted in AI answers, and any guide quoting a precise figure for it is guessing. What you can control is ambiguity: when your availability and price are machine-readable and match the page, there is one answer to give. When they are not, an assistant either skips your product or invents a number from a stale third-party listing.

That argues for keeping markup accurate on the long tail, not just the bestsellers. Out-of-stock and discontinued products are exactly where drift accumulates and exactly where a confident wrong answer does the most damage.

Where product markup sits next to the rest of your structured data

Product schema markup describes items. It does not tell a search engine or an AI assistant who is selling them, which is a separate job handled by Organization and WebSite markup at the site level. Stores that get product markup perfect and skip the site-level entities end up with well-described products attached to an ambiguous seller.

If your JSON-LD foundations are shaky, fix those first: our guide to JSON-LD and structured data covers the format itself, and WebSite schema covers the site-level entities that product pages hang off.

Start with the variant question, because everything downstream depends on it. Decide whether each template is a merchant listing or a product snippet, confirm the required properties for that variant, then fill in shippingDetails, hasMerchantReturnPolicy, and availability on the templates that qualify. Run a crawl with CrawlTide to see which of your product pages are missing required properties right now.