Documentation observes two-class product markup, Merchant Center precedence, and eligibility-versus-display gap

Eligibility rule or feature change

Google Search Central documentation divides product structured data into two main classes and describes the eligibility surfaces each one unlocks. Product snippets are scoped to pages where people cannot directly purchase the product and emphasize review-oriented fields such as pros and cons. Merchant listings are scoped to purchase pages and emphasize detailed product information, with apparel sizing, shipping details, and return policy information listed among the deeper options.

The documentation states that adding the required properties for merchant listings can also make a page eligible for product snippets, framing this as overlap rather than a duplicated rule set. Valid markup is only the first gate; the documentation is explicit that result enhancements are shown at the discretion of each experience and may change over time, and that price drops in particular are computed by Google by observing price changes over time and are not guaranteed to be shown. ](/seo/guides/does-a-clean-json-ld-check-guarantee-a-google-rich-result/) framing.

Separately, the documentation recommends adding structured data defining the policies of an ecommerce business, nested under Organization markup, with Merchant return policy and Loyalty Program called out by name. org pages alone can be generalized into Google behavior; for broader background on how the markup language works, the How Does Schema Markup Work: A Practical JSON-LD Guide lays out the JSON-LD mechanics this guidance assumes.

Markup and validation evidence

The Merchant listing documentation states that adding Product markup to a page can make it eligible for merchant listing experiences on Google Search, listing the shopping knowledge panel, Google Images, popular product results, and product snippets, and calling out that such listings can highlight price, availability, and shipping and return information. The companion documentation explicitly notes that some experiences combine data from structured data and Google Merchant Center feeds if both are available, and uses product snippets as a concrete example where pricing data may be drawn from the merchant feed when not present in the page's structured data.

For shipping and returns specifically, the older commentary reproduced in the source set states that Google will give preference to Google Merchant Center settings when merchants use both the Merchant Center and structured data. The published documentation recommends a two-stage validation workflow: the Rich Results Test during development, and the Rich result status reports after deployment, because templating or serving issues can break validity after deployment even when code looks clean in isolation. org documents its release and "pending" workflow while Google publicly outlines a plan to unify product schema markup with Merchant Center feed data](/insights/seo/schema-org-documents-its-release-and-pending-workflow-while-google-publicly/) thread has framed that Merchant Center preference as part of a longer-term plan to unify product schema with feed data, though that framing sits in commentary rather than in the Search Central text itself.

Display observations and bounded implementation advice

Three display-layer caveats bound any implementation reading of this documentation. First, enhancements such as ratings, pros and cons, shipping, availability, price drops, and returns are described as shown at the discretion of each experience and as potentially changing over time, which means the documentation itself models a display gap between eligibility and rendering. Second, price drops are explicitly flagged as not guaranteed to be shown, which is the clearest documentation-level example of an enhancement that is computable but discretionary.

Third, when both structured data and a Merchant Center feed are supplied, some experiences will combine them and others will prefer the feed; the documentation does not promise that the most recently updated source wins in every experience. The Reports observe product carousels returning inside Google AI Overviews for commercial queries coverage sits outside the Search Central documentation itself and should be treated as observation of an adjacent surface rather than as documentation of behavior.

Operationally, the documentation is most safely read as defining eligibility, not outcome: a valid JSON-LD block is a prerequisite for a rich result, and monitoring the Rich result status reports after deployment is the documented way to detect post-launch breakage.

Knowledge Delta

EVIDENCE: new — two-class division (Product snippets vs Merchant listings) is documented as the framing; Organization-nested Merchant return policy and Loyalty Program are documented as recommended additions; Merchant Center precedence for shipping/returns and the combine-or-prefer model for merchant data are documented. MECHANISM: documentation separates markup validity (Rich Results Test), eligibility (required properties + Organization-nested policy markup), and actual display (discretionary per experience; price drops computed from observed changes, not guaranteed).

org alone can over-implement fields Google ignores or under-implement the Organization-nested nesting Google recommends. UNCERTAINTY: confirmation status is unconfirmed for any specific ranking, traffic, or display-rate change tied to this documentation; the documentation explicitly models the gap between eligibility and display. DECISION: do not rewrite an existing deployment based on this documentation alone; use it as a validation checklist and confirm rendering with the Rich Results Test plus Rich result status reports.

FALSIFIABLE FOLLOW-UP SIGNAL: a controlled rollout that changes only Organization-nested Merchant return policy markup, then tracks the Rich result status reports and a stratified SERP sample, would distinguish a real eligibility effect from documentation churn.

Public Action Brief

ACTION LEVEL: Test first HIGH IMPACT CHANGE: NO WHAT TO DO NOW: Inventory existing Product and Merchant listing structured data against the two-class division, add Organization-nested Merchant return policy markup where applicable, and validate candidate URLs through the Rich Results Test before rollout. org-only examples. WHAT NOT TO CHANGE YET: do not strip existing markup that already passes the Rich Results Test on the assumption that this documentation deprecates prior fields; do not switch feed-versus-markup precedence assumptions on country or content-type segments that the documentation does not specifically call out, and do not rewrite copy or pricing in pursuit of price-drop rendering, since price drops are explicitly not guaranteed to be shown.

MEASUREMENT BASELINE: current Rich Results Test pass rate, current Rich result status reports coverage, and a baseline SERP sample stratified by country and device for product-result surfaces. MEASUREMENT METRICS: change in Rich result status reports coverage and warnings; change in observed display rate of shipping and return information in merchant listing experiences; any new appearance of Organization-nested policy markup in rendered results. MEASUREMENT SEGMENTS: country, device (mobile vs desktop), merchant vs non-merchant page template, and presence or absence of a Google Merchant Center feed.

OBSERVATION WINDOW: one full crawl-and-index cycle plus a stratified SERP sample window of sufficient breadth to detect per-country and per-device display differences. WHAT WOULD CHANGE THIS CONCLUSION: an official Google blog post or Search Central release-notes entry that codifies Merchant Center precedence as a global rule, or a structured-data feature deprecation notice, would upgrade the evidence class from verified observation of documentation to an official change and would justify acting now rather than testing first.

WHEN TO REVIEW: at the next Search Central documentation revision, or sooner if an official change is published that supersedes the current documentation text. APPLICABILITY: merchants operating Google Merchant Center feeds alongside page-level Product structured data, and any site whose templates emit Merchant listing structured data on purchase pages. RISK BOUNDARY: the documentation models a deliberate gap between eligibility and display, so implementation work is bounded by what the Rich Results Test and Rich result status reports can verify, not by what the documentation promises will render.