Assets & tasks / PRACTICAL ANSWER
Why Does My Structured Return Policy Describe the Wrong Country for an International Storefront?
Google's MerchantReturnPolicy uses applicableCountry to identify where a return policy applies. It separately supports returnPolicyCountry for the country to which goods must be returned. A single international storefront can therefore need more than one verified policy representation. Do not copy a home-market policy to every country merely because the same product page is available internationally.
Separate the policy's applicable market from its return destination
Google Search Central defines applicableCountry as the country where the product is sold and from which it will be returned. It uses two-letter ISO 3166-1 alpha-2 country codes. The distinct returnPolicyCountry property identifies where returned goods must be sent.
For example, a customer in Germany may be covered by a German-market return arrangement while the return parcel goes to a processing center in Ireland. Those are not contradictory locations; they describe different roles.
Begin with the merchant's approved return policies for each actual market. Record eligibility, return window, method, fees, refund options and return destination independently. Do not infer a policy from the website language, shipping warehouse or corporate registration address.
Google supports a standard merchant policy under an Organization through hasMerchantReturnPolicy, and product-specific overrides under an Offer. Choose the structure that corresponds to the merchant's real policy scope.
Group countries only when the actual policy is shared
Google allows an applicableCountry value or list of supported country codes. That is useful when one genuinely identical policy applies to several markets. It is not permission to combine countries with materially different terms.
Compare each country's approved return period, customer costs, accepted item conditions and refund arrangements. If these differ, model the supported policy distinctions rather than applying the home-country record globally.
Do not confuse the supported country count with evidence that every international policy can be represented completely in one object. Product-specific exceptions and different fee rules may require separate records or additional documented properties.
Where the available merchant documents do not establish a market's policy, hold that mapping for the responsible policy owner. A technically valid country code cannot verify the underlying customer promise.
Hypothetical three-market storefront
Hypothetical illustration—not a legal assessment or executed schema test: a fictional accessories merchant serves Germany, Austria and Switzerland. Its approved internal records stipulate that Germany and Austria share one return arrangement, while Switzerland uses a different verified return window.
The proposed schema map groups DE and AT only for the common policy. CH receives its own applicable policy representation. The merchant's German and Austrian returns are stipulated to go to a processing location in IE; that destination is recorded separately from applicableCountry.
A generator that emits only DE for the entire international site would omit the other applicable markets. A generator that assigns DE, AT and CH to one policy despite the different Swiss window would overgeneralize the terms.
The fictional worksheet identifies these differences but does not establish whether any real policy is enforceable or complete.
Validate the country map against the actual published terms
After implementing the supported structured-data representation, validate the page and inspect the relevant policy objects. Compare the visible policy link and customer-facing text with each mapped country.
Google's documentation also permits merchantReturnLink as a documented representation option. Where detailed structured fields cannot accurately express the merchant's verified arrangements, review the supported link-based approach rather than inventing unsupported properties.
Record whether a policy applies at organization level or overrides a particular product. Recheck when the seller changes markets, return locations or product-specific terms.
The acceptance criterion is an accurate mapping between verified policy records, the supported Google fields and the visible customer information. Structured-data validation is not a determination of consumer-law compliance or a guarantee that Google will display the policy.
Record your own observations
The filled rows are illustrative examples. Use the blank row for your own files and observations.
| Hypothetical market | Applicable country | Policy relationship | Return destination | Decision |
|---|---|---|---|---|
| Germany | DE | Shared verified arrangement A | IE | Map to arrangement A |
| Austria | AT | Shared verified arrangement A | IE | May share arrangement A |
| Switzerland | CH | Different verified window B | Separate destination to confirm | Use separate verified representation |
| Other storefront visitors | Unknown | No policy evidence supplied | Unknown | Do not infer coverage |
What the references establish
- Google Search Central — Merchant return policy structured data: Directly documents applicableCountry, returnPolicyCountry, organization-level policies, Offer-level overrides, merchantReturnLink and supported policy properties.
Sources and further reading
Recorded source-review dates are listed individually below. An undated source does not inherit the article’s publication date. Software and platform rules can change; check the current original before acting.
- Google Search Central — Merchant return policy structured data · Review date not separately recorded
Frequently asked questions
Is applicableCountry the same as the country where the return package is delivered?
No. Google documents returnPolicyCountry separately for the return destination.
Can I list several countries in one MerchantReturnPolicy?
Google supports multiple applicable countries, but the policy must truthfully apply to those markets. Separate materially different verified arrangements.
PREPARE ASSETS FOR YOUR NEXT STEP
Create supporting product assets in CartVisual.
Create new product creative assets in the workspace, then continue in your chosen tools. Third-party software procedures described in this guide take place in those applications; this workspace link does not imply an integration. Check current capabilities, account access and credit quotes.
Create account and open this workspace Check pricing and creditsStart with free concept and copy planning after sign-in. Image and video generation require available credits; review the quote before starting.
Already have an account? Open the workspace.