Why Return Policies Matter to AI Shopping Engines
When someone asks ChatGPT or Perplexity "which online store has the best return policy for trainers?" they are not just browsing. They are making a purchasing decision, and they are trusting the AI to surface the most reliable, shopper-friendly options. If your return policy is buried in a footer page with no structured data attached to it, the AI has no reliable way to read it, understand it, or recommend you on the basis of it.
That is the gap MerchantReturnPolicy schema is designed to close. It is a structured data type from Schema.org that allows you to describe your return policy in a machine-readable format, directly attached to your product or organisation markup. AI search engines can then parse it, trust it, and use it when answering questions about shopping.
Trust is increasingly the currency of AI shopping recommendations. It is not enough to have a great return policy. The AI has to be able to read it, verify it, and present it confidently. Schema markup is how you make that happen.
What MerchantReturnPolicy Schema Actually Contains
The MerchantReturnPolicy type sits within the Schema.org vocabulary and is typically nested inside a Product or Offer entity. It tells AI engines and search systems the specific conditions under which your products can be returned.
Here are the key properties you should be using:
- applicableCountry - the country or countries your policy applies to, expressed as an ISO 3166 country code (e.g. "GB" for the United Kingdom).
- returnPolicyCategory - a standardised value from Schema.org's enumeration, such as
MerchantReturnFiniteReturnWindow,MerchantReturnUnlimitedWindow, orMerchantReturnNotPermitted. - merchantReturnDays - the number of days within which a return must be initiated. A value of 30 means 30 days from delivery.
- returnMethod - how returns are made, such as
ReturnByMailorReturnInStore. - returnFees - who pays for the return. Options include
FreeReturn,ReturnFeesCustomerResponsibility, andReturnShippingFees. - refundType - whether the customer gets a
FullRefund,ExchangeRefund, orStoreCreditRefund. - returnPolicyUrl - a direct URL to your full return policy page. Always include this.
Each of these properties helps an AI understand your policy with precision. When Perplexity is asked "does this store offer free returns?", it can look at your returnFees value and give a direct, confident answer. Without the schema, it is guessing from unstructured text, and it may get it wrong or skip you entirely.
A Working JSON-LD Example
Here is a practical JSON-LD implementation for a UK e-commerce store offering 30-day free returns by post, with a full refund:
{
"@context": "https://schema.org/",
"@type": "Product",
"name": "Classic Leather Wallet",
"offers": {
"@type": "Offer",
"price": "49.99",
"priceCurrency": "GBP",
"hasMerchantReturnPolicy": {
"@type": "MerchantReturnPolicy",
"applicableCountry": "GB",
"returnPolicyCategory": "MerchantReturnFiniteReturnWindow",
"merchantReturnDays": 30,
"returnMethod": "ReturnByMail",
"returnFees": "FreeReturn",
"refundType": "FullRefund",
"returnPolicyUrl": "https://yourstore.com/returns"
}
}
}This block tells any AI or structured data parser exactly what your policy is, in a standardised, unambiguous format. It takes less than five minutes to implement once you know the properties. The harder part is deciding what your policy actually says and making sure the schema reflects it accurately.
One important note: do not misrepresent your policy in schema. If you say FreeReturn but your checkout flow charges a return shipping fee, that is a trust violation. AI engines cross-reference signals, and inconsistencies can damage your credibility in ways that are hard to reverse.
Where to Place MerchantReturnPolicy in Your Markup
There are three main places to implement this schema, and the right choice depends on your site architecture.
On individual product pages
The most granular approach. Attach the hasMerchantReturnPolicy property directly to each Product or Offer entity on product detail pages. This is ideal if different products have different return conditions, for example, if sale items are non-refundable but full-price items have 30-day returns.
On a sitewide Organisation entity
If your return policy is uniform across your entire catalogue, you can attach MerchantReturnPolicy to your Organization schema in your global site-wide JSON-LD. This avoids repetition and keeps your implementation lean. AI engines can then associate the policy with your brand as a whole, rather than with individual products.
In a dedicated returns page schema
Some stores maintain a standalone returns page. Marking this up with WebPage schema and embedding a MerchantReturnPolicy entity there is a valid approach. It is less directly connected to product data, but it still gives AI crawlers something structured to read when they visit that URL.
For most Shopify and WordPress stores, the product page approach combined with a sitewide Organization entity is the most effective combination. The automations and implementation work at FlinnSchema often covers both in a single pass.
How AI Engines Use This Data in Practice
It helps to understand what actually happens on the AI side when this schema is in place.
Large language models like those powering ChatGPT Shopping, Perplexity, and Google's AI Overviews are trained on web crawl data and supplemented by real-time retrieval. When they retrieve a product page to answer a shopping query, they parse the structured data first. It is faster, more reliable, and less ambiguous than trying to extract policy information from prose.
When your MerchantReturnPolicy schema is clean and complete, the AI can make statements like: "Store X offers free 30-day returns by post with a full refund for UK customers." That kind of specificity builds shopper confidence and increases the likelihood of a click or recommendation.
Compare that to a store without schema, where the AI has to infer policy details from a paragraph of text that might say something like "we aim to process returns within a reasonable time frame." Vague language gets vague AI responses, or no response at all.
There is also a competitive dimension. If you and a competitor sell identical products at the same price, but your structured data clearly signals free returns and theirs does not, AI systems will present your store as the lower-risk choice. That is a meaningful advantage in a crowded market.
For a broader picture of how structured data signals influence AI recommendations, take a look at our post on using AggregateRating schema to influence AI recommendations. Trust signals work together, and return policy is one piece of a larger picture.
Common Mistakes to Avoid
Getting the schema in place is only half the battle. Here are the errors that trip up most implementations.
Using incorrect enumeration values
Schema.org has specific enumeration values for properties like returnPolicyCategory and returnFees. Writing "Free Returns" instead of "FreeReturn" will not validate. Always check the Schema.org documentation for the exact string values. A single typo means the property is ignored.
Leaving out returnPolicyUrl
This is the most common omission, and it matters more than people realise. AI engines use the returnPolicyUrl to cross-reference the schema against the actual policy text. If you do not include it, you lose that verification signal. It also gives the AI somewhere to point users who want more detail.
Schema that contradicts the page content
If your schema says 30-day returns but the text on your returns page says 14 days, AI systems may flag the inconsistency or simply ignore the structured data. Consistency between schema and visible content is not optional. It is the foundation of the whole system working.
Forgetting to update schema when policies change
Return policies change. Seasonal promotions, new carrier arrangements, regulatory updates in different markets. When your policy changes, your schema must change too. If you are not sure how frequently to revisit your markup, our post on how often you should update your schema markup covers this in detail.
MerchantReturnPolicy as Part of a Broader AI Trust Stack
MerchantReturnPolicy schema does not work in isolation. AI shopping engines are building a picture of your brand from multiple signals: your reviews, your product data, your brand entity, your contact information, and yes, your return policy. Each piece reinforces the others.
A store with strong AggregateRating schema, a clean Organization entity, verified contact details via ContactPoint schema, and a well-structured MerchantReturnPolicy is presenting a complete, trustworthy picture to the AI. A store with only one of these things is giving the AI an incomplete signal and hoping it fills in the gaps favourably.
The brands that are winning in AI shopping search are the ones treating structured data as an ongoing investment, not a one-time technical task. If you want to understand where your current setup stands, an AI visibility audit is a practical first step. It will show you which signals are present, which are missing, and where the biggest gaps are relative to competitors.
At FlinnSchema, we work with e-commerce brands specifically on this kind of trust infrastructure. The combination of return policy schema, product schema, and brand entity work consistently drives better AI citation rates than any single element on its own.
Validating Your Implementation
Once you have added your MerchantReturnPolicy JSON-LD, you need to verify it is working correctly. Use Google's Rich Results Test at search.google.com/test/rich-results to check for errors and warnings. Schema.org's validator at validator.schema.org is also useful for catching property-level issues.
Run the test on your product pages, not just your homepage. If you have implemented the schema sitewide via a theme or plugin, spot-check five to ten individual product URLs to confirm the structured data is rendering correctly on each one.
Look for any returnPolicyCategory errors in particular. This property uses a strict enumeration and is the one most likely to throw a validation warning if the value is not exactly right.
After validation, give it two to four weeks before assessing whether AI search visibility has improved. These systems crawl and re-index at their own pace. Patience matters here.
Frequently Asked Questions
Does MerchantReturnPolicy schema affect Google Shopping as well as AI search?
Yes. Google uses MerchantReturnPolicy structured data in its Shopping tab to display return information directly in product listings. So implementing it well benefits both traditional Google Shopping results and AI-driven search features like AI Overviews and Gemini-powered recommendations. It is one of the rare schema types that earns returns across multiple search surfaces.
Can I use MerchantReturnPolicy schema on Shopify?
Yes, though Shopify's default theme does not generate this schema automatically. You will need to edit your product schema template in your theme's Liquid files, or use a structured data app to inject the JSON-LD. If you are on a custom or heavily modified theme, injecting it via a script block in the product template is the most reliable approach. FlinnSchema's implementation work covers this for Shopify stores directly.
What if I have different return policies for different product categories?
You can specify multiple MerchantReturnPolicy entities, each with different conditions, and attach them to the relevant product groups or individual Offer entities. The applicableCountry and returnPolicyCategory properties allow for granular differentiation. This is more complex to implement but accurately reflects real-world policy variations, which is what matters most for AI trust signals.
Will AI search engines definitely read my MerchantReturnPolicy schema?
There is no guarantee that any particular AI engine will surface any particular piece of structured data in any given response. What schema does is make it possible and easy for them to do so. Without it, the AI has to work much harder to extract the same information from unstructured text, and it will often fail or skip you in favour of a competitor with cleaner data. Think of it as removing barriers rather than guaranteeing outcomes.