Someone asks ChatGPT for a cordless drill under $150 with free returns. Your Product and Offer markup is clean: price right, availability current, brand field populated correctly. But there’s no MerchantReturnPolicy block anywhere in the code, and AggregateRating is empty. The model skips you. It doesn’t say why.
That silence is the problem. Auditing MerchantReturnPolicy and AggregateRating schema used to be a box you checked after the real work was done. Now it decides whether you show up in a shopping agent’s answer or vanish from it with nothing in any log to explain the drop.
Key Takeaways
- AI shopping agents need to answer “can this be returned” and “is this trusted” before they will recommend a product, and they answer both from structured fields, not prose.
- Missing or incomplete MerchantReturnPolicy and AggregateRating markup does not trigger a visible penalty. The listing is simply absent from the comparison set the model builds.
- Product, Offer, MerchantReturnPolicy and AggregateRating data must agree with each other and with the visible page. Disagreement between them reads as a trust failure, not a technical glitch.
Why AI Shopping Agents Read Deeper Than Google Ever Did
Google tolerated gaps. No return policy snippet just meant no snippet, and the page still ranked on relevance and backlinks. A shopping agent doesn’t work that way. It’s trying to answer a question with several conditions stacked on top of each other: price, availability, return terms, whether anyone else actually trusts the thing. Miss a structured source for any one of those, and the agent can’t include your listing with confidence. It just won’t.
Search ranked pages. Shopping agents build shortlists. That distinction is smaller than it sounds and bigger than most teams treat it. A shortlist only holds items the model can verify end to end, and a page with three warm paragraphs about its 30-day return window but zero MerchantReturnPolicy schema is, as far as the model’s concerned, a page where that return window doesn’t exist.
What MerchantReturnPolicy Actually Tells the Model
It’s not one checkbox. It’s a cluster of properties: returnPolicyCategory, merchantReturnDays, returnFees, returnMethod, applicableCountry. Each answers a question a shopper (or an agent acting on one) is going to ask directly. How many days do I have? Who pays for the box back? Does this even apply if I’m ordering from outside the country of sale?
Leave those fields blank and the model has no way to answer a return question, even if a human skimming the page would find it in two seconds flat. This is retrieval presence, the technical half of AEO, and it’s earned field by field. Training-data presence builds slowly, over months, through broad coverage. Retrieval presence lives or dies on whether one schema property is present, accurate, and machine-readable right now, today.
growth in AI brand presence for NewDay USA, tracked weekly across five engines over six months, built on structured content alongside PR and trust signal work.See the case study
AggregateRating Isn’t Decoration
AggregateRating carries ratingValue, ratingCount, often reviewCount too. Shopping agents treat it as the quickest available signal of whether buyers actually trust the product. Why does it carry that weight? Because at the AI layer, trust isn’t a single score sitting on your page. It’s agreement across independent sources, and AggregateRating is one node feeding that graph.
A retailer page, a review aggregator, and a manufacturer site that all report roughly the same rating reinforce each other. A page reporting nothing contributes nothing. An agent weighing five listings will pick the four it can check against something else.
A missing field does not lower your rank. It removes you from the set the model is choosing between.
Here’s where most teams shoot themselves in the foot. They publish 2,200 customer reviews on the page, averaging 4.6 stars, and never touch the AggregateRating markup. So the schema says nothing, or it says something from fourteen months ago. An agent cross-checking the visible page against the schema finds two different answers and trusts neither.
The Product and Offer Fields Everyone Gets Half Right
Product and Offer schema get implemented first and audited last, because at a glance they look finished. Name, image, price, currency: present, almost always. What’s missing is the layer agents use to filter, not just display. priceValidUntil. itemCondition. Availability granularity, meaning the gap between InStock, LimitedAvailability, and PreOrder. Whether the Offer actually nests under the correct Product variant when a listing ships in six sizes and four colors.
None of these fields do anything alone. An agent checking a “ships today” filter needs availability, priceValidUntil, and usually shippingDetails to line up with each other and with MerchantReturnPolicy’s returnMethod. Offer says InStock but shippingDetails is blank? Now the agent has a logistics question it can’t answer. It drops you. It doesn’t guess on your behalf.
Where Incomplete Schema Quietly Kills a Listing
No rejection message. No crawl error. Nothing in Search Console pointing at the problem. The listing just never shows up in the agent’s answer, and there’s no entry anywhere explaining why not. That’s the operational nightmare of secondary shopping schema: it fails silently, and you won’t notice until a competitor runs the audit you should have run first.
Think of it as a two-pass checklist the agent runs before anything makes the shortlist. Price and availability clear pass one. Return terms and rating data clear pass two. Fail pass two and you’re out, no matter how airtight your Product and Offer markup is.
Listings that clear both passes consistently get cited more over time, because once a model finds a source it can verify repeatedly, it keeps coming back to it. Listings that fail pass two never get that chance. They don’t even enter the loop.
What To Do Next
Run a field-level audit, not a page-level one. Pull every Product, Offer, MerchantReturnPolicy, and AggregateRating property live on your top-traffic listings. Check three things for each: is it there, is it current, does it match what a buyer actually reads on the page. A mismatch between schema and visible copy does more damage than an absent field, because it reads as inconsistency, not just incompleteness.
Then rank by category risk. Electronics, apparel sizing, anything perishable: these have variable return terms, so MerchantReturnPolicy accuracy matters more here, sooner. Crowded categories full of near-identical alternatives need AggregateRating accuracy just as urgently, since rating data is often the only thing separating two otherwise equal listings in an agent’s eyes.
Fix the worst gaps first. Then build a recurring audit into the calendar, because return policies and review counts shift on their own schedule, one your schema won’t match unless someone forces it to.
FAQs
Does MerchantReturnPolicy schema need to match the text on the return policy page exactly?
It needs to agree with it, not repeat it word for word. If the schema says 30 days and the policy page says 45, an agent cross-referencing the two will treat the listing as unverified rather than picking one figure to trust.
Can a product rank well in traditional search but still be excluded from AI shopping answers?
Yes, and this is increasingly common. Traditional ranking weighs relevance and links. Shopping agents filter on structured fields like return terms and rating data before relevance is even considered, so a page can rank well and still fail to clear the agent’s shortlist.
How often should AggregateRating data be refreshed in schema?
Whenever the underlying review count changes meaningfully, ideally through an automated feed rather than a manual update. Stale rating data that no longer matches visible reviews is often treated as worse than having no rating markup at all.
Is this the same work as a standard structured data audit?
It overlaps but goes further. A standard audit checks for valid syntax and required fields. An AEO-focused audit checks whether the fields an AI shopping agent specifically needs to answer return and trust questions are present, current, and consistent with the rest of the page.
