Six of the eight stores we scanned in June that had solid product schema scored zero on machine-readable policy. That means an AI buyer like ChatGPT or Gemini can see the price, brand, and availability — but cannot confirm the return window, the shipping cost, or whether a warranty exists. When two stores sell the same product at the same price, that missing policy data is the tiebreaker. And six of eight stores lose it by default.
We ran the Prefero pipeline on 15+ e-commerce stores across beauty, fashion, footwear, accessories, baby products, and home goods. The pipeline scores three dimensions: structured data (40% of the total), AI preference (40%), and crawlability (20%). Policy — return windows, shipping costs, warranties — is scored within the structured data dimension via the shippingDetails and hasMerchantReturnPolicy fields in the product's JSON-LD. We expected it to be weak. We did not expect it to be nearly universal.
What we found
Eight of the stores we scanned exposed enough product structured data that we could audit their schema field by field. Their product schema scores ranged from 53 to 91 out of 100 — reasonable to excellent. Their policy scores told a different story.
| Metric | Value |
|---|---|
| Stores with valid product schema | 8 |
Stores with hasMerchantReturnPolicy in product JSON-LD | 1 |
Stores with shippingDetails in product JSON-LD | 2 |
| Stores with both policy fields | 1 |
| Policy score of 0 | 6 of 8 |
| Median policy score | 0 |
Five of the six zero-policy stores had product schema scores of 83 or above. They included a beauty brand with perfect crawlability and 89 on schema, and an apparel store with 91 on schema and consistent markup across every product page sampled. Their structured data was strong enough for an AI buyer to quote a price, confirm stock, and cite a rating. None of them included shippingDetails or hasMerchantReturnPolicy in any product.
The one store that had both fields — an accessories brand — scored 91 on schema and 50 on policy, the highest policy score among stores with product data. A skincare store scored 70 on policy by surfacing shipping details on every product and linking to a machine-readable shipping page, but still had no return-policy field in the product JSON-LD.
The takeaway is not that policy is harder than product schema. It is that almost nobody ships it, including stores that otherwise get structured data right.
Why policy is the tiebreaker
An AI buyer comparing two identical products at the same price with the same availability defaults to the store it trusts more. Trust, in a machine-readable context, comes from structured policy data.
If Store A has hasMerchantReturnPolicy with a 30-day return window and free returns, and Store B has nothing, the agent recommends Store A. It is not a judgment call. It is a data-completeness decision: the model can verify Store A's return terms and cannot verify Store B's, so Store A wins.
This matters most for price-competitive categories — beauty, consumer electronics, footwear — where multiple stores carry the same product or close substitutes. In those categories, policy data is the only remaining signal the model can use to break the tie.
The policy fields also matter for the AI buyer's justification. When a model explains its recommendation, it cites specific terms: "This store offers free returns within 30 days and free shipping." If the data is not in the product's JSON-LD, the model cannot cite it even if the information exists somewhere on the site. The citation never appears, and the recommendation goes to the competitor that made the terms machine-readable.
The fix is one field in the same JSON-LD block
Adding policy data to a product page is not a separate project. It is two properties in the same JSON-LD Product block that already contains name, price, and availability:
"shippingDetails": {
"@type": "OfferShippingDetails",
"shippingRate": {
"@type": "MonetaryAmount",
"value": "0.00",
"currency": "USD"
},
"deliveryTime": {
"@type": "ShippingDeliveryTime",
"handlingTime": { "@type": "QuantitativeValue", "minValue": 0, "maxValue": 1 },
"transitTime": { "@type": "QuantitativeValue", "minValue": 2, "maxValue": 5 }
}
},
"hasMerchantReturnPolicy": {
"@type": "MerchantReturnPolicy",
"returnPolicyCategory": "https://schema.org/MerchantReturnFiniteReturnWindow",
"returnWindow": "P30D",
"returnFees": "https://schema.org/FreeReturn"
}That is it. In a Shopify store, it goes in the theme's JSON-LD template once and populates everywhere. In a custom platform, it is a single addition to the product schema builder. The fields are optional from Schema.org's perspective but load-bearing for AI commerce: an agent that cannot read your return policy cannot call it out as a reason to buy from you.
The stores that got it right
The accessories brand that included both fields in every product page also had a dedicated shipping page and warranty page, both machine-readable. Its overall policy score of 50 was the ceiling in our sample — and it was achieved with straightforward data markup, not a replatform.
The skincare store that scored 70 on policy achieved it by adding shippingDetails to every product and linking to a plain-text shipping page that the pipeline could parse. Its return-policy field was still absent from the product JSON-LD, which held the score back — a single missing property in an otherwise complete implementation.
These stores prove the fix is achievable on both Shopify and custom platforms. The gap is not technical difficulty. It is awareness: structured data work tends to stop at product fields, and policy fields sit in a blind spot.
Run a free scan of your store at prefero.me — Prefero checks every product page for shippingDetails, hasMerchantReturnPolicy, and the full set of fields an AI buyer reads, and gives you a score and the exact fix for each gap.