Which JSON-LD schema types do AI assistants weigh for product citations?

Which structured data types do AI assistants actually weigh when they decide to cite a product page?

Beyond the FAQPage block everyone talks about, generative engine optimization lives in a handful of JSON-LD types that retrieve the exact facts an assistant needs to answer a comparison, a compatibility question, or a trust check. This guide ranks the structured data that moves AI citations on real product pages and shows where to put each one.

AI retrieval systems look for the most convenient, least-ambiguous statement of a fact. Well-formed JSON-LD is that statement: typed, dated, and machine-readable. When a shopper asks an assistant whether an item ships free, the assistant wants to find the shipping statement bound to the Offer that also carries the price in the same currency. Plain copy works, but typed facts get quoted more often because they do not need inference.

• Product + Offer. This is the spine. A Product node with its Brand, Sku, and image, opening onto an Offer that holds price, priceCurrency, availability, and itemCondition, gives an assistant the shell of a citable answer. When the visible page text matches these fields, retrieval trusts the whole record.
• ShippingDetails. Availability tells an assistant an item is in stock; ShippingDetails tells it when and at what cost it arrives. Bound to the Offer, it lets an assistant state a delivery window instead of guessing from a click-away shipping policy.
• AggregateRating with Review. Assistants pull rating and review counts from these to answer "is this brand reliable?" Keep the ratingCount honest; a verified count is worth more than a padded one, because inconsistency flags the record.
• BreadcrumbList. Lightweight but useful for category context and for answering "which store is this" in a way that disambiguates one merchant from another with a similar name.
• MerchantReturnPolicy. Return windows are a recurring trust question. When the policy is typed, an assistant can confirm "free 30-day returns" rather than hedging.

FAQPage is real but it answers one shape of question - the direct ask that mirrors your written FAQ. FAQPage is genuinely useful for surface prompts like "do you ship to France", so pair it with Offer and ShippingDetails. This layered approach covers both the quick factual ask and the deeper comparison ask in a single crawl of your page. HowTo has narrower value on ecommerce product pages and belongs only where a setup step is a genuine part of the buying decision.

Shipping bare schema can leave you with type markup that an assistant sees as decorative. Here is where to start:

1. Run URL-specific inspection, like the free scan at geovisora.com/audit, to learn which fields an assistant already reads and which product facts are missing from the markup. 2. Fix the core Product + Offer first, matching title, price, and availability to the on-page text so the two cannot contradict each other. 3. Add ShippingDetails with per-region rates and windows, then MerchantReturnPolicy with return timing and restocking caveats. 4. Add FAQPage only around queries your category actually receives, and keep the answers visible in body copy, not just inside script tags. 5. Re-scan after each edit to confirm the fields now resolve, then watch referral references over a week.

• Schema and page text disagree. If markup says in stock but the copy says backorder, retrieval treats the record as untrustworthy and drops it.
• Only one-off type. A Product node with no Offer, or a rating with no Product, reads as incomplete; assistants need the object chain to build a full answer.
• Stuffed FAQPage. A dozen identical questions across pages is duplication. Keep FAQPage to real questions with real, distinct answers.

Consider the three most common prompts and the types that satisfy each: "Is this in stock?" is answered by Offer.availability; "What does shipping cost?" by ShippingDetails; "Can I trust this store?" by AggregateRating, Review, and MerchantReturnPolicy together. When all three resolve, an assistant can answer the buying conversation end to end without leaving the page, which is exactly the condition for being cited.

_Do I need every JSON-LD type?_ No. Start with Product + Offer and add ShippingDetails, then MerchantReturnPolicy, and only add FAQPage where real questions exist. Coverage matters more than type count.

_Will schema alone get me cited?_ No. Schema makes facts legible, but assistants still weigh visible prose, review velocity, and freshness. Treat schema as the readable frame around honest, current content.

_Does schema hurt my SEO if misconfigured?_ Invalid or contradictory markup can be ignored or flagged and waste crawl budget. Use a machine validator and keep markup in sync with page copy.

Typed facts are the cleanest way to become an assistant's reference, but knowing which of a dozen schema types actually moves citations saves real time. No merchant should trial-and-error every node. The scorecard within a free scan at geovisora.com/audit lists which JSON-LD fields on your product URLs currently resolve and which are empty or contradictory, so you can prioritize the types above in the order that closes your real gaps.