Structured data for AI: the Product, Offer and FAQ agents look for

For a search engine and an AI agent to understand your store unambiguously, product by product you need a handful of schema.org types written as JSON-LD: Product (what the product is), Offer (price, currency and availability), AggregateRating and Review (opinions, but only real ones), BreadcrumbList (where the product sits in the store), FAQPage (questions and answers) and Organization (who you are as a seller). Structured data is not decoration for Google; it is machine-readable facts a model can take at face value, compare against competitors and surface in a recommendation, instead of guessing from a bag of words scattered across the page. Below: which types matter, how to implement them correctly, and the mistakes that draw a penalty instead of visibility.

Why AI agents need this more than classic Google

Search engines have long been able to extract meaning from raw HTML, so structured data was a bonus: it helped show stars, price or a breadcrumb in the results. An AI agent works differently. When an assistant compares products across several stores or picks a recommendation, it needs hard, unambiguous facts: how much it costs, in what currency, and whether it is in stock. Prose cannot be read reliably, because "£29, last few left, free shipping over £50" is, to a machine, a mixture that must be interpreted and is easy to get wrong. The same product expressed in Offer as price, priceCurrency and availability is computable without interpretation.

That is why availability is written as a full schema.org address, for example https://schema.org/InStock or https://schema.org/OutOfStock, rather than as the word "available" or a boolean. This is not a formality. The full URL points to one specific concept in the schema.org vocabulary, identical for every store in the world, so an agent compares like with like. The less you leave to guessing, the greater the chance your product enters the comparison at the right price and status, instead of being skipped as ambiguous.

Six schema.org types every store must describe

Each type carries a different set of facts, and together they describe the product, the offer and the seller so none of them has to be guessed:

One type = one set of unambiguous facts. Property names shown as you write them in JSON-LD.

Product and Offer: the heart of the listing

Product describes identity: name, image, sku or gtin, brand and a description. Those fields are how an agent learns that your "Kyusu teapot 300 ml" and the same product in another store are one thing. The heart, though, is the Offer node nested inside Product, because it carries the buying decision. A complete Offer has four things you must not skip: price (the number alone, no currency in the field), priceCurrency as an ISO code (PLN, EUR, GBP), availability as a full URL, and url pointing to the product. Add itemCondition and priceValidUntil when the price has an expiry.

Availability values are a closed vocabulary: among others https://schema.org/InStock, https://schema.org/OutOfStock, https://schema.org/PreOrder and https://schema.org/BackOrder. You pick the one that matches the real state shown on the page. Here is the minimal, correct block for a single product:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Kyusu teapot 300 ml",
  "sku": "KYU-300",
  "brand": { "@type": "Brand", "name": "Your Brand" },
  "offers": {
    "@type": "Offer",
    "price": "39.00",
    "priceCurrency": "EUR",
    "availability": "https://schema.org/InStock",
    "url": "https://yourstore.com/kyusu-300"
  }
}
</script>

AggregateRating and Review: real data only

AggregateRating (ratingValue plus reviewCount or ratingCount) and individual Review nodes are a strong trust signal and the source of stars in results. They carry a hard condition, though: they must match real opinions the user sees on that same page. The number in reviewCount is the count of actual reviews, and ratingValue is their real average. Do not attach a whole-brand score to a single product, and do not pull in ratings gathered elsewhere that are invisible on the product page.

BreadcrumbList, FAQPage and Organization: context and trust

BreadcrumbList describes the navigation path (a sequence of ListItem nodes with a position and name), so both the search engine and the agent see where the product sits in the store instead of inferring it from the URL. FAQPage turns a questions-and-answers section into ready pairs to extract, but the same rule as with reviews applies: you mark up only questions and answers actually visible on the page, not a hidden set added for SEO. Organization describes the seller (name, logo, channels in sameAs) and lets you tie every offer to one credible entity, which tells AI systems who actually stands behind the product.

How to implement it correctly: JSON-LD in a script tag

Google recommends JSON-LD embedded in <script type="application/ld+json">, placed in the head or body of the page. The format is separate from the visible HTML, so it is easier to maintain than microdata woven into tags. There are three practical rules. First, the data must be in the code the crawler receives, so on server-rendered (SSR) pages the JSON-LD should ship with the HTML rather than being injected by a script after load. Second, one block describes one entity (or a connected graph), not everything at once with no structure. Third, values come from the same source as the page content: the price in JSON-LD is the same price the customer sees, pulled from the same place, not typed in separately alongside.

The mistakes that draw a penalty instead of visibility

Four mistakes recur most often, and each can turn structured data from an asset into a problem:

• Data that mismatches what the user sees: the JSON-LD states a different price, a different availability, or a product not on the page. That is structured-data spam outright and a real risk of a Google manual action.
• AggregateRating without real reviews, or a whole-page or whole-brand score attached to a single product. A common trigger for manual actions, as covered above.
• Incomplete Offer: no priceCurrency or availability, price as a "from X" range, currency in the price field. The product drops out of some results and loses its clarity.
• Markup for content that is not on the page: hidden FAQs, invisible reviews, data added only for the crawler. The rule is simple: you mark up what the user actually sees.

Validation: before you publish

Before you ship changes, check them with two tools, because they answer different questions. Google's Rich Results Test tells you whether the page qualifies for specific rich results and what Google actually read. The Schema Markup Validator at validator.schema.org checks general correctness against the schema.org vocabulary, independent of Google. Test on the live URL after deploying, not just on pasted code, to catch differences with rendering. After publishing, keep an eye on the structured-data reports in Search Console. Neither tool promises a ranking or an outcome; they only confirm the data is correct and readable.

From correct data to visibility in AI

Structured data is the price of entry to visibility in generative search and agentic commerce, not a shortcut. Without an unambiguous Product, a complete Offer and honest reviews, your store stays a body of text a model has to interpret and can easily skip in favour of a competitor that stated the facts outright. We unpack this further in the pieces on preparing your store for agentic commerce and on GEO for ecommerce. If you want to start on the technical side, our AI library has a ready JSON-LD generator for Product and FAQ, and we run the implementation and upkeep of structured data across a whole store as our AI Visibility service. To be plain: correct structured data improves the odds of your offer being understood unambiguously, but no one guarantees a Google ranking or a citation by AI systems.