Should you declare shipping and return policies at the organization level in structured data?

What exactly changes with this update?

Until now, shipping and return policies had to be specified at the level of each product or offer in structured data. Google now accepts a global declaration at the organization level, which applies by default to your entire catalog.

In practice, this means that an e-commerce site with uniform conditions can centralize this information in the Organization markup, instead of repeating it for each Product or Offer. Search Console now displays this data and flags any structural errors.

Why is Google introducing this option now?

The answer comes down to one word: scalability. Large catalogs suffered from massive redundancy in structured data. Repeating the same policies across 10,000 product pages bloated the code and complicated maintenance.

Google is also looking to improve the display of merchant information in rich results. The cleaner and more centralized the data, the easier it is to use it to display shipping costs, delivery times, or return conditions directly in the SERPs.

What types of policies can be declared at the organization level?

We're talking about ShippingRateSettings (shipping rates and zones) and MerchantReturnPolicy (return conditions, timeframes, possible fees). These schema.org properties already existed at the Offer level, and are now available on the Organization entity.

• ShippingRateSettings: geographic zones, shipping rates, delivery timeframes
• MerchantReturnPolicy: withdrawal period, return modalities, return fees
• These policies apply by default to all products, unless explicitly overridden at the product level
• Search Console provides a dedicated report to monitor the validity of this data
• Centralization reduces technical debt and simplifies global updates

Is this declaration consistent with what we observe in the field?

Absolutely. Sites that had implemented these policies at the product level have been complaining for months about markup complexity. Some e-commerce platforms generated JSON-LD of several hundred lines per product page, 80% of which was repetition.

Google clearly listened to feedback. But — and this is where it gets tricky — this option doesn't exempt you from correct product markup. If your Organization declares a general policy but your product pages are poorly structured elsewhere, you still won't get rich results.

What nuances should we add to this announcement?

First nuance: the organization level doesn't replace the product level, it complements it. If a product has special conditions (oversized shipping, returns not accepted for hygiene reasons), you still need to specify it at the Offer level.

Second nuance: Google doesn't guarantee anywhere that this data will be displayed in results. Technical support exists, but SERP exploitation remains discretionary. We've already seen this pattern with FAQs or HowTo — markup validated, display inconsistent.

In what cases does this option change nothing?

If you have differentiated policies by category (fashion vs appliances, for example), the organization level won't help you much. You'll need to keep managing that at the product level or create multiple Organization entities (a clunky solution, not recommended).

Similarly, marketplaces with multiple sellers can't use this approach: each seller has their own conditions. Markup remains necessarily at the Offer level, vendor by vendor.

What should you do concretely to implement this feature?

First, audit your current policies. If they're uniform across your catalog, you're an ideal candidate. If they vary, identify exceptions before centralizing.

Next, add the shippingDetails and returnPolicy properties to your Organization markup (typically in the site footer or header). Verify the syntax with Google's structured data validator. Then monitor the dedicated report in Search Console.

Finally, gradually clean up redundancies at the product level. Don't remove everything at once — test on a sample first, verify that rich results don't disappear, then deploy.

What errors should you avoid during migration?

Classic mistake: declaring a policy at the organization level without consistency with visible content. If your "Shipping Terms" page says one thing and your JSON-LD says another, you risk manual or algorithmic action.

Another trap: forgetting geographic exceptions. If you ship free in France but not to Corsica, your markup must reflect it with appropriate zones (shippingDestination). Otherwise, you're misleading Google.

• Verify that policies are truly uniform across the relevant catalog
• Add Organization markup with shippingDetails and returnPolicy compliant with schema.org
• Test with the structured data validator and Rich Results Test
• Monitor the new reports in Search Console (Enhancements section)
• Keep markup at the product level for special cases (surcharges, exclusions)
• Document the fallback logic: what happens if a product doesn't have an explicit policy?
• Plan for post-deployment monitoring: click-through rate, rich results display, user feedback

How do you verify that the implementation is working correctly?

Use the Rich Results Test on a typical product page. Google should recognize the organization-level policy and apply it to the product if it doesn't declare one. If the test detects nothing, your syntax is probably incorrect.

Next, wait a few days and check Search Console. The "Merchant Policies" report (or equivalent depending on your language) should list your pages without critical errors. If warnings appear, fix them immediately — Google is particular about this data.