Details regarding shipping and returns can change a buying decision as fast as price. In 2026, that information also needs to make sense to machines, not only shoppers.
That’s where return policy schema comes in. Your store needs clear on-page policy content for people, plus structured data that repeats the same facts for search engines, with MerchantReturnPolicy as the specific type required. Once those two versions drift apart, trouble starts.
Properly implemented structured data is the key to winning rich results in 2026 search engines.
Key Takeaways
- Match markup to your page: MerchantReturnPolicy structured data must repeat the exact return rules from your human-readable policy page, or it risks warnings and lost rich results.
- Start store-wide: Use
hasMerchantReturnPolicyon your Organization or OnlineStore schema for the default policy, adding offer-level overrides only for true exceptions like shorter windows or no-returns. - Prioritize key properties: Focus on
applicableCountry,returnPolicyCategory,merchantReturnDays,returnMethod,returnFees,refundType, anditemCondition—always use Schema.org URLs, not plain text. - Validate relentlessly: Treat schema like a mirror of your policy; check for duplicates, mismatches, and invalid enums after every update using Google’s tools and Search Console.
What return policy schema does, and what it doesn’t
Google documents MerchantReturnPolicy structured data as a way to help Search understand a merchant’s return rules. The Schema.org definition for MerchantReturnPolicy shows the underlying type and supported properties.
That sounds simple, but one point matters most: markup does not replace policy content. Shoppers still need a readable return page with the actual terms, fees, exceptions, and return windows. The merchantReturnLink property should point directly to this human-friendly content. The JSON-LD only describes that content in a machine-friendly format.
If the page says a 60-day return window and the markup says 30, the page wins, and the markup becomes a liability.
In practice, think of this as two layers. First, your visible return policy explains the rules. Second, your structured data in JSON-LD repeats the same rules with standard property names and values. Search engines read the second layer faster, but they still compare it to the first.
That’s why this markup belongs in the same maintenance bucket as product, offer, and FAQ schema. If you need a broader refresher on how those pieces fit together, this ecommerce schema markup guide is a helpful companion.
Schema details can also change over time. Google may adjust eligibility rules, while Schema.org may expand or refine terms. Because of that, use current documentation when you update templates, apps, or feed logic.
A practical JSON-LD setup for 2026
For most stores, a store-wide policy is the right starting point. Put that on your Organization schema or OnlineStore entity, then add narrower rules only when a product truly has an exception.
{
"@context": "https://schema.org",
"@type": "OnlineStore",
"name": "North Peak",
"url": "https://www.example.com",
"hasMerchantReturnPolicy": {
"@type": "MerchantReturnPolicy",
"applicableCountry": "US",
"returnPolicyCategory": "https://schema.org/MerchantReturnFiniteReturnWindow",
"merchantReturnDays": 30,
"returnMethod": "https://schema.org/ReturnByMail",
"returnFees": "https://schema.org/FreeReturn",
"refundType": "https://schema.org/FullRefund",
"itemCondition": "https://schema.org/NewCondition"
}
}
That example is short, but it covers the fields most merchants care about, with hasMerchantReturnPolicy as the connector property.
The properties that matter most
Here’s the quick translation from schema language to plain English.
| Property | What it tells search engines | Common mistake |
|---|---|---|
applicableCountry | Where the policy applies | Marking up countries not listed on the page |
returnPolicyCategory | Whether returns are allowed and what kind of window exists | Adding days but no category |
merchantReturnDays | The return window length | Using a number that doesn’t match the policy page |
returnMethod | How the item comes back, such as by mail or in store | Listing methods you don’t offer |
returnFees | Who pays return costs | Saying free returns when only some items qualify; overlooking restockingFee |
refundType | What the customer gets back | Marking full refund when you give store credit |
itemCondition | The item state required for returns | Ignoring worn, opened, or final-sale exclusions |
For stores that charge flat rates for return labels, use returnShippingFeesAmount with the MonetaryAmount type to specify the exact amount.
Most errors happen because stores treat these as “extra” fields. They aren’t. They describe the real policy.
When to use offer-level overrides
Sometimes one product line has a shorter window or a no-return rule, including seasonal overrides for holiday-specific return window changes. In that case, add an Offer structured data override instead of changing the whole store policy.
"offers": {
"@type": "Offer",
"price": "79.00",
"priceCurrency": "USD",
"hasMerchantReturnPolicy": {
"@type": "MerchantReturnPolicy",
"returnPolicyCategory": "https://schema.org/MerchantReturnFiniteReturnWindow",
"merchantReturnDays": 14
}
}
Keep those exceptions visible on the page. Hidden policy differences are where validation passes but trust fails.
Frequently Asked Questions
What is MerchantReturnPolicy schema?
MerchantReturnPolicy is a Schema.org type that lets search engines understand your store’s return rules in structured data format. It covers details like return windows, fees, methods, and refunds using standard properties. Always pair it with a clear, human-readable policy page linked via merchantReturnLink.
Where should I add return policy markup?
Add it store-wide on your OnlineStore or Organization schema for the default policy. For product exceptions, override it on individual Offer entities. Keep visible policy content updated first, then generate JSON-LD from the same source.
What are the most common markup mistakes?
The top issues are mismatches between page content and JSON-LD, duplicate schema from apps/plugins, and invalid values like plain text instead of Schema.org URLs. Overlooking properties like restockingFee or marking free returns when they don’t apply universally also triggers warnings. Use one source of truth and validate with Google’s tools.
How do I handle return policy exceptions?
Use offer-level hasMerchantReturnPolicy for shorter windows, no-returns, or seasonal changes on specific products. Ensure these differences appear on the product page too. Avoid store-wide changes for rare cases—keep the default policy broad and exceptions targeted.
How can I validate my return policy schema?
Publish the policy page first, then test JSON-LD with Google’s Rich Results Test and Search Console. Monitor Merchant Center for feed errors and recrawl after changes. Watch for editorial drifts from theme settings or apps that cause outdated markup.
Validation mistakes that cause warnings and missed features
The biggest mistake is not technical. It’s editorial. Teams update the return page, but the JSON-LD still pulls old values from a theme setting, app, or hard-coded snippet. That gap creates mixed signals.
Another common issue is duplicate schema. Shopify apps, WooCommerce plugins, and custom snippets often output overlapping data. One block says free returns, another says paid returns, and search engines get a mess. Pick one source of truth.
A few checks catch most problems:
- Publish the visible policy first, with days, fees, methods, refund terms, and exclusions.
- Generate JSON-LD from the same source that powers that page.
- Test for rich results using Google’s testing tools.
- Review Search Console and Merchant Center after recrawling, especially after theme or app changes.
If you also manage feed-based listings, monitor Search Console and Merchant Center as they track product listing errors tied to return policies. This Merchant Center return policy guide gives useful context on how policy settings can affect product data outside organic search.
Watch out for invalid enum values, too. Merchants should define returnLabelSource and specify the return shipping label policy clearly. Properties like returnMethod, returnFees, and refundType often need Schema.org URLs, not plain text like “free” or “mail return.” Use customerRemorseReturnFees and itemDefectReturnFees to differentiate customer remorse from defects and avoid validation warnings. That small format mistake can trigger avoidable warnings.
Return policy schema works best when it acts like a mirror. Your page tells shoppers what to expect, and the markup repeats the same facts in a format machines can parse.
In 2026, that mirror needs to stay clean. If your store keeps one source of truth, validates after every major change, and marks up only what users can see, your return policy schema will stay useful instead of fragile.
