Should you deploy return policy markup at the organization level instead of the product level?

What's the difference between product markup and organization markup?

Until now, to display a return policy in rich results, you had to associate it with each product page individually. The MerchantReturnPolicy markup had to be nested within each Product or Offer. For a catalog of 10,000 SKUs, this meant duplicating the information 10,000 times.

With organization-level markup, you declare your global return policy just once on a dedicated page (like "/return-policy"). Google can then apply this information to all your products without you having to repeat it everywhere.

Why is Google introducing this option now?

The answer comes down to two things: scalability and consistency. Large e-commerce sites manage catalogs that evolve daily. Maintaining identical markup across thousands of product pages represents a significant technical burden, especially when the return policy changes — extending from 14 to 30 days, modifying return fees, etc.

By centralizing the information, Google makes life easier for webmasters while ensuring that displayed data remains consistent. Fewer risks of inconsistencies between pages, fewer deployment errors.

Does this completely replace product-level markup?

No. The two approaches coexist and are complementary. If you have products with specific return policies — for example, non-returnable personalized items or categories with different conditions — you can still use product-level markup for these exceptions.

Organization markup serves as a default policy. Product markup overrides it when it exists. This is a cascading logic similar to CSS.

• Organization markup declares a default global policy applicable to all products
• Product markup can override this policy for special cases
• Google always prioritizes the most specific markup (product > organization)
• Both can work simultaneously on the same site
• This evolution drastically reduces maintenance for uniform catalogs

Does this simplification hide implementation pitfalls?

The concept looks good on paper, but technical execution can run into issues. First question: exactly where should you place this organization markup? Google remains vague about the prerequisites for the page hosting the schema. Does it need to be indexed? Accessible from the homepage? Linked from each product page?

Second point — and this is where it gets interesting — how does Google associate this policy with products if it's not explicitly linked in the markup? We can assume it uses the same domain or Organization entity detection, but no official documentation confirms this. [Needs verification]

How robust is the display in rich results?

Let's be honest: e-commerce rich snippets remain volatile and unpredictable. Even with perfectly validated markup in the Rich Results Test, nothing guarantees Google will display your return info. Search competition, historical CTR, overall site quality — all of it matters.

I've seen sites with flawless organization markup never trigger the display, while others with patchy product markup succeeded. Official documentation provides no clear triggering threshold. Frustrating, but that's the reality of the game.

Should all e-commerce sites migrate to this system?

It depends. If you have a single, uniform return policy across 95% of your catalog, then yes, organization markup simplifies life. Less duplicated code, centralized maintenance, faster deployment of changes.

However, if your model relies on category-differentiated policies — fashion with 60 days, electronics 14 days, fresh products non-returnable — then product markup remains more suitable. You maintain the necessary granularity without creating an overcomplicated system at the organization level.

How do you concretely implement organization markup?

Create a dedicated page (like /return-policy) that clearly details your return conditions for both humans and Google. This page must be indexable and accessible from your footer or legal notices.

Then integrate the MerchantReturnPolicy schema at the Organization level, not Product. Here's the minimum structure to respect: Organization type, your business name, your site URL, then the MerchantReturnPolicy object with returnPolicyCategory, merchantReturnDays, returnMethod, returnFees.

Validate your markup with Google's Rich Results Test. Verify that all required properties are present and correctly typed. Then monitor Search Console to detect any parsing errors.

What are the risks to avoid during migration?

Don't create conflicts between organization and product markup. If both coexist with contradictory information (30 days at organization level vs 14 days on certain products), Google may ignore both or display anything.

Also avoid placing organization markup on a page blocked in robots.txt or with noindex. Even if Google claims to crawl certain blocked content for context, it's better not to push your luck. Make this page perfectly accessible.

Finally, don't remove the old product markup overnight. Keep a transition period of 2-3 months where both systems function in parallel, giving you time to validate that Google understands and correctly displays the new structure.

How do you verify the deployment works?

• Validate organization markup with Google's Rich Results Test
• Verify indexation of the return policy page in Search Console
• Monitor "Products" improvement reports to detect errors or warnings
• Test rich results display on a few key product queries
• Monitor impressions and CTR over 30 days to detect any abnormal variations
• Compare rich snippet display rates before/after migration