94% of Shopify product pages don't state the return policy. AI assistants fill the gap by guessing.

I audited product data across 109 live Shopify stores. The single most common gap wasn't images, keywords, or schema markup — it was that almost nobody states their return terms on the product page itself.

94% of the catalogs I looked at had no return information at product level. 81% had none at all. Shipping was identical: 94% missing.

Every one of those stores has a refund policy. It's sitting at /policies/refund-policy, exactly where Shopify puts it. The problem is that it isn't where the question gets asked.

Why this matters more than it used to

When a shopper wanted to know your return terms, they clicked "Returns" in your footer. The policy page did its job.

Now a growing share of that question is asked somewhere else: "Can I return this if it doesn't fit?" typed into ChatGPT, Gemini, or Perplexity while comparing three stores.

The assistant fetches your product page and reads what's there. If the return terms aren't on it, the assistant doesn't respond "I don't know." It infers — from your category, from what similar stores do, from the general shape of ecommerce. Sometimes that inference is right. Sometimes it invents a 30-day window you don't offer, or misses that an item is final sale.

You never see this happen. There's no log, no error, no ticket. The first signal is a customer who's certain they were told something you never said.

Why "just run an AI tool on it" doesn't work

This is the part that surprised me, and it's the reason I'm writing it up.

I looked at 24 stores that had run automated AI enrichment over their catalogs — the kind that reads each product and fills in missing attributes. Several had run it across thousands of products.

One store ran 12,182 automated attribute fixes. Its return coverage stayed at zero.

Not because the automation was broken. Because it was honest.

These tools read the product's title, description, tags and variants, and they're instructed not to invent facts that aren't in the input. Return terms are a store-level policy. They appear in no product description. So the model correctly writes nothing, on every product, forever.

The same holds for a whole class of data. Across the 109 catalogs:

There's a clean dividing line here. Materials and use cases fill in fine — those are inferable from a good description, and the tools handle them well. Dimensions, weight, care and compatibility don't — because that information was never in the store. It's on the supplier's spec sheet.

Returns are the odd one out, and the best news in the list: unlike dimensions, you already have this data. It just isn't in the place that gets read.

The fix

Put the policy in the product page's structured data, using Schema.org's MerchantReturnPolicy. Assistants and search engines both parse it, and shoppers never see it — it lives in a JSON-LD block, not in your layout.

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Merino Wool Base Layer",
  "offers": {
    "@type": "Offer",
    "price": "89.00",
    "priceCurrency": "USD",
    "hasMerchantReturnPolicy": {
      "@type": "MerchantReturnPolicy",
      "applicableCountry": "US",
      "returnPolicyCategory": "https://schema.org/MerchantReturnFiniteReturnWindow",
      "merchantReturnDays": 30,
      "returnMethod": "https://schema.org/ReturnByMail",
      "returnFees": "https://schema.org/FreeReturn"
    }
  }
}

The shipping half uses shippingDetails with OfferShippingDetails on the same Offer.

The part most people will get wrong

Do not stamp one policy across your whole catalog.

If you emit "30 days, free returns" on every product, you've just taught every AI assistant that your final-sale, made-to-order and personalised items are returnable. A shopper asks, gets told yes, buys, and then discovers otherwise — and that lands very differently from an ordinary return. They don't feel they made a mistake; they feel they were told something untrue.

You'd have automated the exact failure you were trying to prevent.

Schema.org handles this properly. Use the right category per product:

"hasMerchantReturnPolicy": {
  "@type": "MerchantReturnPolicy",
  "applicableCountry": "US",
  "returnPolicyCategory": "https://schema.org/MerchantReturnNotPermitted"
}

MerchantReturnNotPermitted is a first-class value. There's also MerchantReturnUnlimitedWindow and MerchantReturnUnspecified if you genuinely don't have a fixed rule.

In practice: pick your default from your actual refund policy, then exclude products carrying tags or types that signal an exception — final sale, clearance, custom, made to order, perishables. Those get MerchantReturnNotPermitted. Everything else gets your standard window.

Check your own store in thirty seconds

1. Open any product page.
2. View source and search for hasMerchantReturnPolicy.
3. If it's not there, an AI assistant answering questions about that product is guessing your return policy right now.

Then try the same for shippingDetails.

One caveat on my numbers

My 109 stores are self-selected — they're stores that installed an AI-readiness tool, so they skew toward merchants already thinking about this. A random sample of Shopify stores would likely look worse, not better, but I can't prove that.

I also can't tell you this is costing anyone money. I've asked merchants directly for a real case of an AI assistant getting a policy wrong and causing a return or a dispute, and I haven't got one yet. What I can tell you is that the precondition is nearly universal: the information isn't on the page, so something has to fill the gap, and right now it's the model's best guess.

If you've seen this happen on a real order, I'd genuinely like to hear about it.

---

About the author

Rahul — Founder, FoundGPT

Rahul built FoundGPT and personally ran the audits behind this page. Across 111 Shopify stores he has run 23,000+ real AI-search checks on ChatGPT, Gemini, Google AI Mode and Perplexity, and applied ~99,000 structured-data fixes.

→ About FoundGPT