A field-by-field anatomy of a Google Shopping product feed

Most feed problems are not exotic. They are one of a dozen well-understood attributes being wrong in a quiet way. So here is the anatomy: the fields that matter in a Google Shopping feed, what each one is really for, and the trap that comes with it. Keep this next to your transformation and you will catch most issues before Merchant Center does.

The fields that get you rejected if they are wrong

idis the stable key for a variant. The gotcha: it must never change. Regenerate IDs on every export (because you keyed them off array position instead of the variant’s own identifier) and Google sees a churn of products appearing and disappearing, which hurts you.

title drives relevance. Front-load brand and product type; Google weights the early words. The trap is templated titles that read as keyword soup, which suppress rather than help. description is lower-weight but still indexed, so write for a human, not a crawler.

link and image_link are where silent failures hide. The link must resolve to a live, in-stock landing page with a price that matches the feed. The image must be clean, large enough, and badge-free. Both carry a URL only, so the feed looks fine even when the destination is broken.

price and availability must match the landing page at crawl time. A sale that updates the storefront instantly but the feed on the next push is the most common price mismatch there is. availabilityneeds an explicit policy for what “in stock” means across your inventory locations.

brand plus gtin or mpn are the identifier set. Validate the GTIN (length, numeric, valid check digit) instead of trusting the barcode field, and set identifier_exists to no for genuinely unbranded or custom products rather than leaving it ambiguous.

The fields that decide who sees the product

google_product_categoryplaces you in Google’s official taxonomy, and getting it wrong does not always reject the product, it just shows it to the wrong searches. product_type is your own free-text category and is great for structuring campaigns, so use both: the official one for Google, your own for your bid strategy.

condition (new, used, refurbished) is required and trivially easy to get wrong on resale inventory. item_group_id ties variants of the same product together; every color and size of one shirt should share it, with distinct color, size, and material attributes. Skip this and Google treats your variants as unrelated products, which fragments performance.

The fields people forget until a disapproval forces them

shipping and tax can be set in the feed or in account settings, and the two disagreeing is a real source of disapprovals. sale_price and sale_price_effective_date exist precisely so a promotion can be expressed in the feed instead of fought through a price mismatch. custom_label_0 through custom_label_4 carry nothing to Google but everything to your campaign segmentation; bestseller, margin tier, and season live here.

The meta-point

Notice the pattern: the dangerous fields are the ones that carry a reference (a URL, an identifier, a category) rather than a value. The feed can be perfectly formed and still point at a broken page, an invalid GTIN, or the wrong category. That is why validation has to check what the references resolve to, not just that the columns are present.

The plug

SnowPipe maps a Shopify (or other) catalog into exactly these fields with the validation built in: identifier checks, category mapping, variant grouping, and row-level tracking when a field still gets a product disapproved. It is at pipe.snowforge.dev if you would rather not hand-maintain the mapping.