Short answer: write your return and shipping terms in plain language on the page, then describe the same terms in structured data. Returns use MerchantReturnPolicy and shipping uses OfferShippingDetails. Put your standard policy once, on a single returns page, under Organization, and use the product-level Offer only for exceptions. The markup has to say what the visible page says, and any settings you create in Merchant Center or Search Console will override your page markup. Google does not promise that rich results will appear, so the realistic goal is not a special look in search but a policy that machines can read as accurately as customers can.
This guide is for store owners, developers and catalog managers. It covers which facts get marked up, how the organization and product layers divide the work, what the shipping fields expect, and how to keep markup in step with the page and validate it. It ends with a list of common errors and a pre-launch checklist. If you also need price and availability, our product schema markup guide sits right next to this one. Here we stay on the returns and shipping layer only. Merchant Center feed problems are a different subject: that is data you upload, while this article is about the markup on your pages.
What Gets Marked Up: Window, Fees, Method
Return policy markup answers the questions shoppers ask before they buy. How long do I have? Who pays to send it back? Can I take it to a shop? Do I get my money back or store credit? Google's MerchantReturnPolicy documentation (Opens in a new tab) gives each of those questions a standard property.
The minimum: pick one of two routes
The documentation allows two ways to meet the required level. On the first route you provide applicableCountry together with returnPolicyCategory. The country property takes two-letter ISO 3166-1 alpha-2 codes, up to 50 of them. The category is one of three values: a finite return window, returns not permitted, or an unlimited window. Choosing the finite window makes merchantReturnDays required as well.
On the second route you provide only merchantReturnLink, the URL of a page that describes your policy. That page can be yours or belong to a third-party service that handles returns. The second route carries less detail. If you want to state the window and the fees in a form a machine can use directly, take the first route.
The recommended properties
The substance of a policy sits in the recommended properties. In the documentation they are:
| Property | What it describes | Values and notes from the documentation |
|---|---|---|
| merchantReturnDays | Days after delivery during which a return is accepted | Integer. Required when the category is a finite window |
| returnFees | Who pays the cost of returning the item | FreeReturn, ReturnFeesCustomerResponsibility, ReturnShippingFees |
| returnShippingFeesAmount | A fixed return shipping charge set by the merchant | Needed only with ReturnShippingFees, and must be non-zero |
| returnMethod | How the item comes back | ReturnAtKiosk, ReturnByMail, ReturnInStore. More than one can be given |
| itemCondition | Which condition of item may be returned | DamagedCondition, NewCondition, RefurbishedCondition, UsedCondition |
| refundType | The kind of refund | ExchangeRefund, FullRefund, StoreCreditRefund |
| restockingFee | A restocking charge | A number for a percentage, or a MonetaryAmount for a fixed fee |
| returnLabelSource | Where the return label comes from | ReturnLabelCustomerResponsibility, ReturnLabelDownloadAndPrint, ReturnLabelInBox |
| returnPolicyCountry | The country the return is sent to | ISO alpha-2 code. May differ from the country the item shipped from |
The documentation also defines separate fee, label and shipping-amount properties for customer remorse returns and for item defect returns. That lets you describe a two-tier policy truthfully: a fee when someone simply changes their mind, a free return when the product arrived faulty.
Dependencies that cause errors
Most mistakes come from how the fields depend on each other. When returnFees is FreeReturn or ReturnFeesCustomerResponsibility, you leave returnShippingFeesAmount out. When it is ReturnShippingFees, the amount is required and cannot be zero. So a free return is expressed with the FreeReturn value, not with a zero amount. Likewise, choosing the finite window without merchantReturnDays leaves the policy incomplete.
Seasonal overrides
The documentation includes returnPolicySeasonalOverride for temporary rules, such as a longer holiday window. An override carries its own category, the number of days when the window is finite, and start and end dates. In the page's own full example the end date comes before the start date, which looks like a typo. When you enter your dates, check that the end falls after the start.
A rule for what not to mark up
Do not mark up a condition that the page does not state. If your store accepts only unopened items, the new-condition value fits, but adding it to the markup before the rule is written on the page produces data that disagrees with the visible text. The documentation warns that markup that does not match the page can make the data ineligible even when the syntax is valid. We return to this in the validation section.
Organization-Level vs Product-Level Policies
In most stores one policy covers nearly everything, while a small set of products follows different rules: personalized items, hygiene products, digital codes. The documentation answers this with two layers.
The organization layer carries the default
You nest MerchantReturnPolicy under Organization with the hasMerchantReturnPolicy property. The documentation recommends placing it on one page that describes your return policy, not on every page. The reasoning is that a policy is a fact about the business, and repeating it on thousands of product pages adds maintenance without adding information. For the wider picture of organization and breadcrumb markup, our JSON-LD structured data guide covers how that layer is set up.
The offer layer carries the exceptions
A return policy nested under a product's Offer is meant for items that depart from the default. According to the merchant listing documentation (Opens in a new tab), the offer-level policy supports a subset of the organization-level properties. The required pair is applicableCountry and returnPolicyCategory. The recommended ones are merchantReturnDays, returnFees, returnMethod and, when a customer pays a fixed fee, returnShippingFeesAmount. To point at a policy defined elsewhere, you can use only the @id keyword, which avoids writing the same terms in two places and letting them drift apart.
Which source wins
When several sources exist, the documentation orders them from strongest to weakest: Content API for Shopping return settings, then Merchant Center or Search Console settings, then product-level merchant listing markup, then organization-level markup. It adds that Search Console settings override on-page markup.
| Priority | Source | When to check it |
|---|---|---|
| 1 | Content API for Shopping return settings | If you manage products through a feed or API, this setting outranks everything else |
| 2 | Merchant Center or Search Console settings | If your page says one thing and the results show another, look here first |
| 3 | Product-level Offer markup | For exceptions |
| 4 | Organization markup | For the standard policy |
A decision rule in four questions
- Is the policy the same for nearly every product? If so, build only the organization layer.
- Do some products follow different rules? Add offer-level policies for those products only.
- Have you entered return settings in Merchant Center or Search Console? Make sure your markup says the same thing, because that setting wins.
- Does a third party run your returns? Consider the link route, and also keep a short summary of the terms on your own site.
Example scenario: a store with three kinds of products
Example scenario: a store accepts returns on most items within a limited window, by post, with the customer paying the return label. Custom-engraved products cannot be returned. Gift cards follow a separate rule. The first rule lives on the single returns page and is marked up under Organization. The engraved products get an offer-level policy with the not-permitted category. The gift cards get their own written terms on the page and their own markup. Each group is readable by a person, expressible in markup and consistent between the two.
Why a single returns page matters
One page that holds the policy gives you one place to edit, one URL to inspect and one block of markup to validate. It also makes it simpler for shoppers to find the terms, since links from product pages, the footer and the checkout can all point to the same address. If the policy changes, you change one page and one block, not a template with thousands of outputs.
Shipping Details and Delivery Time Fields
Shipping costs and delivery times weigh on a purchase as much as returns. The merchant listing documentation covers them with the shippingDetails property on Offer, which takes an OfferShippingDetails object. The same advice as for returns applies: the documentation recommends providing a global shipping policy for the business under Organization markup, and using the offer-level version only to override it for particular products.
The OfferShippingDetails properties
| Property | Status | What it expects |
|---|---|---|
| shippingRate | Required | A MonetaryAmount. The currency (ISO 4217, three letters) must match the offer's currency. At least one of value or maxValue is needed, and 0 means free shipping. Only one shippingRate per OfferShippingDetails |
| shippingDestination | Required | A DefinedRegion with a two-letter country code (addressCountry) |
| deliveryTime | Required | A ShippingDeliveryTime. Do not give more than one |
| handlingTime | Recommended, inside deliveryTime | The typical delay between receiving an order and the goods leaving the warehouse |
| transitTime | Recommended, inside deliveryTime | The typical delay between dispatch and arrival at the customer |
Writing time ranges
Both handlingTime and transitTime are QuantitativeValue objects. The documentation requires minValue and maxValue to be non-negative whole numbers, both present, and the unit code to be DAY or d. A promise such as "ships in one to two days, arrives in three to five" becomes two day ranges. The property has no separate notion of business days versus calendar days, so state on the page which one you mean and keep the wording consistent with the numbers.
Narrowing a destination
Inside a DefinedRegion you may narrow beyond the country. The documentation lists addressRegion (an ISO 3166-2 subdivision code, supported for the US, Australia and Japan) and postalCode (supported for Australia, Canada and the US), and says not to use both. Because other countries are not listed for those narrower options, stay at country level when your terms apply to a whole country.
Free shipping for one region
One of the documentation's examples sets the shippingRate to 0 and limits the destination to a single region, so free shipping applies only there. Other regions get their own OfferShippingDetails with their own rate. If your rule is "free above a certain basket total", the property list in the documentation has no field dedicated to that. Write the condition clearly on the page and do not claim more in the markup than the listed properties can express.
Referencing a shared shipping policy
To avoid repeating shipping terms on every product, the documentation lets you use the hasShippingService property under OfferShippingDetails, with only the @id of a policy defined on another page. Updating a rate then means editing one definition instead of a whole catalog.
Keeping shipping and returns apart
Shipping describes the trip to the customer and returns describe the trip back. A common point of confusion is a page that advertises free shipping while the returns section says the customer pays the return label. These do not contradict each other, but they must be written as two separate sentences on the page and expressed in two separate fields in the markup: shippingRate for the outbound cost and returnFees for the return. Otherwise shoppers assume that "free" covers both.
Matching On-Page Content and Validating
Structured data is a machine-readable copy of what the page says. Problems begin when the copy says more than the original, or something else.
The matching principle
The return policy documentation is direct about this: the Rich Results Test cannot detect every problem, and content or spam issues, such as markup that does not match the page, can make the data ineligible even if the syntax is valid. A manual action causes the page's structured data to be ignored, although the page itself can still appear in results. Google's ecommerce structured data overview (Opens in a new tab) notes that Organization markup can cover return policies for the business as a whole, but it does not state a separate matching rule. Matching is therefore a working rule drawn from the general guidelines and the warning on the return policy page.
A validation sequence
The requirements on the return policy page translate into this order of work:
- Read the general structured data guidelines and Search Essentials. Return markup sits on top of them.
- Run the Rich Results Test. Fix critical errors.
- Use the URL Inspection tool to confirm Google can reach the page. It must not be blocked by robots.txt, carry a noindex tag or sit behind a login.
- Allow time for recrawling and reindexing. The documentation mentions this explicitly, and submitting a sitemap helps keep Google informed.
- Check Merchant Center and Search Console settings. They override your markup.
If you work in a localized interface, menu names in Merchant Center and Search Console may look different from the English ones. Find the section by what it does rather than by its label.
Set the right expectation
The documentation says Google does not guarantee that rich results will appear. Complete markup is not a promise of a particular appearance, ranking or click rate, and the documentation says nothing about a ranking effect from this markup. What you can expect is that an accurate, consistent and reachable policy helps Google understand the information correctly.
A mapping between markup and visible text
Every property you mark up should have a matching sentence on the page. The table below makes a handy reference when you work with a content team.
| Markup property | What the page should say |
|---|---|
| merchantReturnDays | One sentence with one clear number of days after delivery |
| returnFees | Who pays for the return, in plain words |
| returnMethod | The list of ways to send the item back: post, shop or drop-off point |
| refundType | Whether the customer gets money back, an exchange or store credit |
| shippingRate | The delivery charge and the free shipping condition |
| handlingTime and transitTime | How long preparation takes and how long the trip takes |
Who owns what
Return and shipping markup is rarely one person's job, and it usually breaks in the gaps between teams. Customer service or legal sets the policy, a writer drafts the page text, a developer adds the markup and a catalog manager keeps Merchant Center settings up to date. Each person can do a correct job and the whole can still disagree after one change. Add a rule to your workflow: a policy change closes four items in the same ticket. The page text is updated, the markup is updated, the Merchant Center and Search Console settings are reviewed and validation is rerun.
In a small shop one person holds all four roles, which is not easier, because nobody notices which step they skipped. A change log is enough. Record the date the value changed, the date the markup changed and the date of the last test result.
Example scenario: a promotion that outlived itself
Example scenario: a store extends its return window for the holidays using the seasonal override. When the promotion ends, the banner disappears from the page but the override stays in the markup. Now the page shows the standard window and the markup shows the extended one. Two habits prevent this: always give an override an end date, and add a "remove the override" task to the campaign calendar.
Common Errors and a Checklist
Frequent mistakes
- Writing a free return as a zero amount. Use FreeReturn and leave the amount property out.
- Choosing a finite window without the number of days. merchantReturnDays is required in that case.
- Marking up a different number than the page shows. For example 14 days on the page and 30 in the markup.
- Copying the organization policy into every product page. The documentation suggests a single returns page.
- Forgetting a Merchant Center setting. It overrides your markup, and it is the most common answer to "why did nothing change".
- Blocking the returns page. A robots.txt rule, a noindex tag or a login wall stops the page from being read.
- Using a shipping currency that differs from the offer. The currency must match the offer's.
- Reversing seasonal dates. The end must come after the start.
- Using region codes for unsupported countries. addressRegion and postalCode are supported only for the countries the documentation lists.
- Adding currency symbols to amounts. The documentation says numeric strings should not carry currency symbols or separators.
Pre-launch checklist
- Is the return and shipping policy written clearly, dated and unambiguous on the page?
- Is the single returns page marked up under Organization?
- Do the category, number of days and fee values agree with each other?
- Are exceptional products marked up separately at the offer level?
- Does every offer have shippingRate, shippingDestination and deliveryTime?
- Are time ranges whole numbers with a day unit?
- Does the Rich Results Test show no critical errors?
- Has URL Inspection confirmed that Google can access the page?
- Do Merchant Center and Search Console settings agree with the markup?
- Will text and markup be updated in the same release when the policy changes?
A two-week rollout plan
If you are starting from scratch, split the work into small steps. First take stock: how many different return and shipping texts exist on the site, and which contradict each other? Pick one official policy text and either redirect or remove the rest. Build and validate the organization-level return markup. List the exceptional product groups and write one sentence for each saying why it is an exception, because an exception you cannot explain is usually unnecessary. Try shipping markup on your best-selling group first, validate it, and then extend it to the rest of the catalog. Finally compare Merchant Center and Search Console settings with the markup and close any gaps.
This order prevents two problems. One is a half-finished setup that tells the old policy in some places and the new one in others. The other is a mistake that spreads to the whole catalog instead of one product group.
Multi-country selling
The applicableCountry property supports up to 50 countries, so if your terms differ by country you need a separate policy for each set of terms. The returnPolicyCountry property names where the return must be sent and may differ from the shipping origin. If you ship from one warehouse but process returns at another, that property expresses the difference. For shoppers, the page should show the return address and cost by country in a form they can read.
Discontinued products
Return and shipping markup lives as long as the product page does. When a product leaves the catalog, what happens to its page is a separate decision, covered in our guide on out-of-stock and discontinued product pages. If the page is removed for good, its offer markup goes with it; the organization-level returns page stays.
Brand trust beyond the page
A clear return and shipping policy is one of the first trust cues a shopper sees. How others write about your brand adds to it, and we cover that for online stores in our guide to sponsored content for ecommerce brands. The two do not replace each other: markup describes the policy on the page, and outside coverage supports the confidence people place in the brand.
Related guides: Customer Reviews and SEO: How to Collect, Display and Mark Up Reviews, Google Business Profile Verification Problems: Video, Postcard, Phone, Google Business Profile Suspended: Reasons, Reinstatement, Prevention.
Conclusion
Return and shipping markup rests on three principles. Say on the machine-readable layer exactly what the page says, with the same numbers and the same meaning. Keep the standard policy in one place under Organization and mark up only exceptions at the product level. And remember that Merchant Center and Search Console settings override page markup, so establish a single source of truth. Validators see syntax, not whether a policy is true or current, which means the real check stays with people. Limits and property lists in Google's documentation can change, so consult the current pages before you implement. No markup guarantees a rich result or a particular ranking.
Once the policy is live, being mentioned on trusted outside sites supports shopper confidence too. You can look at the backlink packages at Akua Adforce; scope and terms are listed on the product page.
Frequently Asked Questions
Which structured data type describes a return policy?
Return policies use the MerchantReturnPolicy type. You provide the standard policy under Organization with hasMerchantReturnPolicy, and exceptions for particular products under Offer with the same property. The required core is the pair applicableCountry and returnPolicyCategory, or alternatively just merchantReturnLink.
Do I add the return policy markup to every product page?
No. Google's documentation recommends placing the standard policy under Organization on a single page that describes your return policy. Offer-level markup is only for products that depart from the standard.
How do I mark up a free return?
Set returnFees to FreeReturn and leave returnShippingFeesAmount out. The amount property is only required with ReturnShippingFees, and it must be greater than zero.
If Merchant Center and my page markup disagree, which one is used?
According to Google's documentation, Merchant Center or Search Console settings take precedence over on-page markup, and Content API for Shopping return settings sit at the very top of the list. The safest approach is to keep all three saying the same thing.
How are shipping times written in markup?
Under deliveryTime you give handlingTime and transitTime. Each is a QuantitativeValue whose minValue and maxValue are non-negative whole numbers and whose unitCode is DAY or d. They are used together with shippingRate and shippingDestination.
Will the return information definitely show up in search if I add markup?
No. Google does not guarantee that rich results will appear. If the markup does not match the page, the data can be ineligible even when the syntax is valid, so keep page text and markup updated together.
Post a comment
Please log in to leave a comment. Login