Sign in Start free

Product Schema That Earns Listings

Valid schema and eligible schema are different things. Product markup only earns a rich listing when the required fields are present, consistent with what the page visibly shows, and the identifiers resolve. Most implementations pass validation while missing the fields that actually trigger the enhancement, or contradict the rendered page in a way that suppresses it silently.

CATEGORY
Ecommerce SEO
FORMAT
product-schema-that-earns-listings.md
STEPS
6
PRICE
Free - no account
WHEN TO REACH FOR THIS

Use when product pages are valid in the rich results test but show no price, rating, or availability in the search listing.

The skill file

product-schema-that-earns-listings.md
---
name: product-schema-that-earns-listings
description: Use when product pages are valid in the rich results test but show no price, rating, or availability in the search listing.
---

# Product Schema That Earns Listings

Valid schema and eligible schema are different things. Product markup only earns a rich listing when the required fields are present, consistent with what the page visibly shows, and the identifiers resolve. Most implementations pass validation while missing the fields that actually trigger the enhancement, or contradict the rendered page in a way that suppresses it silently.

## What you need first

- the rendered DOM of a product page, not the source HTML
- your GTIN, MPN, and brand data coverage across the catalog
- Search Console merchant listings and product snippet reports

## Method

1. Validate against the rendered page, since a lot of ecommerce templates inject price and stock client-side and the crawler may see a different value than your JSON-LD claims.
2. Ship offers with price, priceCurrency, availability, and priceValidUntil. A missing currency alone is enough to suppress the price in the listing while still validating.
3. Populate gtin where you have it and mpn plus brand where you do not. Identifier coverage is what separates merchant listing eligibility from a plain product snippet.
4. For variant products use a single product with an offer for each variant, or aggregateOffer with lowPrice and highPrice. Do not emit one Product object per variant on one URL.
5. Only mark up aggregateRating where the reviews are genuinely on that page and visible. Aggregating site-wide ratings onto every product is the most common cause of a structured data manual action.
6. Track the Search Console merchant listings report weekly rather than retesting single URLs - it shows which items are eligible at scale and which are being filtered out.

## What this produces

Product JSON-LD that passes the merchant listing eligibility bar, not just the validator, verified against the rendered page.

## Where this goes wrong

- JSON-LD price drifting from the displayed price because one is cached and the other is not, which suppresses the enhancement silently
- reusing one site-wide review score as aggregateRating on every product page
- omitting priceCurrency or shipping details and assuming a valid test result means the listing will show

---

From the QuQi skill library - https://www.quqi.io/skills/product-schema-that-earns-listings
Free to download · no account, no email

What you need first

  • the rendered DOM of a product page, not the source HTML
  • your GTIN, MPN, and brand data coverage across the catalog
  • Search Console merchant listings and product snippet reports

Method

  1. 01 Validate against the rendered page, since a lot of ecommerce templates inject price and stock client-side and the crawler may see a different value than your JSON-LD claims.
  2. 02 Ship offers with price, priceCurrency, availability, and priceValidUntil. A missing currency alone is enough to suppress the price in the listing while still validating.
  3. 03 Populate gtin where you have it and mpn plus brand where you do not. Identifier coverage is what separates merchant listing eligibility from a plain product snippet.
  4. 04 For variant products use a single product with an offer for each variant, or aggregateOffer with lowPrice and highPrice. Do not emit one Product object per variant on one URL.
  5. 05 Only mark up aggregateRating where the reviews are genuinely on that page and visible. Aggregating site-wide ratings onto every product is the most common cause of a structured data manual action.
  6. 06 Track the Search Console merchant listings report weekly rather than retesting single URLs - it shows which items are eligible at scale and which are being filtered out.

What this produces

Product JSON-LD that passes the merchant listing eligibility bar, not just the validator, verified against the rendered page.

Where this goes wrong

  • JSON-LD price drifting from the displayed price because one is cached and the other is not, which suppresses the enhancement silently
  • reusing one site-wide review score as aggregateRating on every product page
  • omitting priceCurrency or shipping details and assuming a valid test result means the listing will show

Use this skill in your own AI

The download is a plain markdown file with the name and trigger in its frontmatter. Where an assistant supports skills it can load itself, that frontmatter is what it reads to decide this one applies.

Claude Code Save it as ~/.claude/skills/product-schema-that-earns-listings/SKILL.md and Claude loads it on its own when what you are doing matches the trigger line. Put it in .claude/skills inside a project instead if the whole team should have it.
Claude Upload the file in the skills section of your settings. Once it is there it applies itself in any conversation where the trigger fits, so you do not have to remember it exists.
ChatGPT There is no skills format to install into, so paste the file contents into a Project instruction or a Custom GPT instead. It then applies to every chat in that project rather than only the one you paste it into.
Anything else Paste the markdown into the chat before your question. It works in any assistant, it just has to be pasted again each time.

Questions about this skill

When do I need this rather than another pass through the rich results test?

When product pages validate cleanly and still show no price, rating or availability in the listing. Retesting single URLs until the validator is green cannot help, because valid and eligible are different bars. Use this when the gap sits between what the markup claims and what the rendered page and your identifier coverage actually support.

What do I need before touching the product markup?

The rendered DOM of a product page rather than view source, your GTIN, MPN and brand coverage across the catalogue, and the Search Console merchant listings and product snippet reports. Many ecommerce templates inject price and stock client side, so testing the source tells you nothing about what the crawler resolved. Without coverage figures you cannot separate a markup fault from a data gap.

What does the corrected markup look like, and which part decides eligibility?

Product JSON-LD verified against the rendered page, with offers carrying price, priceCurrency, availability and priceValidUntil, and identifiers populated where you hold them. Identifier coverage is the part that decides outcomes, since it separates merchant listing eligibility from a plain product snippet. The weekly merchant listings report is how you then read eligibility at catalogue scale.

Which mistake here risks the whole catalogue?

Reusing one site wide review score as aggregateRating on every product page. It is the most common cause of a structured data manual action, and an action removes enhancements across the whole catalogue rather than on the pages at fault. Mark up ratings only where the reviews sit on that page and are visible to a reader.

More in Ecommerce SEO