Product schema that AI actually reads

The myth of the magic code

In GEO, you often hear two opposite promises: “LLMs ignore schema” and “just install Product schema to show up in ChatGPT.” Both oversimplify. Structured data has specific consumers and purposes: Google uses markup to understand content and enable rich results; OpenAI publishes its own feed specification; a web search may retrieve the HTML and other representations of the page.

The right question is not “which code does AI read?” It is: which system needs to receive which data, through which channel, with what guarantee of freshness?

Methodology and criteria

We compared official documentation as of July 2026: Product and Offer on Google Search Central, the Schema.org vocabulary, OpenAI commerce feeds and Google's guidance for AI experiences. “Read” means the platform documents ingesting that format — not that every field is a ranking factor. Google states that valid data makes the page eligible, but does not guarantee a rich result.

The four layers

1. Visible HTML: the editorial source of truth

The customer needs to see the name, description, variants, measurements, price, stock, policy and reviews. When JSON-LD claims something the page doesn't show, the implementation loses credibility and may violate guidelines. HTML carries what doesn't fit into rigid fields: how to choose, which context it suits, limitations and comparisons between versions.

2. Schema.org: the grammar of the page

Product says “this entity is a product.” Offer describes the sale. AggregateRating summarizes ratings; Review represents an individual one; ProductGroup organizes variants. SKU, GTIN and MPN distinguish items. For merchant listings, Google can highlight price, availability, shipping, returns and ratings in Search, Images and product experiences.

3. Feeds: the operational layer of the catalog

Feeds are not optional copies of the schema — they are their own interface for keeping the catalog in sync. In OpenAI's stable specification, title, description, URL, brand, image, price, availability, seller and target countries are among the core data, with provisions for variants, policies, reviews and Q&A. The feed updates price and stock without waiting for the page to be reinterpreted — crucial in catalogs with thousands of SKUs.

4. External signals: the validation layer

Reviews on independent sources, editorial mentions, official profiles and consistent data confirm identity and context. No amount of your own schema turns a commercial claim into independent proof.

The minimum core of a PDP

• →@type: Product;
• →name and description;
• →image;
• →brand.name;
• →sku and, when applicable, gtin or mpn;
• →offers.url;
• →offers.price e priceCurrency: BRL;
• →offers.availability;
• →offers.itemCondition;
• →aggregateRating and review only when real and visible.

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Medium Plain Hoop Earring in 925 Silver",
  "description": "925 silver hoop, 22 mm diameter with a snap closure.",
  "image": ["https://loja.exemplo.com.br/imagens/argola-prata-925.jpg"],
  "sku": "ARG-925-22",
  "brand": {"@type": "Brand", "name": "Example Brand"},
  "offers": {
    "@type": "Offer",
    "url": "https://loja.exemplo.com.br/argola-prata-925",
    "priceCurrency": "BRL",
    "price": "129.90",
    "availability": "https://schema.org/InStock",
    "itemCondition": "https://schema.org/NewCondition"
  },
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.8",
    "reviewCount": "37"
  }
}

The example is illustrative. The final implementation must follow the platform's current requirements, reflect the visible content and include only true data.

Fields that reduce ambiguity

Identifiers

SKU as a stable internal key. GTIN when the product has a valid commercial code (use the most specific type). For in-house manufacturing without a GTIN, brand and MPN help. Don't invent codes just to fill the field.

Variants

Color, size, voltage and finish should not be crammed into a confusing offer. Each variant needs identification, URL and availability consistent with the actual purchase. Group them with ProductGroup or the structure the feed requires.

Offer, shipping and returns

Use BRL and the expected value format; the marked-up price must match the option that is actually purchasable. For a purchase recommendation, total cost, delivery time and return risk matter — Google offers shipping and return properties, and OpenAI includes return policy and window in the feed.

Reviews and Q&A

AggregateRating summarizes score and volume; Review preserves individual ratings. Don't mark up aggregated ratings from another product or from the store as if they belonged to that SKU.

The most important rule: consistency

Imagine the same offer diverging: PDP R$ 149.90 in stock; JSON-LD R$ 129.90 sold out; feed R$ 139.90 in stock; marketplace showing an image of a different variant. Every format is readable, but the record is semantically poor — the greater the divergence, the greater the chance of showing wrong information or losing trust. Treat the catalog as a single source that publishes to page, schema and feeds, with automated price/stock updates and governance over description, attributes and identifiers.

“More schema” isn't necessarily better

Excessive markup creates maintenance and risk. Prioritize properties that describe something real and visible, differentiate the product, change the purchase decision, are supported by the data consumer and can be kept up to date. Avoid:

• →repeating keywords across fields;
• →marking up FAQ that doesn't appear on the page;
• →using AggregateRating without real ratings;
• →duplicating conflicting Product blocks;
• →assigning the “starting at” price to an unavailable variant;
• →mixing store ratings with product ratings;
• →letting different plugins generate competing schemas.

Implementation and validation

1. Inventory — a sample with a simple product, variants, a promotion, a sold-out item, a launch and an item without a GTIN. 2. Single source — define the system responsible for price, stock, description, identifier and policy, with an update frequency per destination. 3. Markup — generate JSON-LD in the PDP template, without manual entry per product. 4. Testing — Rich Results Test, URL inspection, feed validation and a visual comparison between page and data. 5. Monitoring — valid items, warnings, rejections and divergences; after any theme or template change, run the test again.

Conclusion

The schema that AI “actually reads” is not a universal block — it's a system of consistent representations. HTML explains, JSON-LD classifies, the feed updates, external signals validate. The advantage doesn't come from adding the largest number of properties, but from building a complete, unambiguous and synchronized product record that different engines can retrieve, compare and recommend with less risk.