Shipping and tax attributes
How shipping and tax are set in Merchant Center, covering account-level settings versus feed-level shipping, when per-product overrides are needed, US tax basics, and the contradictions that disapprove.
Shipping and tax can be set once at the account level or, when a product is an exception, overridden per product in the feed. Most stores are best served by account-level settings with a handful of feed overrides for oversized or special items. The disapprovals here come from contradictions: a feed override that fights the account settings, or shipping that doesn't match what the landing page charges.
The shipping and tax attributes
| Attribute | What it is | Example |
|---|---|---|
shipping |
A per-product shipping rate override (country, region, service, price) | GB::Standard:3.99 GBP |
shipping_weight |
Product weight used to calculate rates | 1.2 kg |
shipping_length / _width / _height |
Dimensions for dimensional-weight pricing | 30 cm |
tax |
US sales-tax handling per region | US:CA:8.25:y |
For most merchants these attributes stay mostly empty, because the sensible default is to configure shipping and tax once, at the account level, and reach for the feed only for the exceptions.
Account-level vs feed-level shipping
- Account-level (set in Merchant Center settings) is the default and the right home for your standard rates: flat rate, free over a threshold, carrier-calculated. Set once, applies to the whole catalogue, easy to keep current.
- Feed-level (the
shippingattribute per product) is an override for products the account rules get wrong.
You only need feed-level shipping when a product genuinely deviates:
- Oversized or heavy items (furniture, appliances) with special freight rates.
- Free shipping on specific products while the rest of the catalogue pays.
- Products excluded from shipping to certain regions.
For everything else, leave shipping empty and let the account settings do the work. shipping_weight and the dimension attributes are worth sending whenever rates are weight- or size-based, so Google can calculate correctly.
Tax (US)
The tax attribute applies to US sales tax only:
- Set your standard nexus-based tax at the account level; use the
taxattribute for per-product exceptions (e.g. a tax-exempt product category). - Outside the US (UK and EU included), you do not submit a
taxattribute at all. VAT is baked into the displayedprice, so the job there is simply making surepriceis the tax-inclusive amount the shopper pays (see price and availability).
Deep dive The contradictions that disapprove
Shipping and tax rarely disapprove for being absent; the account settings usually cover the gap. They disapprove for contradiction, which is subtler and easier to create by accident:
- Feed override fighting account settings. A leftover
shippingvalue on a product that no longer needs one, contradicting the account rule Google would otherwise apply. Google sees two answers and treats the conflict as an error. - Shipping that doesn't match checkout. The rate the feed (or account) implies is lower than what the shopper is actually charged at checkout. Google cross-checks and disapproves for a shipping mismatch, the same "feed must match the landing page" principle that governs price.
- Missing weight on weight-based rates. Account shipping is set to carrier-calculated by weight, but products ship without
shipping_weight, so Google can't compute a rate and the item can't serve correctly. - Tax attribute submitted outside the US. A UK or EU feed carrying a
taxattribute, often copied from a US template, doesn't belong there and confuses the pricing picture. - Free-shipping claims that aren't real. Marking
0shipping in the feed while the store still charges for delivery. Like promotional text in a title, an unhonoured shipping claim is a policy and trust problem.
The rule mirrors pricing exactly: what Google understands about shipping and tax must equal what the shopper is actually charged. Keep the account settings authoritative, and use feed overrides sparingly and deliberately: every override is one more place a contradiction can hide.
How this works in /tools
Shipping and tax are configured in your store and Merchant Center account, not set by enrichment, but the feed's shipping-related attributes are validated for the contradictions above: stray feed-level overrides, missing shipping_weight where rates need it, and tax attributes that don't belong in a UK/EU feed. Those consistency checks feed your Feed Health Score, and monitoring catches a shipping regression before it spreads. For the broader field-by-field picture, see the product data spec overview; for a live disapproval, see fixing disapproved products.
Frequently asked questions
Should I set shipping in the account or the feed?
Set your standard rates once at the account level in Merchant Center, which covers most of the catalogue and is easiest to maintain. Only add feed-level shipping for the products that are genuinely exceptions, like oversized or heavy items with different rates.
Do UK/EU merchants need the tax attribute?
No. The tax attribute is for US sales tax. In the UK and EU, VAT is included in the displayed price, so you don't submit a tax attribute; you just make sure price is the tax-inclusive amount shoppers pay.
Why is my product disapproved for a shipping mismatch?
Usually a feed-level shipping value contradicts the account settings, or the shipping cost the feed implies differs from what the checkout actually charges. Google cross-checks these, and a contradiction disapproves the item.