Google Shopping XML Feed: Format & Example

The example below is a complete, valid Google Shopping XML feed containing one product in two size variants. It shows the envelope, the namespace, the seven required attributes, the identifier trio (brand + gtin), and the variant mechanics (item_group_id shared, size differing, unique id per variant):

<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:g="http://base.google.com/ns/1.0">
  <channel>
    <title>Example Store Product Feed</title>
    <link>https://www.example-store.com</link>
    <description>Product feed for Google Merchant Center</description>
    <item>
      <g:id>SKU-201-M</g:id>
      <g:title>Trailhead Merino Running Socks — Mens M</g:title>
      <g:description>Mid-weight merino running socks with seamless toe.</g:description>
      <g:link>https://www.example-store.com/socks/trailhead?size=m</g:link>
      <g:image_link>https://cdn.example-store.com/trailhead-socks.jpg</g:image_link>
      <g:price>18.00 EUR</g:price>
      <g:availability>in_stock</g:availability>
      <g:condition>new</g:condition>
      <g:brand>Trailhead</g:brand>
      <g:gtin>04012345678901</g:gtin>
      <g:item_group_id>SKU-201</g:item_group_id>
      <g:size>M</g:size>
      <g:google_product_category>188</g:google_product_category>
    </item>
    <item>
      <g:id>SKU-201-L</g:id>
      <g:title>Trailhead Merino Running Socks — Mens L</g:title>
      <g:description>Mid-weight merino running socks with seamless toe.</g:description>
      <g:link>https://www.example-store.com/socks/trailhead?size=l</g:link>
      <g:image_link>https://cdn.example-store.com/trailhead-socks.jpg</g:image_link>
      <g:price>18.00 EUR</g:price>
      <g:availability>in_stock</g:availability>
      <g:condition>new</g:condition>
      <g:brand>Trailhead</g:brand>
      <g:gtin>04012345678918</g:gtin>
      <g:item_group_id>SKU-201</g:item_group_id>
      <g:size>L</g:size>
      <g:google_product_category>188</g:google_product_category>
    </item>
  </channel>
</rss>

Keep the first six lines and the closing two exactly as they are — envelope, namespace, channel metadata. Repeat the <item> block once per product or variant, replacing every value. Three details preserve validity while you edit: store GTINs as text so leading zeros survive (a spreadsheet that coerces 04012345678901 to a number corrupts the check digit), keep the ISO 4217 currency code inside every price value, and remove any attribute you have no value for — Google’s checklist explicitly says to drop empty attributes rather than ship empty tags.

Google also publishes a downloadable RSS 2.0 example file in its help center if you want a second reference point; the structure is identical.

Products with a manufacturer-assigned GTIN should submit it in g:gtin together with g:brand. Where no GTIN exists but a manufacturer part number does, g:mpn plus g:brand is the fallback pair. Google cross-checks GTINs structurally (length and GS1 check digit) at ingestion, and a wrong check digit disapproves the item — which is why the digit deserves validation before upload, not after.

Handmade, vintage, and private-label products with no GTIN or MPN declare <g:identifier_exists>false</g:identifier_exists>, which exempts the item from identifier requirements. Use it truthfully: setting it on a product that demonstrably has a GTIN in GS1’s registry is itself a disapproval reason. The full decision tree — which identifier to send when, and what happens when you get it wrong — is covered in the Merchant Center disapprovals guide.

The single most common hand-built-feed failure is an unescaped ampersand. A title like Socks & Gloves Set must be written Socks & Gloves Set in raw XML — a bare & makes the entire file malformed, and Merchant Center rejects it at fetch time, not row by row. The same applies to < in any value. URLs with query strings (?size=m&color=blue) are the classic carrier: every & in every URL needs escaping. If your generator emits through a real XML library rather than string concatenation, this class of bug disappears entirely.

Beyond well-formedness, four value patterns cause quiet failures: availability spelled outside the four supported values ("available", "yes", "In Stock" with capitals); prices missing the currency code (18.00 instead of 18.00 EUR); GTINs that lost their leading zeros to a spreadsheet export; and attributes without the g: prefix, which Google ignores wholesale rather than erroring. The last one is the cruellest — the feed fetches green, and the products just lack the data you thought you sent.

Google’s pre-submission checklist adds two mechanical rules: the filename must end in .xml and must exactly match the name registered for the data source in Merchant Center, and attributes with no value should be removed from the file rather than shipped as empty tags. Empty tags are not neutral — an empty <g:gtin></g:gtin> is an invalid identifier, not a missing one.

In Merchant Center, add the file as a primary data source. Three transport options exist for a file feed: scheduled fetch (Google pulls a URL you host on a cadence you set — the standard choice, because updates need no manual step), direct upload through the UI, and SFTP push. Register the exact filename, set the fetch schedule to at least daily, and Google fetches, parses, and begins processing items into review.

The first fetch’s processing report is where format errors surface: parse failures, missing required attributes, and invalid values are listed per item with counts. Treat this report as the source of truth for what Google actually ingested — not your generator’s logs. Items that clear processing then enter review, where policy checks run; item-level rejections from that stage are disapprovals, a different failure class with its own diagnostic workflow.

A hand-maintained XML file is a perfectly good solution for a small, stable catalog — a dozen SKUs whose prices change quarterly need nothing more than this guide and a text editor. The crossover comes from change frequency, not catalog size alone: every price change, stock-out, and new variant is a manual edit, and every manual edit is an escaping bug waiting to happen. When updates outpace your willingness to edit XML carefully, generation should move to software — whether that is your e-commerce platform’s export, a script, or a feed management tool that emits Merchant Center-compliant XML continuously from your catalog. The discipline around that switch — one canonical catalog in, validated channel-shaped feeds out — is feed management.

Generation is the smaller half of what tooling buys. The larger half is the loop around it: pre-export validation against the same rules Google enforces, automatic truncation and category mapping, disapproval monitoring after upload, and bulk fixes when Google reports issues across hundreds of products. That loop — validate, ship, monitor, fix — is what the broader practice of product feed optimization builds on top of a structurally correct feed. One side benefit compounds across channels: because Criteo accepts Google's product taxonomy, the google_product_category mapping you get right for Merchant Center is reused as-is for Criteo feed management — one mapping, two channels.