Product snippets vs merchant listings

Understand the two product structured-data experiences and their separate Search Console reports.

GSC UI required Intermediate

Use product-snippet requirements for pages about a product when visitors cannot purchase it directly from the site, such as editorial reviews and product aggregators. Use merchant-listing requirements for product pages where customers can buy from the site.

Both features use Product structured data and overlap substantially. Merchant listings require a purchasable offer and richer commerce data; meeting their required properties generally also makes the page eligible for product snippets.

This guide reflects Google's documentation on July 18, 2026.

The deciding question: can the visitor buy here?

Page type	Primary markup requirements	Why
Editorial review of one product	Product snippet	The publisher describes or reviews the product but is not selling it on the page
Product comparison or aggregator page focused on one product	Product snippet	Offers or reviews can be aggregated without the site being the seller
Affiliate page linking to another seller	Product snippet	The customer cannot complete the purchase on this site
Merchant product detail page with checkout	Merchant listing	The site sells the product directly
Marketplace offer page where the site is the seller of record	Merchant listing	A purchasable offer exists on the page
Category or search-results page listing unrelated products	Neither product rich-result pattern	Google product rich results focus on a single product or variants of one product

Google's Search Console definition of an online merchant excludes affiliate sites and sites that redirect users elsewhere to finish the purchase.

Do not choose merchant-listing markup merely because a page shows a price. The page must let the shopper purchase the product from the merchant represented by the offer.

How the Search experiences differ

Product snippets

A product snippet is an enhanced text result that can show product information such as:

Review ratings.
Review information.
Price.
Availability.
Editorial pros and cons for eligible review pages.

It is appropriate for non-merchant product content as well as certain product offers. It does not require the site to be the seller.

Merchant listings

Merchant listings cover fuller shopping experiences and always include a price. Search Console's Performance documentation describes the segment as shopping features other than product snippets, including experiences such as popular products and shopping knowledge panels in Web Search and Google Images.

Merchant markup supports more detailed commerce information, including:

Purchasable offer and current price.
Availability and condition.
Shipping cost and delivery time.
Return policies.
Product variants and apparel attributes.
Unit, sale, and member pricing.
Loyalty programs and merchant policies.

Eligibility does not guarantee that Google will display any specific format.

The minimum required data is different

Google changes feature documentation over time, so implementation teams should treat the live documentation as definitive. The following is the current minimum decision framework, not a substitute for every nested-type rule.

Product snippet minimum

At the Product level, provide:

name.
At least one of review, aggregateRating, or offers.

If offers is used:

It can be an Offer or AggregateOffer.
An Offer needs price or priceSpecification.price.
priceCurrency is recommended to remove ambiguity.
A zero price can describe a free product offer under the documented product-snippet rules.

Every nested Review, AggregateRating, Offer, or AggregateOffer must also satisfy the requirements for that type.

Merchant listing minimum

At the Product level, provide:

name.
image.
offers containing an Offer.

The Offer requires:

A current price or priceSpecification.price greater than zero.
priceCurrency or priceSpecification.priceCurrency.

An AggregateOffer is not sufficient for a merchant listing because the page's merchant must be the seller of the specific offer.

Minimum comparison

Property or rule	Product snippet	Merchant listing
`Product.name`	Required	Required
`Product.image`	Recommended	Required
`review`, `aggregateRating`, or `offers`	At least one required	Optional reviews; `offers` required
`Offer` versus `AggregateOffer`	Either can be used when applicable	`Offer` required
Active price	Required when `Offer` is used	Required and greater than zero
Currency	Recommended for `Offer`	Required
On-site purchase	Not required	Required

Do not interpret “minimum” as “best implementation.” Product identity, availability, condition, canonical offer URL, price validity, shipping, returns, and identifiers make merchant data more useful and verifiable.

Properties that usually belong in both

Where accurate and visible or otherwise permitted by the feature documentation, include:

name.
description.
High-quality image URLs.
brand.
sku.
The applicable GTIN property or mpn.
review and aggregateRating when based on genuine, visible review content.
Accurate offers data.

Use the most specific valid product identifier. Do not invent a GTIN, SKU, brand, rating, or review to remove a Search Console warning.

Structured data must describe the product and information visible on the page. A mismatch can make the feature ineligible and can create Merchant Center problems when a feed is also used.

Merchant-specific commerce detail

Merchant listing markup can describe details that do not belong to a simple editorial review:

Offer URL.
Availability.
Item condition.
Price-valid-until date.
Sale and strikethrough pricing.
Unit pricing.
Member prices and loyalty tiers.
Shipping destinations, rates, handling, and transit time.
Product-level return policies.
Apparel size, color, material, pattern, age, and gender attributes.
Certifications and energy-efficiency information where applicable.
3D models for supported product assets.

Many of these are optional enhancements, but optional does not mean arbitrary. Add only the details that apply and follow every required nested property.

Organization-level shipping, return, and loyalty policies can reduce duplication. When both organization-level and product-level return-policy markup exist, Google uses the product-level policy for that product.

Editorial pros and cons belong to review pages

Google's positive and negative notes feature is for editorial product review pages. It is not for:

Merchant product pages.
Customer review text.
Marketing claims written by the seller.

For an eligible editorial review, use positiveNotes and/or negativeNotes inside the review and provide at least two statements in total under the current requirements.

Pros and cons should summarize an actual editorial assessment. Do not mark ordinary feature lists as independent review conclusions.

Both features support product variants

Use ProductGroup with product variant data when several products are variations of the same parent, such as sizes, colors, materials, or patterns.

Important relationships include:

ProductGroup.productGroupID.
ProductGroup.variesBy.
ProductGroup.hasVariant, or Product.isVariantOf.
A more specific name and applicable attributes for each variant Product.

Variant markup does not replace the ordinary requirements. Each Product still needs the required merchant-listing or product-snippet properties for the intended experience.

Both single-page and multi-page variant designs are supported when implemented according to Google's URL and canonical guidance. Do not use AggregateOffer to model variants; it represents multiple offers for a product, not related product variations.

Page-level eligibility rules

Product rich results currently focus on pages about:

One specific product.
Multiple variants of the same product.

A category such as “all running shoes” is not a single product. Marking every card in a broad category page as though the page were one product does not create valid product-page eligibility.

When a product is offered in multiple currencies, Google recommends a distinct URL for each currency. Keep each page's visible price, structured data, canonical signals, and any Merchant Center landing-page data consistent.

For merchants, Google recommends putting Product data in the initial HTML when optimizing for shopping experiences. JavaScript-generated markup can make shopping crawls less frequent or reliable, which is especially risky for fast-changing price and availability.

Why there are two Search Console reports

Search Console can show separate Product snippets and Merchant listings rich-result reports under Shopping.

The reports are separate because the eligibility requirements differ. Google documents an important overlap rule:

The Merchant listings report includes checks for product snippets that use Offer data.
The Product snippets report therefore needs to be consulted for non-merchant pages such as reviews and aggregators.

This prevents merchant teams from treating every shared requirement as two independent bugs.

Product snippets report only

This is normal when the site contains editorial reviews or aggregators with review, aggregateRating, or non-merchant offer data but does not sell the product directly.

It can also mean Google's current report sample contains product-snippet items but no valid merchant-listing items.

Merchant listings report only

This can occur when the site consists primarily of purchasable product pages. Merchant listing validation includes the relevant product-snippet checks for offer-based pages, so absence of a separate Product snippets report does not by itself mean those merchant pages cannot earn a product snippet.

Both reports

This is expected for sites with a mixture of page types, such as:

A store with purchasable product detail pages.
A separate editorial review or buying-guide section.

Fix issues according to the page's role. Do not add checkout-oriented offer data to an editorial page simply to move it into the merchant report.

Neither report

Possible explanations include:

Google has not found valid supported product markup.
Product pages are not indexed.
Markup is unparsable or rendered unreliably.
Pages are blocked or require authentication.
Google has not recrawled recent changes.
Search Console's representative sample does not expose the expected items.

Use the Rich Results Test and URL Inspection on representative URLs.

Rich-result reports are not Merchant opportunities

The Merchant opportunities report is a separate Search Console feature for sites Google identifies as eligible online shops selling physical goods.

Possible combinations are meaningful:

Rich-result reports present, Merchant opportunities absent: Google found product structured data but does not recognize the site as an eligible online shop.
Merchant opportunities present, rich-result reports absent: Google recognizes the merchant, but has not found applicable structured data in the report sample.

Report presence is not proof of a Merchant Center association, and a Merchant Center association is not required for basic organic product rich-result eligibility.

Structured data and Merchant Center feeds complement each other

Google supports three approaches to supplying product data for Search:

Product structured data on the site.
A Merchant Center feed with free-listing participation.
Both.

Google recommends both for merchants because the sources can maximize eligibility and help Google understand and verify data. Some experiences combine them; for example, product snippets can use pricing from a Merchant Center feed when the page's structured data does not contain it.

The sources must agree. Align:

Product identity and URL.
Price and currency.
Availability.
Condition.
Shipping and returns.
Variant identifiers.
Brand, GTIN, MPN, and SKU.

Merchant Center automatic item updates can use landing-page structured data to correct temporary price, availability, or condition mismatches. Google explicitly says this is not a replacement for regularly updating product data.

Search Console reports structured-data eligibility; Merchant Center reports feed processing, product approval, and commerce-program requirements. A valid Search Console merchant item can still have a Merchant Center disapproval, and the reverse problem can also occur.

A reliable implementation workflow

1. Classify the page

Record whether the site sells the product directly, reviews it, aggregates offers, or sends the user elsewhere. Choose the primary requirement set from the actual transaction path.

2. Map visible data to properties

Create a source-of-truth map for product identity, offers, reviews, shipping, returns, and variants. Every structured value should come from governed product or editorial data, not duplicated template constants.

3. Implement the minimum valid graph

For a product snippet, start with Product.name plus the appropriate review, rating, or offer branch.

For a merchant listing, start with Product.name, Product.image, a specific Offer, active price, and currency. Then add accurate availability, condition, URL, identifiers, and applicable enhancements.

4. Test every commercial state

Use the Rich Results Test for:

In-stock and out-of-stock products.
Full-price and sale-price offers.
Products with and without reviews.
Variant and single-product pages.
Products missing global identifiers legitimately.
Editorial review and merchant product templates.

5. Verify production rendering

Test the exact production URL. Inspect rendered HTML, especially when JavaScript injects price, availability, reviews, or variants.

6. Compare indexed evidence

Use URL Inspection to confirm Google indexed the intended canonical and detected the expected product item. If the live page is correct but indexed evidence is old, allow recrawling or request indexing for a small number of important pages.

7. Monitor the correct report

Use the Merchant listings report for purchasable offer pages and the Product snippets report for non-merchant product content. Fix template causes before starting issue validation.

8. Measure actual appearances separately

In Performance → Search results, use the Product snippets and Merchant listings Search appearance filters when they are available for the property.

Validity counts are not appearance counts. A page can be valid without receiving the feature, and appearance changes can reflect demand, ranking, query mix, device, country, or Google's presentation choices.

Common implementation mistakes

Using `AggregateOffer` for a merchant listing

Merchant listings require the merchant's specific Offer. Use AggregateOffer for an aggregate of multiple offers in an appropriate product-snippet context, not as a replacement for a purchasable merchant offer.

Omitting currency

Currency is recommended for product snippets and required for merchant listings. Always provide the correct three-letter ISO 4217 code with an offer price.

Marking a category page as one product

Product rich results focus on a single product or its variants. Category and internal search pages need a different content and data model.

Treating an affiliate link as an on-site offer

If users must leave the site to complete the purchase, the page is not an eligible online-merchant product page under Search Console's definition.

Adding editorial pros and cons to merchant pages

The pros-and-cons appearance is for editorial review pages, not seller-written marketing content or customer reviews.

Allowing feed and page data to drift

Price, availability, condition, and identity mismatches can undermine trust and cause Merchant Center issues. Update both sources from compatible product data and monitor mismatch errors.

Publishing stale price-valid-until dates

An expired priceValidUntil can prevent the offer from displaying. Omit the property when it does not apply rather than publishing a stale date.

Generating unstable markup with JavaScript

Intermittent or slow rendering makes product data unreliable for crawlers. Prefer stable initial HTML for merchant product data when possible and test rendered production pages repeatedly across template states.

Inventing identifiers or reviews

Missing optional data is better than false data. Never fabricate a GTIN, rating, review count, shipping promise, or return policy to clear a warning.

Diagnose report changes

Merchant valid items fall

Check:

Price and currency output.
Missing image or Offer nodes.
Availability and product-data feed changes.
Product-page indexing.
JavaScript or API failures.
URL, canonical, or variant changes.

Product snippet items rise unexpectedly

Identify whether new editorial or aggregate pages were indexed or merchant pages lost properties needed for merchant-listing eligibility. A movement between reports can reflect a data-model regression.

Search appearance drops while reports remain valid

Technical eligibility is intact. Investigate demand, rankings, feature selection, device and country mix, feed status, and Google reporting anomalies before changing markup.

Reports pass but Merchant Center shows disapprovals

Open Merchant Center diagnostics. Search Console does not test every feed attribute, account policy, landing-page rule, or program requirement.

What Search Console can and cannot conclude

It can show:

Which supported product item types Google sampled.
Critical and non-critical structured-data issues.
Whether known issue instances passed validation.
Recorded Product snippets or Merchant listings Search appearances when available.

It cannot prove:

That every product page was checked.
That a valid item appeared in Search.
That a Merchant Center product is approved.
That page data and the merchant feed match completely.
That product markup improved ranking or CTR.
That a site is recognized as an eligible merchant from a rich-result report alone.

Decision checklist

The page's transaction path is classified correctly.
Non-purchase review and aggregator pages use product-snippet requirements.
On-site purchase pages meet merchant-listing requirements.
Product pages focus on one product or its variants.
Merchant Product includes name, image, and a specific Offer.
Merchant price is greater than zero and includes currency.
Product-snippet Product includes a review, aggregate rating, or offer.
Pros and cons appear only on eligible editorial review pages.
Variant relationships use ProductGroup, not AggregateOffer.
Visible, structured, and Merchant Center data agree.
Production rendered output is tested.
The appropriate Search Console report is monitored.
Validity and Performance appearance are reported separately.