Structured data for AI shopping agents: the fields that decide whether you get quoted

Most stores that fail agent readiness fail on the same thing: the price, availability and product name a shopper sees are assembled by JavaScript in the browser, and the raw HTML an agent fetches contains none of them. Server-rendered structured data is what makes a product page answerable — and it is testable in one command. This guide covers what agents actually read, which fields matter, and how to check your own pages.

What an agent sees is not what you see

Open a product page in a browser and everything is there. Fetch the same URL with a plain HTTP client and you may get a shell: a page frame, some scripts, and empty containers that the browser would have filled in.

Assistants and crawlers vary in how much JavaScript they execute, and the ones that do execute it are slower, cheaper to skip, and less consistent. Assuming rendering is a bet you lose quietly — nothing errors, your product simply is not in the answer.

The test that matters:

curl -s https://yourstore.com/products/your-product | grep -c "application/ld+json"

If that returns 0, an agent reading your page has no structured description of the product. Then check the raw HTML actually contains the product title and price as text — not as a template placeholder.

The fields that decide whether you can be quoted

Product JSON-LD has many optional fields and a handful that do real work. In rough order of impact:

• name — the product name, matching what is on the page. A mismatch between JSON-LD and visible text is a quality signal against you.
• offers.price and offers.priceCurrency — a number and an ISO currency code. A price without a currency is unusable, and a currency mismatch with the page is worse than no price at all.
• offers.availability — an explicit InStock / OutOfStock URL value. Absent availability means an assistant either omits your product from a "can I buy this now" answer or guesses.
• image — at least one, with a real URL. Agents increasingly build visual comparisons.
• description — the actual product description, not the store tagline repeated on every product.
• sku / gtin — identifiers let an agent match your listing to the same product elsewhere. This is how you appear in comparisons rather than as an unmatched item.
• brand — cheap to include, frequently used to filter.

Variants are where most catalogs get vague. If a product has real variants with different prices, a single offer with one price misrepresents the page. Either express the range with AggregateOffer (lowPrice, highPrice, priceCurrency) or list the variants as separate offers with their own SKUs. Picking one variant's price and presenting it as the product's price is how "the site said EUR 19" complaints start.

Getting availability honest

Availability is the field most likely to be wrong, because it is the one that changes. Two habits keep it useful:

• Reflect the real inventory state, including "available to order but not in stock" if that is what you mean — schema.org has values for backorder and preorder, and using them is better than a flat InStock that turns into a cancellation email.
• Do not cache it into stale. If your page is served from a long cache while inventory moves, an agent gets a confident answer that was true an hour ago. This is the one field worth thinking about cache lifetime for.

Beyond the product page

Product markup gets you into product answers. Two other types decide whether you get into the questions that come before and after a purchase:

• Organization, on the home page — who you are, your logo, your URL, and sameAs links to the places you also exist. This is what lets a model reconcile your store with your other presences instead of treating each as a separate unknown entity.
• FAQPage, on pages that genuinely answer questions — shipping, returns, sizing, compatibility. Assistants answering "does this ship to Austria" prefer a structured answer over a paragraph they have to interpret.

Both are cheap, and both are about being resolvable rather than merely present. An agent that cannot tell whether two mentions of your brand are the same business will hedge.

Rules that keep markup trustworthy

Structured data that disagrees with the page is worse than none — search engines treat it as spam, and models learn to distrust the source.

• Only mark up what is visible. A price in JSON-LD that appears nowhere on the page is a violation, not a shortcut.
• One product per product page. Marking up a whole collection as a single product confuses everything downstream.
• No invented reviews. AggregateRating with numbers you cannot substantiate is the fastest way to lose the markup entirely — and it is the one that gets manual action.
• Keep it in the HTML. JSON-LD injected by a tag manager after load is exactly as invisible as the rest of your client-side rendering.

Checking the whole catalog, not one page

One good product page proves the theme is capable. It does not prove the catalog is consistent — and inconsistency is normal: products imported at different times, variants added later, images missing on the long tail.

The checks worth running across a sample rather than a single page:

• Does every sampled product render its title and JSON-LD in raw HTML?
• Does every offer carry a price and a currency?
• Is availability present and specific?
• Do images exist, and do they have alt text? Missing alt text is both an accessibility gap and a lost description.
• Are product type and category set, so an agent can place the item in a taxonomy?

Sichta runs these as deterministic checks across a sample of your live catalog and reports each product that fails, which is more actionable than a single score. The point is not the number — it is the list of products to fix.

The short version

Fetch your own product page with curl before believing anything about agent readiness. Ensure name, price with currency, and specific availability are in server-rendered JSON-LD, express variants as a range or as separate offers rather than picking one, add identifiers so you can be matched in comparisons, and put Organization and FAQPage markup where they belong. Never mark up what is not on the page, and check a sample of the catalog rather than your best product.