Google Shipping and Return Settings: All Your Options, and What Takes Precedence

Shipping and return policies can be configured in multiple places with Google, and the interactions between those places are not always obvious. If you're getting into conflicts, seeing stale data surfaced, or just trying to understand which method is right for your setup, here's how it all fits together.

The reason this gets complicated is that Google surfaces shipping and return information across multiple products (Shopping ads, free listings, product rich results), and each product has slightly different data requirements and ingestion paths. There is no single "shipping settings" field. There are five distinct configuration layers, each with its own scope and authority.

The five configuration layers

Before getting into the details of each, it's useful to have the full picture. Google can read your shipping and return information from:

1. Product-level feed attributes in Merchant Center: set per-product in your submitted feed.
2. Programmatic Merchant API v1: settings written via the API, mostly by feed management platforms and automation tools.
3. Account-level settings in Merchant Center or Search Console: the same layer in precedence, but GMC has primacy. Anything set in Search Console auto-syncs into Merchant Center; once a policy is created or edited in MC, it can only be managed there, and Search Console shows it as a read-only reference for 30 days.
4. Product-level merchant listing markup: shippingDetails and hasMerchantReturnPolicy in structured data on individual product pages.
5. Organisation-level markup: return policy defined at site level in Organisation schema. The fallback signal.

Each layer has a different scope and a different relationship to the others. The right combination depends on your stack, how often your policies change, and whether you're running Shopping campaigns or relying on free listings and rich results.

Merchant Center: the canonical home for Shopping

If you're running Google Shopping campaigns or want your products to appear in free listings with accurate shipping and return information, Merchant Center is where that data lives. You configure shipping settings and return policies under the relevant account settings sections.

Account-level settings in GMC apply to your entire product catalogue by default. You define shipping services (carrier, regions, rates, transit times), return windows, conditions, and fees. These settings are what Google uses to populate the shipping and returns annotations you see on Shopping listings.

The main advantage of GMC settings over markup is control and visibility. You can preview how policies will display, and changes take effect across your entire catalogue without touching individual product pages or feeds.

Search Console: an alternative that auto-syncs to GMC

This is the least-known option and the source of the most confusion I see. You can configure shipping and return policies directly in Search Console under Settings, and Google will automatically push those settings to Merchant Center.

This matters in a few scenarios:

• You have a verified Search Console property but haven't completed full GMC onboarding
• You want a simpler UI for managing policies without navigating GMC's more complex settings structure
• You manage multiple properties and find SC a cleaner entry point

The key point is that SC settings and GMC settings are not separate databases. They converge, but with a primacy rule. Anything you set in Search Console auto-syncs into Merchant Center. Once a policy is touched in MC after that, it belongs to MC: Search Console can no longer edit it, and shows the policy as a read-only reference for 30 days.

Merchant listing markup: product-level signals

Shipping and return information can also be embedded directly in your product pages via structured data. The relevant properties are shippingDetails and hasMerchantReturnPolicy, used in merchant listing markup on individual product pages.

This approach puts the data in the page itself, which can be useful when:

• You don't have a GMC account but want shipping and returns to appear in product rich results
• Policies vary significantly by product and you want per-product precision in the markup
• You want markup to act as a backup signal when feed data isn't present

The limitation is maintenance. Every time a policy changes (new return window, updated shipping costs, expanded regions), you either update every affected product page or accept that your markup is stale. For catalogues with frequent policy changes, this overhead is real.

To generate the correct markup for your product pages, use the Merchant Listing Schema Generator.

Organisation markup: the weakest signal

It's also possible to define return policies at the site level using Organisation schema. This applies a single policy to the entire site rather than individual products.

This is the weakest configuration in the hierarchy. Google treats organisation-level signals as a fallback: useful when no other data is available, but easily overridden by anything more specific. If you have GMC settings, a product feed, or product-level markup, organisation markup won't make a material difference to what Google shows.

Where it can help: smaller retailers without a GMC account and without product-level markup who want some policy signal present. It's better than nothing, but it's not a substitute for the approaches above.

What Google uses when you define multiple configurations

This is the part that trips people up. When shipping or return data exists in more than one place, Google follows a strict order of precedence. Stronger sources override weaker ones completely. There is no blending.

• Product-level feed attributes in Merchant Center Strongest

  The shipping and return_policy_label attributes set on individual products in your submitted feed. These override everything else for that specific product.
• Merchant API v1 (programmatic)

  Shipping and return configuration written programmatically via the API. Used by feed management platforms and automation tools.
• Settings in Merchant Center or Search Console

  Account-level policies. The two converge, but GMC has primacy: once a policy is created or edited in Merchant Center, it can only be managed there. Search Console shows it as a read-only reference for 30 days.
• Product-level merchant listing markup

  shippingDetails and hasMerchantReturnPolicy in structured data on individual product pages.
• Organisation-level markup Weakest

  Return policy defined at site level in Organisation schema. Only used when no higher-precedence source exists.

The practical implication: if you have a product feed with shipping attributes set, your structured data values for shipping are functionally invisible to Google Shopping. The feed wins. Markup can still support rich results independently, but for Shopping purposes it's been overridden.

This also means that cleaning up a conflict isn't always about fixing the markup. It's about understanding which layer is actually winning and whether that layer has correct data.

The silent failure mode

This is the failure mode that costs people the most time, because nothing about it looks like a failure.

You implement Merchant Listing markup. It validates in the Rich Results Test. The product page passes Search Console's structured data checks. Nothing breaks. There is no error, no warning, and no indication that anything is wrong.

Six months later, someone notices that the rich result in Shopping is showing free delivery while the website charges £4.99. Or worse: a listing is rejected for a mismatch nobody knew existed. The investigation eventually traces back to an account-level shipping rate set in Merchant Center years ago, never updated, quietly overriding every line of markup since.

The markup didn't fail. It was never the source of truth in the first place. Nothing in the validation tooling tells you that.

A worked example

A UK retailer has all four layers populated:

• A Merchant Center feed with shipping(country:GB, price:4.99 GBP, service:Standard) on most SKUs
• A Search Console shipping policy of "Free over £50, otherwise £3.99" set last year
• Product-level JSON-LD with OfferShippingDetails returning £2.99 for orders under 1kg
• An Organization block with a generic shippingDetails of "£4.99 standard UK shipping"

Which one shows up in the rich result?

The feed value: £4.99. For any SKU covered by the feed, the Search Console policy is ignored, the JSON-LD is ignored, and the Organisation markup is ignored. For SKUs not in the feed, the Search Console policy takes over. The markup only ever drives the rich result for SKUs in neither layer, which on most ecommerce sites is effectively zero products.

Now consider the scenario where the merchandising team runs a feed-level promotion that drops shipping to £2.99, the dev team updates the feed, and the on-site shipping rule never gets touched. Customers click the listing expecting £2.99 and find £4.99 at checkout. Google's documentation is explicit about what happens next: a listing can be rejected if Google finds a lower shipping cost on the listing than on the website. The direction of the mismatch matters. Listing cheaper than site is rejection territory; site cheaper than listing is not. Either way, the gap between them is what gets flagged.

Where each layer is the right source of truth

No single layer is correct for every retailer. The right home for shipping and return data depends on your catalogue size, how often policies change, and whether you operate a feed at all.

When the feed is the right source

• You sell more than a handful of SKUs and shipping varies by weight, category, or region
• You run frequent promotions that affect shipping costs or thresholds
• You already operate a Merchant Center feed, at which point the feed becomes the practical canonical source whether that was intentional or not

When Search Console or Merchant Center account-level is the right source

• You have one shipping policy per country and it rarely changes
• You do not have a feed, do not want one, and just need policies attached to your domain for free listings
• Your return window and cost are consistent across products

When product-level markup is the right source

• You have no Merchant Center account at all and Search Console settings are too coarse for your catalogue
• You want a defensive signal for AI Overviews, third-party indexers, and merchant listings outside Google's Shopping graph
• You want a single canonical place. Your CMS already has shipping logic, and mirroring it in markup keeps the data auditable in one spot

Where conflicts most often appear

• You implement markup and a feed, then update only one. The feed wins, the markup goes stale
• You set policies in both Merchant Center and Search Console, edit the MC version, and wonder why the Search Console UI still shows the old one. It will, with a note that the policy is now managed in MC, for 30 days
• You submit return policies and assume they are live. Returns require manual verification and take 10 to 13 days. Shipping is auto-approved on submission. Schedule launches accordingly
• You declare shipping costs on Organization and assume that covers product pages. It does not. Organisation-level is the weakest signal and only applies when nothing higher-precedence exists

The decision tree

Work through in order. Stop at the first match.

What to do instead of "implement schema and forget"

The single most useful principle: decide where the source of truth lives, then make every other layer either inherit from it or stay out of the way.

Concretely, that means a few habits:

• Pick one canonical system. Feed, Search Console, or markup. Document the decision. Tell the team. The cost of which system you pick is much smaller than the cost of leaving the choice implicit.
• If you have a Merchant Center feed, deprecate manually set policies in Search Console. They will not be honoured for fed products anyway, and keeping them around creates a drift surface no one wants to audit six months later.
• If you keep markup as a safety net, audit it on every shipping price change. A simple monthly diff between your OfferShippingDetails values and your Merchant Center feed values catches drift before Google does.
• Match the on-site shipping cost to the listing exactly. Not approximately. Same currency, same number, same conditions. Recovering a rejected listing is straightforward but slow, and the impressions lost during the recovery window do not come back.
• Treat returns and shipping as separate launches. Returns verify slower than shipping. If you are launching a new return policy, set it up around two weeks before you need it live. Shipping you can set the morning of.

Making the change without breaking what works

If you are currently signalling shipping in three or four places and want to consolidate, the migration is not particularly complex, but it does need to happen in order.

1. Audit current state. Pick three representative products. For each, manually compare the feed value, the Merchant Center account-level value, the Search Console value, the JSON-LD value, and the on-site checkout value. List them in a sheet. The number of cells that do not match will be larger than you expect.
2. Decide the canonical source. Use the decision tree above.
3. Update the canonical source first. Confirm it propagates: typically 24 to 48 hours for feed-level changes, longer if your re-crawl backlog is long.
4. Then strip or align the weaker signals. Remove conflicting account-level policies. Update markup to match, or remove it entirely. Update Organization markup to a plausible site-wide fallback or leave it out.
5. Re-test. Pull a sample of products through the Rich Results Test. Check Merchant Center diagnostics for shipping or returns warnings. Verify the live rich result in a real search query.

There is no shortcut and no tool that handles this end-to-end. The cleanup is the project.

A closer look at the Search Console route

For sites without a Merchant Center account, the Search Console Shipping and returns settings (under Settings › Shopping) are a useful addition. They give you a Merchant Center-grade signal without the overhead of running a feed. The forms are limited (one shipping policy per country, flat or "free over X" cost models, basic return windows), but for a long tail of merchants that is enough.

A few things worth knowing before you commit to this route:

• Owner or full user access on the Search Console property is required
• If you also have a Merchant Center account, you must associate the two. Policies created in MC then appear in Search Console as a read-only link for 30 days. After that, they are managed only in MC. This is intentional and worth knowing before someone goes hunting for them in the wrong interface
• Returns require manual verification. You submit them, wait 10 to 13 days, then check the status. Shipping is auto-approved on submission
• Anything you set in Search Console is automatically pushed to Merchant Center if the accounts are linked. That is useful for keeping a single source of truth without operating the feed yourself

Beyond Google: the durable principle

The precedence ladder above is specific to Google. The principle underneath it, alignment between feed, schema, and front-end, outlasts any specific platform. Other automated buyers, including AI shopping agents, compare the same layers, and when the layers disagree the rational response is to trust none of them. Consolidating to one canonical source is not a Google-only fix. It is what keeps the catalogue legible to whichever system reads it next.