I run AEO strategy across a fifty-state site portfolio. The pattern I see most often in ecommerce audits is a product page that ranks fine in traditional search but gets completely ignored when someone asks Google AI Overviews or ChatGPT for a product recommendation. The page has a title, a price, some photos. But it has no schema, no question-formatted content, no aggregateRating markup, and an inventory field that reads 'call for availability.' That page is invisible to AI engines, full stop.
AI shopping answers are no longer a future concern. Google AI Overviews now appear on the majority of 'best of' product queries and reach over a billion users monthly. ChatGPT's shopping feature, now live in multiple markets, pulls product data from a combination of Google's Shopping Graph and schema markup on individual product pages. If your data is not in that graph, and if your pages do not answer the questions AI engines are trying to surface, a competitor who has done the work will be cited instead of you.
This post walks through exactly what I implement on ecommerce clients: the Product schema fields that matter, the content structure for PDPs and category pages, the review markup rules, and the honest limitation you need to understand before you set expectations. I am not going to tell you AEO alone conquers Amazon. I will tell you what is in your control and how to execute it correctly.
Why Do AI Shopping Answers Cite Some Retailers and Not Others?
AI engines cite retailers whose product data is complete, structured, and verifiable. Google's Shopping Graph contains over 50 billion product listings that update two billion entries every hour. If your schema is missing price, availability, or a product identifier, the AI has no reliable data to surface. Completeness and accuracy are the entry criteria.
At Search Central Live NYC in early 2025, Google's Ryan Levering confirmed that structured data makes their systems more efficient by reducing the need to infer meaning from unstructured pages. The practical consequence: a page where the price exists only as unstructured text inside a JavaScript render is a page the Shopping Graph may never confidently index. A page where price, availability, brand, and GTIN are all declared in JSON-LD structured data gives the system nothing to guess. It cites accordingly.
ChatGPT's shopping recommendations operate on a similar principle. According to industry analysis, approximately 83% of the product data feeding ChatGPT shopping answers comes from the Google Merchant Center feed; the remaining signal comes from schema markup directly on product pages. That split means a retailer with a well-maintained Merchant Center feed and clean on-page Product schema has two reinforcing data pipelines feeding the AI. A retailer relying on organic HTML alone has neither.
The selection mechanism also penalizes data inconsistency. If your schema says a product is in stock but your Merchant Center feed shows it as discontinued, Google's verification layer flags the conflict and may deprioritize the listing entirely. AI engines are pattern-matching on trustworthiness signals, and internal contradictions are a hard negative. Every retailer I audit has at least one category where this exact mismatch is killing citation eligibility.
Which Product Schema Fields Do AI Engines Actually Surface?
The fields AI engines rely on most are: name, image, offers (with price, priceCurrency, availability, and priceValidUntil), brand, gtin, aggregateRating, and description. These are the attributes Google's merchant listing guidelines define as required or strongly recommended. Anything missing reduces your eligibility for AI-generated product results.
Google's merchant listing structured data documentation specifies three required properties for Product markup: name, image, and offers. But required means minimum eligibility, not citation readiness. For AI Overviews specifically, completeness of the Offer object matters most. That means price (numeric, no currency symbols), priceCurrency (ISO 4217 code like USD), availability using the schema.org/InStock URI, and a priceValidUntil date so the AI knows the data is current. A price with no expiry date is a stale signal by definition.
GTIN is the field most retailers skip and it costs them the most. The global trade item number is the primary key Google's Shopping Graph uses to match your product listing against the canonical product record in its database. When you provide a valid GTIN, your listing gets cross-referenced against manufacturer data, price history, and consumer reviews from across the web. When you omit it, your product is an orphan record with no corroboration. For branded products, GTIN is non-negotiable. For private-label products, MPN combined with brand.name is the fallback.
AggregateRating markup deserves its own attention. The schema.org AggregateRating type requires ratingValue, reviewCount, and bestRating. When this is present and the underlying reviews are real and verifiable, AI engines surface it directly in product answer cards. When it is absent, the AI either borrows review data from a third-party aggregator (which may not favor you) or omits rating signals entirely from its citation. A product page with 200 verified reviews and no aggregateRating schema is wasting its strongest trust signal.
How Should Product Detail Pages Be Structured to Capture AI Citations?
PDPs should lead every product with a question-formatted H2 that mirrors how a shopper would ask about it, followed by a 40-60 word answer. Questions like 'How much does [Product] cost?', 'Is [Product] worth it?', and 'What sizes does [Product] come in?' signal to AI engines that this page is the authoritative answer source, not just a transaction endpoint.
The structural logic here is the same as any answer-engine optimization: AI engines are retrieving answers, not pages. A PDP that opens with a product title, a price, and a photo is structured for a human browsing session. A PDP that opens with a question H2 and a direct answer is structured for an AI retrieval event. These are not mutually exclusive. You can have a conversion-optimized page layout and answer-engine-readable content in the same HTML if you plan it correctly.
In practice this means adding a section below the primary product description with two to four question H2s that target the queries shoppers actually type before they buy. 'How much does [Product Name] cost?' with a one-paragraph answer that states the price, explains the pricing tier if applicable, and notes current availability. 'Is [Product Name] worth it?' with a paragraph that summarizes the strongest verified use case and references your aggregateRating. 'How does [Product Name] compare to [Top Competitor Product]?' with a factual comparison that does not fabricate specifications.
The 40-60 word lead answer format matters because AI engines are looking for extractable passages. I track this across our portfolio: pages with a direct answer in the first two sentences of a section get cited at a significantly higher rate than pages where the relevant information is buried in paragraph four of a 600-word product description. Structure is the mechanism. You are not writing for Google's crawler; you are writing for an AI system that is evaluating whether your text is the most direct answer to the user's question.
What Should Product FAQ Sections Cover to Win Comparison and Buying-Intent Queries?
Product FAQ sections on PDPs should target the three highest-volume comparison and buying-intent queries for that specific product: a direct versus competitor comparison, a 'who is this for?' question, and a warranty or return question. These are the queries where AI engines need a sourced answer and where marketplace giants are often too generic to compete.
FAQ sections marked up with FAQPage schema give AI engines a pre-formatted question-and-answer pair to extract directly. The schema.org FAQPage type tells the AI: these are questions, these are the answers, and this page is asserting ownership of both. Without the markup, your FAQ is just prose. With it, the AI can surface your exact answer text when a user asks the matching question. The match does not need to be verbatim; semantic proximity is sufficient. But your answer needs to be specific and factual, not marketing copy.
The comparison question is where I see the most unrealized opportunity. A shopper searching 'Product A vs Product B' is at the bottom of the funnel. If your PDP for Product A has a FAQ entry that honestly addresses how it compares to Product B on the dimensions that matter most to buyers, you are the page that answers that question. Most retailers avoid this because they fear drawing attention to competitors. That avoidance is a mistake. AI engines will answer the comparison question regardless; the only question is whether your page is the source or your competitor's page is.
Buying-intent FAQs should also include at least one question about fulfillment and returns. 'When will my order ship?' and 'What is the return policy for [Product]?' are high-intent queries that AI engines surface when users are in the final decision stage. If your FAQ answers these questions with specific, accurate information — not 'ships in 3-5 business days' but 'in-stock orders ship same day if placed before 2pm EST' — you are providing the kind of verifiable, precise data that earns AI citations.
How Should Review and AggregateRating Schema Be Implemented Without Fabricating Data?
AggregateRating schema must reflect only real, collected reviews from verified purchasers. The schema requires ratingValue, reviewCount, and bestRating. Do not inflate reviewCount, do not round ratingValue upward, and do not mark up reviews that are internal or generated. Google cross-checks aggregateRating data against its own signals and will suppress listings where the rating appears manipulated.
The schema.org AggregateRating documentation defines ratingValue as a number or text using standard digit characters, reviewCount as an integer, and bestRating as the maximum value in your rating scale (typically 5). Implementation is straightforward. What is not straightforward is the ethical and practical requirement that every review you mark up must be a real review from a real customer. I specify this explicitly because I have audited ecommerce sites that were marking up internal 'editorial ratings' or test reviews as aggregateRating data. Google catches this. The listing gets suppressed, not just demoted.
The practical implementation for most ecommerce platforms is to pull the aggregateRating values dynamically from your review database and inject them into your JSON-LD Product schema at render time. This keeps ratingValue and reviewCount current without manual updates. Stale review counts are almost as damaging as fabricated ones: a page that shows 47 reviews in the schema but 112 reviews in the visible UI signals a data quality problem. AI engines and Google's verification layer both flag this kind of inconsistency.
For new product pages with fewer than five reviews, I recommend not marking up aggregateRating until you have a statistically meaningful sample. A ratingValue of 5.0 from two reviews is not a signal AI engines trust; it reads as potential manipulation. The threshold varies by category, but I generally wait for at least ten verified reviews before adding aggregateRating markup to a PDP. In the meantime, you still get full benefit from the Product, Offer, and FAQPage markup, which is sufficient for most citation eligibility purposes.
How Do Category Pages Win 'Best X for Y' AI Queries?
Category pages capture 'best X for Y' AI citations by adding an answer-block at the top that directly answers the query, followed by a comparison section with specific product attributes. Most category pages are filtered grids with no editorial content. Adding 150-200 words of answer-first content above the grid is the highest-leverage change most ecommerce sites can make.
The 'best running shoes for flat feet' or 'best stand mixer under $200' query pattern is where AI engines generate the most commercially valuable citations. When a user gets a named product recommendation from Google AI Overviews or ChatGPT, that is bottom-of-funnel intent being resolved by a source. If your category page is that source, the downstream conversion rate is significantly higher than from a standard organic click. If your category page is a paginated product grid with a page title and nothing else, it will never be that source.
The answer-first block for a category page should follow the same structure as a PDP question section: a question H2 phrased as the user would type the query, a 40-60 word lead answer that names the top recommendation with a specific reason, then two to three paragraphs that expand on the selection criteria. On a 'best X for Y' category page, the lead answer should actually name a product from your catalog. 'The best entry-level espresso machine for beginners is the [Product Name], because it automates pressure profiling without requiring manual tamping' is a citable answer. 'Browse our selection of espresso machines' is not.
FAQPage schema on category pages works the same way as on PDPs but targets the category-level questions: 'What is the best [category] for [use case]?', 'What should I look for when buying [category]?', 'How much does a good [category] cost?' Mark up three to six real question-and-answer pairs per category page. The answers must be accurate and specific to your actual product catalog. Generic buying guides that could apply to any store will not earn citations over the established editorial sites that have published the same content for years.
How Do You Keep Inventory and Pricing Data Fresh Enough for AI Engines to Trust It?
AI engines verify price and availability data against multiple sources. Stale schema is worse than no schema because it creates a detectable mismatch. You need server-side rendered JSON-LD that pulls live inventory data at page render, a priceValidUntil date on every Offer, and a synchronized Merchant Center feed refreshed at least daily for any product with volatile pricing.
Google's merchant listing guidelines are explicit: dynamically-generated Product markup from JavaScript can make Shopping crawls less frequent and less reliable, particularly for fast-changing content like availability and price. The recommendation is to put Product structured data in the initial HTML, meaning server-side rendered at request time with live data. If your platform generates Product schema as a static JSON-LD block at build time and does not update it when price or inventory changes, you will regularly have schema that contradicts your live page. Google detects this and downgrades the listing's eligibility.
The priceValidUntil field is the most commonly omitted freshness signal in ecommerce schema implementations. Without it, an AI engine looking at a price has no way to know if that price is current or from eighteen months ago. Adding a priceValidUntil date thirty or sixty days out, and refreshing it dynamically, tells the AI that someone is actively maintaining this data. It is a low-effort field that has a disproportionate impact on how AI systems evaluate your data reliability.
For retailers with large catalogs, a synchronized Google Merchant Center feed is the practical solution to freshness at scale. On-page schema and Merchant Center feed data are complementary: Google explicitly states that product snippets may use pricing data from your merchant feed if it is not present in the on-page structured data. Running both pipelines means you are covered even if a page-level render misses a price update. The feed updates every few hours for most integrations; on-page schema updates at render. Together they create a data freshness floor that AI engines treat as trustworthy.
What Are the 7 Product Schema Fields That Most Directly Drive AI Citation Eligibility?
These are the seven fields I prioritize in every ecommerce AEO audit. Some are required by Google's merchant listing guidelines; some are technically optional but functionally mandatory if you want AI citation eligibility. Missing any one of the top four disqualifies your listing from most AI-generated product answers.
- offers.price + offers.priceCurrency + offers.priceValidUntil: A numeric price, the ISO currency code, and a future expiry date on every Offer object. This is the freshness and verifiability trifecta. Without priceValidUntil, your price is undated. Without priceCurrency, your price is ambiguous. Google's verification layer checks all three.
- offers.availability using schema.org URIs: Use https://schema.org/InStock, https://schema.org/OutOfStock, or https://schema.org/PreOrder as the value — not freeform strings like 'Available' or '3 left'. AI engines do exact-match lookups on availability status. String variants that do not map to a recognized URI are treated as missing data.
- gtin (or gtin8 / gtin13 / gtin14): The global trade item number is the primary key for product matching in Google's Shopping Graph. With a valid GTIN, your listing is cross-referenced against the canonical product record and gains corroboration from all data sources tracking that product. Without it, your listing is an isolated record with no external validation.
- brand.name: A single, accurate brand name declared in the Brand object under your Product schema. This is how AI engines attribute product recommendations to a manufacturer. For private-label products, use your store's brand name. Do not submit 'Generic' or omit the field; both result in degraded citation eligibility for brand-query patterns.
- aggregateRating with ratingValue, reviewCount, and bestRating: Real, current, verified-purchaser review data marked up in schema. This signal directly influences whether AI engines treat your product as vetted by real users. Only add this markup when you have ten or more genuine reviews. Never fabricate or inflate review data.
- description: A factual, keyword-informed product description in the description field of the Product object. Not a copy of the title. Not a marketing tagline. A specific paragraph that describes what the product is, who it is for, and what distinguishes it from alternatives. AI engines use description text to match products to semantic queries that do not include the exact product name.
- image: A high-resolution image URL pointing to a stable, crawlable image file. Not a JavaScript-rendered lazy-loaded image. Not a placeholder. The image property is a required field in Google's merchant listing schema, and a low-quality or missing image is one of the most common reasons a valid Product schema listing fails to surface in AI-generated shopping results.
Sources and further reading
These are the primary sources referenced in this article. Each is an authoritative documentation page or publication we verified before citing.
- Google's merchant listing structured data documentation — Primary reference for required and recommended Product, Offer, and AggregateRating schema properties for ecommerce pages eligible for Google shopping experiences and AI Overviews.
- schema.org AggregateRating specification — Defines the ratingValue, reviewCount, and bestRating properties required to correctly implement aggregateRating markup on product pages.
- Google's product structured data overview — Explains the distinction between product snippets and merchant listings, and outlines which structured data properties unlock which AI and shopping result enhancements.
