A Product schema with a name, price, and image is invisible to an AI shopping agent that needs to compare it against alternatives. Fourteen fields determine whether an agent can understand, trust, and recommend your product: name, image, description, brand, sku, gtin, offers, price, priceCurrency, availability, itemCondition, aggregateRating, review, and shippingDetails. The first three get you indexed. The next eleven get you compared and chosen. Most product pages stop at the first three. This is what each field does for an agent and which ones decide whether you make the shortlist.
Product schema written for Google's rich results and product schema written for AI shopping agents are not the same target, even though they use the same vocabulary. Rich results want enough to render a card. An agent wants enough to reason: can this ship to my user, is it actually in stock right now, how does its price compare in the same currency, is it trustworthy, what condition is it in. The fields that answer those questions are the ones that decide whether your product enters the agent's comparison at all.
The fourteen below split into two groups. The first three are table stakes, present on almost every product page. The remaining eleven are where products separate, because they are the fields an agent uses to compare and choose, and they are the ones most catalogs leave empty.
The three table-stakes fields
Name, image, and description get your product into the index, and almost every product page has them. Name is the canonical product label, and the same consistency rule applies as anywhere else: the name in your schema should match the name on the page and stay stable across every surface the product appears on. Image gives the agent something to show the user. Description is the prose the agent can quote when explaining the product. These three are necessary and nowhere near sufficient. A product with only these is a product an agent can display but cannot reason about, which means it loses every comparison to a product that filled in the rest.
The identity fields: brand, sku, gtin
These three let an agent match your product across stores, dedupe it, and verify it is the same item being sold elsewhere. Brand ties the product to a manufacturer entity. Sku is your internal identifier. Gtin is the global identifier (UPC, EAN, ISBN) that is the same number wherever the product is sold. The gtin is the one that matters most for cross-store reasoning, because it is how an agent knows your "Acme Widget Pro" and a competitor's listing are the literal same physical product, so it can compare on price and availability rather than guessing they might be related. Nesting these identity fields correctly inside the Product and merchant graph is what lets the agent resolve identity cleanly rather than treating your listing as an unverifiable standalone.
The commerce fields: offers, price, priceCurrency, availability, itemCondition
This is the cluster that decides whether the agent treats your product as buyable. Offers wraps the commercial terms. Price and priceCurrency must be present together and machine-typed, because an agent comparing prices across stores has to normalize currency, and a price with no currency is a number it cannot compare. Availability tells the agent whether the item is in stock right now, which is decisive: an agent will not recommend an out-of-stock product when an in-stock alternative exists, so a missing or stale availability value can drop you from the shortlist even when you have the better price. ItemCondition distinguishes new from refurbished from used, which the agent needs to match the user's intent. Keeping pricing and stock status accurate for AI is its own discipline, because these are the fields most likely to go stale and a stale commerce field is worse than a missing one.
The trust fields: aggregateRating and review
AggregateRating gives the agent a single trust signal: the average rating and the count behind it. Review gives it individual reviews it can read and quote. An agent ranking several comparable products uses these to break ties and to justify its recommendation to the user. A product with a strong aggregateRating and a healthy review count reads as a safer recommendation than an identical product with no ratings, even at the same price. The count matters as much as the score, because a 5.0 from three reviews is weaker than a 4.6 from four hundred, and the agent can read that difference when the count is present.
The logistics field: shippingDetails
ShippingDetails tells the agent whether the product can actually reach the user, at what cost, and in what timeframe. This is the field that converts a recommendation into a viable purchase, because an agent acting for a user in a specific location needs to know your product ships there before it recommends it. A product that cannot ship to the user is not a candidate no matter how good its price or rating, and an agent that cannot determine shipping from your schema may exclude you rather than risk recommending something undeliverable. This is the most commonly omitted of the fourteen and one of the most decisive for location-specific queries.
Why the bottom eleven decide the outcome
The pattern across all fourteen is that the table-stakes three answer "what is this," and the other eleven answer the questions that actually decide a recommendation: is it the same as that other listing, can I buy it, can I trust it, can it reach my user. An agent does not recommend a product it cannot reason about, and reasoning requires the comparison fields. This is the product-page equivalent of the empty-shell problem: the page looks complete to a human, and the agent cannot work with it.
The contrarian takeaway is that the prettiest product pages, the ones with rich photography and persuasive human-facing copy, are often the weakest in agent comparisons, because the effort went into the human layer while the machine layer stayed at name-price-image. Fill the eleven comparison fields, keep the commerce and logistics fields accurate rather than just present, and your products become reasoning-ready. This is also the foundation the UCP catalog layer builds on, so the schema work here pays off twice: once for direct agent comparison and once as the substrate for protocol-level commerce.
Sources
- Schema.org, Product type: the full field reference for the properties discussed. schema.org/Product
- Google, product structured data: required and recommended fields for product markup. developers.google.com
- Schema.org, Offer and shippingDetails: the commerce and logistics field definitions. schema.org/OfferShippingDetails
- Website AI Score, JSON-LD product nesting: how to structure the product and merchant graph. View article
- Website AI Score, pricing and stock for AI: keeping the commerce fields accurate, not just present. View article
