Shipping weight is the feed attribute that reports how much a shipped item weighs, submitted to Google Merchant Center as <g:shipping_weight> in the form of a number plus a unit — pound, ounce, gram, or kilogram. It exists specifically to support carrier-calculated shipping, where a channel asks a carrier's API for a live rate instead of using a flat table, and that calculation is only as accurate as the weight the feed reports.

Why Shipping Weight Matters

When a Merchant Center account is configured to use carrier-calculated rates, shipping_weight isn't a nice-to-have — it's the input the whole quote depends on, alongside origin address and destination. An item with no shipping_weight in that setup either falls back to a default that's rarely correct or fails to generate a rate at all, which shows up downstream as an inaccurate or missing shipping figure next to shipping on the listing. Because the value should reflect the packaged weight a carrier actually bills for, not just the product's net weight, a feed that pulls this field straight from a PIM's item-weight attribute without accounting for packaging tends to systematically understate cost — a discrepancy that eventually surfaces as a tax-and-shipping accuracy flag once real invoices are compared against what shoppers were quoted.

How Shipping Weight Works

The field accepts a decimal number followed by a unit abbreviation with a space between them — 2.5 kg, 12 oz, 40 lb — and Google rejects values submitted without a recognized unit or with a unit it doesn't support. It's optional unless the merchant's shipping settings use carrier-calculated or weight-based rate rules, in which case it becomes effectively required for accurate quotes on every affected item. Meta Catalog includes the same field for the same purpose, used within Commerce Manager's shipping cost configuration rather than displayed to shoppers directly. Because source systems often store weight in inconsistent units across product categories — grams for accessories, kilograms for furniture — this field is one of the more common candidates for normalization rules in a feed pipeline, converting everything to the single unit a merchant's shipping settings expect before submission.

Example

<item>
  <g:id>SKU-71144</g:id>
  <title>Ceramic Dutch Oven - 6 Quart, Sea Salt</title>
  <g:price>129.00 USD</g:price>
  <g:shipping_weight>4.8 kg</g:shipping_weight>
  <g:shipping>
    <g:country>US</g:country>
    <g:service>Standard</g:service>
    <g:price>9.95 USD</g:price>
  </g:shipping>
</item>

Related Concepts

Shipping_weight only matters in combination with shipping: one field states the physical fact, the other states or calculates what that fact costs a shopper, and an audit of one without the other misses half the picture. Because inaccurate weight data compounds into inaccurate landed cost — the same category of problem that makes an unaccounted-for tax rate look like a pricing error — feed teams tend to review both fields together rather than in isolation. Getting the unit conversion right at the source, through consistent normalization rules rather than manual fixes per category, is usually what keeps this field reliable as a catalog grows past a handful of product types.