Google can use MerchantReturnPolicy structured data to understand return information for products and merchant knowledge panels. A standard policy can sit under Organization or OnlineStore markup, while product-level Offer markup is for genuine exceptions. Because Google applies a precedence order across APIs, Merchant Center, Search Console, product markup, and organization markup, a technically valid page can still lose to a conflicting higher-priority setting.

VISUAL LESSON

What you will learn

  1. 01Choose organization-level policy or a product-specific override correctly.
  2. 02Map visible return terms to supported structured-data fields.
  3. 03Test syntax, precedence, crawlability, and operational truth.
A visible merchant return policy maps into organization and product-level structured data before validation and precedence checks
Return-policy markup is an evidence chain: written policy, supported fields, product exceptions, platform precedence, validation, and ongoing operations must agree.

ILLUSTRATIVE WORKED EXAMPLE

Audit an illustrative 25-product return-policy set

Products reviewedCatalog sample
25
Standard policyOrganization-level
22
True exceptionsOffer overrides
3
Cross-system conflictsResolve before launch
2
Illustrative example—not a benchmark. Replace every sample value with your own campaign, market, and measurement data.

PRACTICAL INTERFACE MAP

Move from operating policy to search-eligible markup

Policy01Freeze the customer-facing rules

Record applicable countries, return-policy country, window, conditions, methods, fees, labels, refund type, seasonal overrides, product exceptions, effective dates, owner, and support path.

Markup02Choose the correct structured-data level

Nest the standard MerchantReturnPolicy under Organization or OnlineStore; use the supported Offer subset only when a product genuinely overrides the standard policy.

Release03Validate and reconcile precedence

Test JSON-LD, visible-content agreement, crawlability, Rich Results Test, URL Inspection, Merchant Center or Search Console settings, product feeds, exceptions, and change alerts.

Conceptual walkthrough. Labels, controls, and availability can vary by account, region, plan, and interface version; verify the current screen before acting.

STEP-BY-STEP LESSON

Visible return rules → structured policy → precedence check → validated release

WriteCustomer-facing truth
ModelStandard and exceptions
GovernSystems stay aligned

THE LEAD ATLAS METHOD

Lead Atlas Data can research business contacts for a customer’s categories, market, and locations, while the merchant website publishes the exact return terms those prospects and customers can verify.See how custom list research works ↗
01

Write the operating policy before JSON-LD

Record the applicable sales countries, return-policy country, finite, unlimited, or no-return category, return window, eligible item conditions, return methods, fees, label responsibility, refund method, restocking or shipping charges, seasonal overrides, product exceptions, effective dates, support route, and legal and operations owners.

The visible policy, customer service script, checkout, order confirmation, warehouse process, and refund system must agree. Structured data cannot repair unclear or contradictory real-world terms.

02

Choose the correct policy level

Use one standard MerchantReturnPolicy nested under Organization or OnlineStore when the terms apply to most products. Use product-level Offer markup only for genuine product exceptions or when no standard merchant policy exists, and follow the smaller set of properties Google supports there.

Do not copy a policy onto every product without a governance rule. Google recommends a single policy page for the business and notes that product-level data can override the organization-level policy.

03

Map terms to supported properties

Choose Option A fields such as applicableCountry and returnPolicyCategory, adding merchantReturnDays for a finite window, or use merchantReturnLink when that matches the implementation. Add only supported, truthful conditions, methods, fees, refund types, label sources, and seasonal dates.

Use ISO country codes, whole-day windows, correct schema.org enumerations, matching currencies, and valid seasonal ranges. Do not mark returns free when the customer pays shipping or omit a material product exception visible elsewhere.

04

Validate syntax, meaning, and precedence

Run the Rich Results Test and schema validation, inspect server-rendered HTML, verify the policy page is crawlable and indexable, deploy a small sample, and use URL Inspection. Compare the result with Content API, Merchant Center, Search Console, product feeds, product markup, and organization markup.

Google’s documented precedence runs from Content API, then Merchant Center or Search Console, product-level markup, and organization-level markup. Resolve contradictions in the actual source of truth rather than repeatedly editing a lower-priority page.

05

Operate the policy as governed data

Set alerts and review steps for policy, country, fee, warehouse, carrier, seasonal, catalog, legal, Merchant Center, and support changes. Re-test representative products and refund paths after every material update, and monitor Search Console without promising a rich result.

Deliverable: visible return policy, country and product scope, policy-level decision, property map, JSON-LD, exception register, Rich Results Test, crawl and URL Inspection proof, cross-system precedence audit, operational QA, update trigger, rollback, and owner.

THE TAKEAWAY

Markup must describe the visible operating policy, not invent one; keep the scope and precedence explicit, validate both syntax and meaning, and never guarantee that Google will display the return treatment.

OFFICIAL REFERENCES

Check the platform’s current instructions.

Platform labels, eligibility, and workflows can change. These official help pages were used to validate this lesson.