Product Snippet or Merchant Listing? Marketplace Guide

Before you write a single line of Product markup for a marketplace page, answer three questions. Can the shopper buy the product on this page? Does the page focus on one product? Who is the seller named in the offer? Google's product structured data page (Opens in a new tab) splits product markup into two experiences, product snippets for pages where people cannot directly purchase the product and merchant listings for pages where customers can purchase from you, and the answers decide which one you build. Marketplace developers, sellers and SEO owners all work from the same fork. Examples use one product category: headphones.

Interface labels are given in quotation marks in English. If your interface is in another language, names may look different.

Three questions that decide the markup

Marketplaces apply one template to every page that mentions a product. Google's documentation does not support that shortcut. It sets conditions per experience, and each condition is a question about the page.

Table: The three questions and where each answer leads

Each question gets its own treatment, with a headphone marketplace as the running example.

What the two experiences are

Product snippets

Google's overview describes product snippets as the markup for product pages where people cannot directly purchase the product, with more options for review information such as pros and cons. According to the product snippet documentation (Opens in a new tab), the required property is name, plus at least one of review, aggregateRating or offers. The offers property can be an Offer or an AggregateOffer. The Search Console report for these pages is "Product snippets", described for product reviews and aggregator sites.

Pros and cons have conditions of their own. Only editorial product review pages are eligible for that appearance, and you must provide at least two statements about the product. A seller's own listing page with buyer comments does not meet the condition.

Merchant listings

The overview describes merchant listings as markup for pages where customers can purchase products from you, with more options for detailed product information such as apparel sizing, shipping and returns. The merchant listing documentation (Opens in a new tab) makes three properties required: name, image and offers, with offers being a nested Offer that sells the product. It adds that only pages where a shopper can purchase a product are eligible, and pages that merely link to other sites selling the product do not qualify. The matching report is "Merchant listings".

Table: The two experiences side by side

Google adds that meeting the merchant listing requirements can make product pages eligible for product snippets too. That sentence matters for a purchasable page: complete merchant listing fields serve both experiences.

Single-product pages only

Google's product snippet page says product rich results support only pages that focus on a single product (or multiple variants of the same product). A category page for over-ear headphones, a seller storefront or a search result list therefore does not fit, however many product cards it holds. The documentation read here has no statement on any other product markup type for list pages.

Practical suggestion: write the decision down per template. A template inventory for a headphone marketplace might look like this.

Table: Template inventory

Write a one-sentence reason in each row. A year later, a new developer asking why the category template has no Product markup finds the answer in the inventory.

Mixed pages

A page can offer a headphone for purchase and also carry an editorial review of the same model. Because complete merchant listing fields can also qualify a page for product snippets, a purchasable page with all merchant fields covers both. The pros and cons appearance still needs an editorial review page; do not mark up a listing page for it.

Required fields, side by side

Merchant listings need name, image and a nested Offer in offers. Product snippets need name and one of review, aggregateRating or offers. Google lists many recommended properties for merchant listings, among them aggregateRating, brand.name, category, description, the gtin variants, review and sku. It also states that the more properties you add, the more enhancements the page can be eligible for, and it does not promise that any enhancement will appear.

Table: Fields and their role

Example scenario: a headphone listing

Example scenario: a seller lists a pair of wireless over-ear headphones, and the shopper can add them to a cart on the listing page. For merchant listings the page needs the product name, the main photo address and an Offer carrying price, currency and availability. Recommended fields include description, brand.name if the seller has a brand, sku and a real aggregateRating and review only if the page shows genuine ratings. A listing with no reviews gets no aggregateRating field at all.

Practical suggestion: let the template omit a field when the listing has no value for it. An empty string or a placeholder is worse than absence, because it creates a mismatch between markup and page.

Offer, AggregateOffer and the seller question

Google's merchant listing page says merchant listings require an Offer because the merchant has to be the seller of the product. The product snippet page accepts Offer or AggregateOffer, describes an AggregateOffer as a kind of Offer representing an aggregation of other offers, and says not to use AggregateOffer to describe a set of product variants.

Table: Choosing the offer type

Color variants

A headphone model sold in black, white and sand is a set of variants. Google's only statement here is the prohibition on describing variants with AggregateOffer. The overview also names product variants as a separate topic. Practical suggestion: if each color has its own listing address, give each page a single Offer for that color.

One model, several sellers

The merchant listing documentation has no section on marketplaces, so it does not settle how a catalog page with many sellers for one model should be marked up. Practical suggestion: use one page per listing, so that the shopper who starts checkout on the page does so with one named seller, and the page carries an Offer tied to that seller.

Shipping and returns: three places, one order

Google's merchant listing page says shipping and returns can be defined in Merchant Center or in Search Console instead of in markup. When the same information is defined in several places, the order of precedence runs from the product-level Merchant Center feed, the strongest, to organization-level markup, the weakest.

For a marketplace this is a design decision. If shipping and return terms differ by seller, a policy set once at the organization level conflicts with what each seller offers. Practical suggestion: generate listing-level terms from one source. Do not hand-write the same terms separately for the feed and for the markup.

Review rules worth knowing

Two review statements in the snippet documentation affect templates. A reviewer's name must be a valid name for a Person or Team. The pros and cons appearance is limited to editorial product review pages. Practical suggestion: keep seller-written listing text and buyer comments out of the pros and cons structure, and use review markup only for review content the page really shows.

Script-rendered markup

The product page says markup produced with JavaScript can make Shopping crawls less frequent and less reliable. If your listing pages render on the client, price and availability are the fields most likely to change, so deliver them in server-sent HTML.

Applying the fork to an existing marketplace

A marketplace that already carries Product markup rarely has it in the right places. A cleanup follows a fixed order, and each step produces something you can check.

1. List every template that outputs Product markup today, including blog and campaign templates that borrowed the listing component.
2. Classify each template with the three questions: purchase on the page, single product, named seller.
3. Remove product markup from templates that fail the single-product question.
4. For purchasable listings, complete name, image and a nested Offer; for review pages, complete name and one of review, aggregateRating or offers.
5. Replace any AggregateOffer used for color or size variants.
6. Record the valid and invalid counts in the matching Search Console report, release, and compare a few days later.

The order matters because step three shrinks the number of pages carrying markup before steps four and five add fields. Removing misplaced markup first keeps the later comparison readable.

Example scenario: five headphone pages

Example scenario: a marketplace audits five pages. A listing for wireless over-ear headphones with a cart button gets merchant listings fields. A listing whose only action is a "Visit seller" link is not a merchant listing candidate. An editorial review of a studio model is a product snippets candidate. The category page "Bluetooth headphones" loses its Product markup. A buying guide that mentions ten models carries none.

Table: The five pages and their decisions

What sellers must supply

Markup is only as good as the listing data behind it. The seller form decides whether a template can write required fields at all. For merchant listings that means a product name, at least one usable photo and the price, currency and availability that make up the Offer. Recommended fields come from optional form inputs: description, brand, sku and identifiers such as gtin.

Practical suggestion: mark the required inputs as required in the form and show sellers which inputs feed the page, so that a missing photo is fixed at upload and not discovered in a report weeks later. Do not let sellers type a rating or review summary by hand; ratings belong to genuine reviews shown on the page. Google's merchant listing page is explicit that its guidelines apply to the markup, and a hand-typed rating with no visible basis would conflict with the idea that markup describes the page.

A test set before release

One sample listing cannot cover the states a headphone listing can be in.

Table: Listing states and expected behavior

Run the set again whenever the template changes. The check should confirm that each visible value on the page matches the value in the markup.

Example scenario: a sold-out pair

Example scenario: a seller's headphones sell out. The page stays live and tells shoppers the item is gone. The markup has to carry the same status as the page; a page that says sold out while the markup says available is a mismatch. The detail of availability values belongs to the dedicated guides on that topic. Here the point is that the template takes the status from one source.

Reading the two reports

Google ties two Search Console reports to two page types: "Merchant listings" for pages where shoppers can buy, "Product snippets" for other product-related pages such as reviews and aggregator sites. After significant site changes, Google says to watch for increases in invalid items, and a drop in valid items may mean the markup is no longer embedded. To fix problems, correct the invalid items, inspect the live URL with the URL Inspection tool and request validation in the status report. Recrawling and reindexing can take several days, and the Performance report shows how many times pages appear as rich results, clicks and average position.

Practical suggestion: note the valid and invalid counts before a template release, and compare them a few days after. If a purchasable listing shows up in the snippet report, check whether a merchant field is missing or whether the page failed an eligibility condition.

Google does not guarantee that features consuming structured data will show up in search results, and a manual action causes the structured data to be ignored. The documentation can change, so check Google's current pages before you finalize a template.

Decision log

A short log keeps choices readable. Record the template name, page type, chosen experience, required fields and their data sources, known limits (for example, no documentation for multi-seller catalog pages) and the date of the last check. Review the limits against Google's three pages every few months, and note the date. If one of the pages gains a new statement, reopen the decision for that template.

When Google's pages change

The three pages used here are living documents. Practical suggestion: assign one person to compare them against your decision log every few months. If a page adds a property to the required list, or changes the wording on eligibility, mark the templates affected and re-run the test set. A log with dated checks turns an unexpected report spike into a question with a short list of suspects.

Who owns what

Table: Ownership of markup decisions

Checklist before release

Checklist: choosing and shipping product markup

• Is the purchase flow on the page itself?
• Does the page focus on one product?
• For merchant listings, are name, image and a nested Offer in offers present?
• For product snippets, is name present with one of review, aggregateRating or offers?
• Is AggregateOffer kept away from variants?
• Does every written field match something visible on the page?
• Are pros and cons limited to editorial review pages?
• Are shipping and return terms generated from one source?
• Are price and availability in server-delivered HTML?
• Is the matching Search Console report being watched?

Mistakes to avoid

Putting merchant listing fields on every page

A page that sends shoppers to another shop does not qualify. Check the function of the page before writing fields.

Marking up list pages

Product rich results support single-product pages. Writing one product's fields onto a category page puts the wrong markup on the wrong page.

Describing colors with AggregateOffer

Google says not to use it for variants. Prefer one address and one Offer per variant.

Placeholder fields

An invented rating, an empty brand name or a made-up review creates a mismatch between page and markup. If there is no data, leave the field out.

Treating the template as finished

A new photo component, a changed checkout flow or a redesigned listing layout can silently break the markup. Re-run the test set on every template change, watch the invalid-item count in the matching report and confirm that visible values still equal markup values. Make the test part of the release process so that nobody has to remember it, and keep the decision log current so the next change starts from a written record rather than from guesses about why a template was built the way it was.

Presenting markup as a promise

Google does not guarantee that features consuming structured data will appear. Describe pages as eligible, not as certain to show a result.

Frequently Asked Questions

What is the difference between product snippets and merchant listings?

Per Google, product snippets are for product pages where people cannot directly purchase the product, and merchant listings are for pages where customers can purchase from you.

Which fields do merchant listings require?

Google's merchant listing page lists name, image and offers as required, with offers being a nested Offer.

Can I use AggregateOffer on a marketplace listing page?

Merchant listings require an Offer because the merchant must be the seller. The product snippet page accepts Offer or AggregateOffer, and says not to use AggregateOffer to describe product variants.

Can I add Product markup to a category page?

Google says product rich results support only pages that focus on a single product.

Where should shipping and returns be defined?

Google allows markup, Merchant Center or Search Console. When several places define the same information, the product-level Merchant Center feed is strongest and organization-level markup is weakest.

Does structured data guarantee a rich result?

No. Google does not guarantee that features that consume structured data will show up in search results.

Conclusion

Choosing structured data for a marketplace product page comes down to a fork and a check. If the shopper can buy on the page, build merchant listings: name, image and a nested Offer. If not, consider product snippets: name plus one of review, aggregateRating or offers. Then confirm that the page focuses on one product, since list pages do not fit product rich results. Keep AggregateOffer away from variants, generate shipping and return terms from one source, and let every field match what the page shows.

Once your templates are settled, reach more shoppers with your listings. To see where they can appear, explore the ad spaces. For the general Product schema framework, read the product schema markup guide.