# Product Schema (JSON-LD) for AI Shopping

> Product JSON-LD is the machine-readable layer agents trust when your page and feed disagree: ship Offer, price, availability, and review fields, or the agent guesses.

<!-- Product JSON-LD is the machine-readable layer agents trust when your page and feed disagree: ship Offer, price, availability, and review fields. -->
<!-- Canonical: https://agentmint.net/product-schema-for-ai-shopping/ · By Abdalsalaam Halawa · Published 2026-07-07 -->
<!-- Evidence tags below are load-bearing: <Claim type="spec-fact|reported|hypothesis"> marks how each factual claim is sourced. -->

<KeyTakeaways
  items={[
    "Product JSON-LD isn't a ranking trick: it's how you hand an agent the selection signals (price, availability, reviews) in a form it can read without guessing.",
    "When your live page and your submitted feed disagree, we expect an agent to trust the machine-readable layer on the page, because it is unambiguous where scraped text is not.",
    "The schema fields that matter are the ones that map to selection signals (Offer price and availability, and genuine review or rating fields), not decorative markup.",
    "Retail product pages average only 66 out of 100 for machine readability, so how completely your structured data is filled in is a real lever, not a checkbox.",
    "Never ship empty or misleading schema: fabricated reviews, prices your page doesn't show, or FAQ/HowTo markup that misrepresents the page is a dark pattern that risks trust and manual actions.",
  ]}
/>

## Why product schema is the agent's tie-breaker

An AI shopping agent doesn't read your product page the way a person does. It parses it. The cleanest thing on the page to parse is the structured-data block: the JSON-LD an agent can lift field by field without interpreting your layout, your marketing copy, or your CSS. <Claim type="spec-fact" source="schema.org, Product" href="https://schema.org/Product">Product, and the nested Offer type it carries, are defined by the open schema.org vocabulary, the same structured-data standard search engines have read for years.</Claim> That vocabulary is official-docs turf: the exact field names and their syntax are schema.org's to define, and we link to them rather than restate them.

What this page is about is narrower and it is ours: *which* of those schema signals actually shift whether an agent selects you, and why an agent leans on schema in the first place. The reason is ambiguity. Everything an agent needs to score you (is this in stock, what does it cost, how well is it reviewed) is exactly the data that structured markup states unambiguously and that free-text page copy states messily. Those selection signals, and the evidence behind them, are the subject of the hub for this cluster, [how AI shopping agents choose products](/how-ai-agents-choose-products/); this page is about how you hand those signals over in a form an agent trusts.

## Which schema fields carry selection weight

Not every field on a Product node changes an outcome. The ones that do are the ones that map directly to a signal an agent is already scoring:

1. **`Offer` with `price` and `priceCurrency`**: price is one of the strongest, most model-variable selection levers, so an unambiguous machine-readable price beats a number an agent has to scrape out of your page copy.
2. **`Offer` `availability`**: an agent that can't confirm you can fulfil an order has an easy reason to skip you; stating availability in schema removes that doubt.
3. **`review` and `aggregateRating`**: rating depth moves selection, so genuine review data belongs in structured form. Only mark up ratings that are real and visible on the page (see the anti-pattern section below).
4. **Product identifiers** (`gtin`, `brand`, `sku`): these help an agent resolve your item to a known product and reconcile it against a feed rather than treating it as an unknown.

The point of listing these is not to teach the markup: schema.org already does that better than we could. The point is that these are the fields worth auditing first, because they are the ones tied to a decision. And completeness is itself the lever: <Claim type="reported" source="Adobe Digital Insights, Vivek Pandya" href="https://business.adobe.com/blog/ai-traffic-surge-retail-sites-not-machine-readable" date="2026-04-16">on Adobe's AI Content Visibility Checker, retail product pages score an average of 66 out of 100 for machine readability, meaning roughly a third of a typical product page is not machine-readable to an agent at all.</Claim> The gap between a page that scores well on its [machine-readability score](/glossary/#machine-readability-score) and one that doesn't is usually the fields above, left empty.

## Feed versus schema: what an agent trusts when they disagree

Most stores expose product data through two channels at once. One is the **feed**: the structured product data you submit to a platform (a Merchant Center feed, or a protocol product feed), covered in depth in [make your product feed AI-readable](/make-product-feed-ai-readable/). The other is the **schema** an agent reads off your live product page. When both agree, this is academic. When they disagree (a stale feed, a price the page updated but the feed didn't), an agent has to pick a version.

<Claim type="hypothesis">When a store's feed and its live product page disagree, the machine-readable layer an agent can parse directly from the page is the version we expect it to trust, because on-page JSON-LD is the current, unambiguous state of the item, where a feed can lag and page copy can mislead.</Claim> We label that an inference, not a measured fact. But it is why schema is worth shipping even when you already run a clean feed: it is the tie-breaker that keeps a data mismatch from quietly costing you the selection.

<Illustrative>
  A shopper's agent is comparing two sleep masks. Your feed, refreshed nightly, still lists last week's price and "out of stock." Your product page (updated this morning) shows the new lower price and "in stock," and says so in its Product/Offer JSON-LD. The agent that reads the page has an unambiguous, current answer; the agent that only trusts the stale feed skips you over a problem you already fixed. Keeping schema and feed in sync closes that gap.
</Illustrative>

## What not to do: no empty or misleading markup

This is the section where the temptation to game schema is strongest, and where doing so backfires. The rule is simple: **mark up only what is true and visible on the page.**

- **No fabricated reviews or ratings.** Inventing `aggregateRating` values, or marking up reviews that don't exist on the page, is exactly the kind of fake signal our whole approach exists to argue against, and it is a well-known trigger for search manual actions.
- **No phantom fields.** Don't state a price, availability, or offer in schema that the page itself doesn't show. Empty or contradictory markup is a mismatch an agent can catch, and it erodes the trust that made schema a tie-breaker in the first place.
- **No misleading FAQ or HowTo markup.** It is tempting to wrap thin content in these types to look richer. It no longer even earns the visual payoff: <Claim type="reported" source="Google, FAQPage structured data documentation" href="https://developers.google.com/search/docs/appearance/structured-data/faqpage" date="2026-05-07">Google retired HowTo rich results in 2023. FAQ rich results were first restricted to authoritative government and health sites that same year, then fully retired for all sites effective May 7, 2026, so marking up how-to steps or FAQs on a store page no longer produces a rich result in search for anyone.</Claim> This is also why every how-to page on this site uses `TechArticle`, not `HowTo`: the type should describe what the page genuinely is.

The honest version of "richer schema" is completeness of the true fields, not decoration, and never invention.

## Validating your schema (link out for the syntax)

Validation is official-docs turf, and the tools are free, so use theirs rather than a rewrite of ours. Paste a product URL into [Google's Rich Results Test](https://search.google.com/test/rich-results) to see what Google parses, and check the shape of your markup against the [schema.org Product reference](https://schema.org/Product) and [Offer reference](https://schema.org/Offer). The goal isn't a passing badge: it's confirming that the fields that carry selection weight are present, accurate, and match what a shopper sees on the page.

## Apply this in ChatGPT and Gemini

Schema is one of the levers, not the whole game. It works alongside a complete [product feed](/make-product-feed-ai-readable/) and titles a shopper actually searches, and which engine reads which data over which rail is its own decision. See [UCP vs ACP: which gets you selected](/ucp-vs-acp/). To turn this into per-engine work, pair it with the platform playbooks: [ChatGPT shopping optimization](/chatgpt-shopping-optimization/) and [Gemini and Google AI Mode shopping ranking](/gemini-shopping-ranking/). Ship the true fields, keep them in sync with your feed, validate with the official tools, and let the machine-readable layer speak for you when the agent is deciding.