Validate MerchantReturnPolicy schema by comparing three layers in one pass: the visible return policy text, the structured data values, and the page URL that both point to. Google documents MerchantReturnPolicy as a way to describe return conditions, methods, fees and refund options, either as a site-wide policy under Organization or as a product-level override under Offer. Validation means those layers agree, not just that the code parses.
What does MerchantReturnPolicy schema actually describe?
MerchantReturnPolicy is a structured data type that lets a merchant describe how returns work. According to Google's Merchant return policy documentation, it can specify a link to your return policy page, or details such as the conditions under which customers can return a product, return methods, return fees and refund options (Google Search Central, checked 30 September 2026).
Two placement patterns matter for validation:
- Site-wide policy. A standard policy that applies to most or all products is nested under Organization using the hasMerchantReturnPolicy property.
- Product-level override. If a specific product needs different terms, one or more MerchantReturnPolicy instances are placed under the Offer type. Google notes that product-level policies under Offer support a more limited set of properties than organization-level return policies.
That distinction is the first validation question. A mismatch often starts with choosing the wrong level, not with a typo.
Why does markup drift away from real return terms?
Return terms change more often than most product data. A seasonal window, a change in who pays return shipping, or a switch from mail to in-store returns can all invalidate markup that was correct last quarter. Google's documentation describes how to specify return policy details using MerchantReturnPolicy structured data, including a link to your return policy page, conditions, return methods, return fees, and refund options.
Drift usually enters through one of four doors:
- The policy page is edited but the structured data is not.
- The structured data is edited but the policy page still shows the old terms.
- A product-level override is added and the site-wide policy is left contradicting it.
- The policy URL in the markup points to a page that has moved, redirected or been replaced.
Each of these is a content problem before it is a code problem.
A three-layer validation method
Run this as a repeatable pass rather than a one-off check.
Layer 1 — Visible text. Open the return policy page a shopper would reach from the product page. Record the return window, who pays return shipping, accepted return methods, refund type and any exceptions. Write these down as plain statements.
Layer 2 — Structured data. Extract the MerchantReturnPolicy block from the page source or a structured data viewer. List every property and its value. Note whether it sits under Organization or under an Offer.
Layer 3 — The URL bridge. Confirm that the policy URL referenced in the markup resolves to the same page you read in Layer 1, with no redirect chain and no locale mismatch.
Then compare Layer 1 against Layer 2 line by line. Any value in the markup that is not supported by the visible text is a mismatch, even if the code is technically valid.
Decision table: which mismatch needs which fix
| Symptom | Likely cause | Fix direction |
|---|---|---|
| Markup valid, policy page silent on a value | Markup describes terms the page never states | Add the term to the visible policy, or remove it from markup |
| Policy page updated, markup unchanged | Editorial change without a data change | Update the structured data in the same release |
| Product override contradicts site-wide policy | Override added without reviewing the parent | Decide which level is authoritative and align both |
| Policy URL redirects to a different locale | URL change or regional routing | Point markup at the canonical policy URL for that market |
| Rich Results Test passes but values look wrong | Test checks syntax, not truth | Re-run the three-layer comparison |
The last row is the one teams skip. A passing test tells you the markup is parseable. It does not tell you the markup is accurate.
Worked example (hypothetical)
Consider a hypothetical retailer selling in the UK and the US. Its site-wide policy under Organization states a 30-day return window. One product line, a clearance range, is marked final sale on the product page, and a MerchantReturnPolicy override is placed under that product's Offer.
During a quarterly check, the team finds the clearance override still lists a 30-day window because it was copied from the site-wide block. The visible product page says final sale. The markup is syntactically valid and would pass a syntax test, but it contradicts the page.
The fix is editorial first: confirm the final-sale term is the one the business actually applies, then make the override reflect it. The figures here are illustrative only and are not drawn from any real store.
What should you check on every release?
Treat return markup as part of the same release checklist as price and availability. The same discipline that keeps Product schema price and availability accurate applies here: structured data must agree with what shoppers see.
A short release check:
- Did any return term change? If yes, which layer changed first?
- Does every MerchantReturnPolicy block still resolve to a live policy URL?
- Do product-level overrides still agree with the site-wide policy where they overlap?
- Are market-specific terms separated, so UK and US wording is not blended into one block?
That last point matters because return rights and expectations differ by market. A single blended block invites contradictions.
How does this connect to the written policy?
Markup cannot rescue unclear terms. If the visible policy is ambiguous about who pays return shipping, no property value will make it unambiguous. The writing work comes first, and the markup mirrors it. A useful companion is the guide on writing ecommerce return policy terms shoppers can use, which focuses on the human-readable layer this markup depends on.
What are the limits and uncertainties?
Several things are genuinely uncertain and worth stating plainly:
- Google's documentation describes what the markup can express and how to test it, but it does not promise that any particular display will appear in Search.
- Product-level policies under Offer support fewer properties than site-wide policies, so some terms cannot be expressed at product level at all.
- The documentation does not prescribe a specific update cadence. Any review schedule is a team decision, not a documented rule.
- Where a source does not specify a step, the honest approach is to define your own verification method rather than invent a menu or API behaviour.
Validation, in the end, is a comparison habit. The code is only one of the three layers.
Follow-up questions
Does passing the Rich Results Test mean my return markup is correct?
No. The test checks whether the structured data is parseable and follows the expected shape. It does not compare values against your visible policy. Correctness requires the three-layer comparison described above.
Should I use a site-wide policy or product-level overrides?
Start with a site-wide policy under Organization for terms that apply to most products. Add product-level overrides under Offer only where a product genuinely differs, and remember that overrides support a more limited set of properties.