The XML feed for Google Shopping in AI Mode: what it is and how to prepare it

A Google Shopping XML feed is an RSS 2.0 file in which every product in your catalog is described as an <item> with standardised attributes — identifier, title, price, availability, GTIN, image — inside Google’s namespace. It is how you tell Google what you sell, at what price and under what conditions, without making it infer all of that by crawling your store.

With AI Mode the file format has not changed, but its job has. It used to feed a system that matched short queries against product listings. It now feeds the Shopping Graph, the product database Google grounds its generative answers in: comparisons, recommendations, review summaries and, increasingly, checkout itself. The query is no longer “trail running shoes size 10”. It is “I need trail shoes for wet ground, I have a weak ankle, and I want to stay under £120”.

The practical consequence is uncomfortable: a feed with 100% of its products approved in Merchant Center can be, at the same time, a poor feed for AI Mode. Approved means “you do not violate policy”. Appearing in a generative answer means “you carry enough structured information for the model to reason about your product”. Those are different bars — and since January 2026 Google has been publishing new attributes, the so-called conversational attributes, precisely to close that gap.

What a Google Shopping XML feed actually is

Technically it is an RSS 2.0 document (Atom 1.0 is also accepted) that declares the http://base.google.com/ns/1.0 namespace. Every attribute belonging to that namespace must carry the g: prefix; without the prefix Google ignores the tag and everything inside it, with no obvious warning.

The minimum structure looks like this:

<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:g="http://base.google.com/ns/1.0">
  <channel>
    <title>My store</title>
    <link>https://www.mystore.com</link>
    <description>Product catalog</description>

    <item>
      <g:id>SKU-4471</g:id>
      <g:title>Terra GTX trail shoe men - Blue - 44</g:title>
      <g:description>Trail running shoe with a waterproof membrane…</g:description>
      <g:link>https://www.mystore.com/terra-gtx-blue-44</g:link>
      <g:image_link>https://cdn.mystore.com/terra-gtx-blue.jpg</g:image_link>
      <g:availability>in_stock</g:availability>
      <g:price>129.95 EUR</g:price>
      <g:brand>Terra</g:brand>
      <g:gtin>8412345678905</g:gtin>
      <g:condition>new</g:condition>
      <g:item_group_id>TERRA-GTX-M</g:item_group_id>
    </item>

  </channel>
</rss>

That block is the “classic feed”: identification, offer, variant grouping. It is what the vast majority of feed plugins and modules generate by default — ours included. And today it is not enough.

Identifiers are not paperwork

g:id is your primary key: it must be stable over time and unique within the account. g:gtin is the key you share with the rest of the world. When the GTIN is missing, Google loses the ability to reconcile your product with the same product sold by others — and that reconciliation is exactly what makes a comparison possible in AI Mode. A product that cannot be compared is harder to surface in an answer whose natural shape is a comparison.

If you sell own-brand products with no GTIN, set g:identifier_exists to no and make sure you send g:brand and g:mpn. What does not work is leaving the field empty and hoping it resolves itself.

XML, TSV or Content API: when to use which

The choice matters more than it used to, because several of the new attributes are repeatable and carry sub-attributes. XML nests them without ambiguity. In CSV you have to escape commas and colons — and according to the feed specialists who documented these attributes, that is the most frequent formatting mistake: a product_highlight reading “titanium case, and a green nylon band” becomes two highlights, the second one a meaningless fragment.

What actually changes with AI Mode

Google describes AI Mode as a conversational experience, and that has two measurable effects on your feed.

The first is query length and specificity. Per figures Google itself has shared, AI Mode queries are on average about three times longer than traditional search queries. A long query carries constraints — material, use case, compatibility, budget, context — that a product title alone cannot satisfy. The system needs fields where those constraints are written down explicitly.

The second is the intermediary. Your feed never reaches the model: it reaches the Shopping Graph, and the Shopping Graph answers. Google puts that graph at more than 60 billion product listings, with roughly 2 billion updated every hour. A product with thin data does not disappear from the graph; it simply becomes harder to represent accurately when the model builds an answer. The penalty is not exclusion, it is silent degradation.

Getting approved in Merchant Center and being useful to AI Mode are two different bars. The first is cleared with correct data. The second, with complete data.

One honest caveat is worth adding: the visibility impact of these attributes is not publicly quantified by Google. What is documented is which attributes it built explicitly for conversational surfaces, and several of them carry a literal note in the Merchant Center documentation: “This attribute is primarily intended for use in conversational experiences such as AI Mode in Google Search.” That sentence is the most reliable signal available.

The eight conversational attributes

These are the attributes Google has explicitly tied to AI surfaces. All of them are optional, and all of them travel through the same feed.

How they look in XML

This is where XML wins. Group attributes nest; repeatable ones repeat as sibling tags:

<!-- Benefits: one per tag, never concatenated -->
<g:product_highlight>Waterproof membrane with sealed seams</g:product_highlight>
<g:product_highlight>5 mm lugs for mud and wet rock</g:product_highlight>
<g:product_highlight>Ankle reinforcement for unstable footing</g:product_highlight>

<!-- Specifications grouped into named sections -->
<g:product_detail>
  <g:section_name>Materials</g:section_name>
  <g:attribute_name>Membrane</g:attribute_name>
  <g:attribute_value>GORE-TEX</g:attribute_value>
</g:product_detail>
<g:product_detail>
  <g:section_name>Outsole</g:section_name>
  <g:attribute_name>Lug height</g:attribute_name>
  <g:attribute_value>5 mm</g:attribute_value>
</g:product_detail>

<!-- A variant dimension outside the standard six -->
<g:item_group_id>TERRA-GTX-M</g:item_group_id>
<g:item_group_title>Terra GTX trail shoe men</g:item_group_title>
<g:variant_option>
  <g:name>drop</g:name>
  <g:value>8 mm</g:value>
</g:variant_option>

<!-- Relationships: one tag each, never comma-separated -->
<g:related_product>
  <g:relationship_type>accessory</g:relationship_type>
  <g:identifier_type>gtin</g:identifier_type>
  <g:identifier>8412345671234</g:identifier>
</g:related_product>
<g:related_product>
  <g:relationship_type>substitute</g:relationship_type>
  <g:identifier_type>id</g:identifier_type>
  <g:identifier>SKU-4472</g:identifier>
</g:related_product>

<!-- Q&A: answer what does not fit in the description -->
<g:question_and_answer>
  <g:question>Does it work on packed snow?</g:question>
  <g:answer>The membrane keeps water out, but the outsole is not designed for ice. For packed snow we recommend lightweight crampons.</g:answer>
</g:question_and_answer>

<!-- Public, crawlable documentation, no login -->
<g:document_link>https://cdn.mystore.com/docs/terra-gtx-size-guide.pdf</g:document_link>

<!-- A real sales ranking within your catalog -->
<g:popularity_rank>95.5</g:popularity_rank>

Three details that save you from rewriting the feed twice:

• Do not duplicate. Google is explicit: if a fact already lives in title, description, product_detail or product_highlight, do not repeat it in question_and_answer. And if you submitted a document_link containing that information, Google extracts it from the PDF and the matching product_detail entry becomes redundant.
• item_group_title is not the product title. The variant title is “Terra GTX trail shoe men blue 44”. The item_group_title is “Terra GTX trail shoe men” — no size, no colour, nothing that identifies a specific variant. It must be identical across every variant in the group and different from the individual title.
• popularity_rank has to be true. Google asks for a ranking that reflects actual sales. With no scoring system in place, a reasonable starting point is 90–100 for your ten best sellers, 50–80 for the mid range and below 50 for slow-moving stock, refined later with real data. What you must not do is give the whole catalog a 100: that is noise, and it contradicts the definition of the field.

document_link: the attribute almost nobody has

It deserves its own section because it changes the conversation the most and is used the least.

You submit the URL of a public PDF about the product: manual, assembly instructions, size guide, technical sheet, package insert. Google crawls that document and uses its content to answer detailed questions inside AI Mode. In other words: upload the assembly PDF and Google can answer “how long does it take to assemble?” from your documentation instead of from a forum thread.

The requirements are strict and rule out a fair number of rushed implementations:

• https URL, ASCII characters only, RFC 3986 compliant, up to 2,000 characters.
• PDF format, 50 MB maximum, up to five documents per product.
• Googlebot must be able to crawl it: no login, no robots.txt block.
• The URL must be stable — do not reuse the same path for a different document later.
• The document must be about the product, not about the company.

If your store keeps manuals behind a protected folder or serves them after a lead-capture form, this attribute will not work as currently set up.

Feed and structured data: not one or the other

The recurring question: if my product page already has Schema.org Product markup, why the feed?

Because they do different jobs. On-page markup is what Google finds when crawling, and it serves to verify and cross-check. The feed is what you declare explicitly, completely, and can update without waiting for a crawl. And some attributes — popularity_rank, document_link, related_product — simply have no equivalent on the page.

The practical rule is simple: the two must say the same thing. Google explicitly requires that the product details shown on the landing page match the values submitted through variant_option. A mismatch between feed price and page price is not a nuance; it is the most common reason for disapproval in Merchant Center.

Freshness carries more weight now

In classic Shopping, an overnight feed was acceptable: the shopper saw a listing, clicked, and checked the real price on your site. In a generative answer the shopper may never make that click. If the assistant states the product is available at €129.95 and it is not, the error is consumed as-is.

That is why the sensible 2026 architecture runs at two speeds:

1. A complete primary feed, with full descriptions and conversational attributes, once a day.
2. Incremental updates to price and availability as close to real time as you can manage, through supplemental feeds or the Content API.

If your feed generator takes twenty minutes to walk the catalog, that is the first bottleneck to fix: cache, paginate and regenerate in batches instead of rebuilding the whole file on every request.

Errors that break a feed silently

The ones we see over and over in real catalogs:

• Unescaped commas and colons in CSV. They split highlights and Q&A answers. Fix: TSV, double quotes, or a backslash in Google Sheets.
• Unstable identifiers. A g:id that changes when the feed is regenerated destroys the product’s history and its reconciliation in the graph.
• Variants with no item_group_id. Every size competes as a separate product, and the assistant cannot say “available from 6 to 12”.
• Several related products in one field. related_product does not accept comma-separated lists: each relationship gets its own tag with its three sub-attributes.
• A non-crawlable PDF. A document_link blocked in robots.txt is an attribute you submit and nobody ever reads.
• Locale-formatted prices. 129,95 EUR with a decimal comma fails; use a dot and an ISO 4217 currency code.

How to measure whether any of this works

Until 2026 there was no way to know whether you appeared in AI answers. At Google Marketing Live 2026, on May 20, Google announced AI Performance Insights in Merchant Center, and on May 27 it detailed the report: brand share of voice across AI surfaces (AI Mode, AI Overviews and the Gemini app), performance broken down by funnel stage — discovery, evaluation and purchase — the product terms shoppers use, and feed attribute completeness.

That last block is what makes everything above actionable: it tells you which structured attributes you are missing. At the time of writing, the rollout was announced for the United States, Canada, Australia, India and New Zealand, starting as a pilot on a limited number of US accounts. If you operate elsewhere, prepare the feed now and measure with what you have — Search Console, AI visibility tooling, and AI Mode answers themselves — until the report reaches you.

Beyond the feed: UCP and checkout inside the conversation

The feed solves discovery. The transaction is a separate layer, and it is the one Google is building with the Universal Commerce Protocol (UCP).

At Google Marketing Live 2026 the company announced the expansion of UCP with Universal Cart — a cart shared across retailers, paid through Google Pay or the retailer’s own checkout — and its integration into AI Mode, Demand Gen, Direct Offers and Shopping ads on YouTube, plus an extension into hotels and food delivery. The rollout started in the United States, with Canada and Australia next and the UK later.

For a store that means there are two surfaces to prepare, not one: the data (the feed, with its conversational attributes) and the capabilities (endpoints an agent can query to check availability, calculate shipping, validate a coupon and complete a purchase). That is exactly the split AI Merchant Pro implements: it generates the AI-ready product feed for WooCommerce and PrestaShop on one side, and exposes UCP endpoints so an agent can operate against the store on the other.

Implementation checklist

1. Confirm the feed declares xmlns:g="http://base.google.com/ns/1.0" and that every Google-namespace tag carries the g: prefix.
2. Audit identifiers: stable and unique g:id, g:gtin present whenever one exists, and identifier_exists set to no only when it genuinely does not.
3. Group variants with item_group_id and add a generic item_group_title, different from the individual title.
4. Add 4 to 6 product_highlight entries per product, focused on benefits rather than specifications.
5. Turn your specification table into product_detail entries with named sections.
6. Publish manuals and size guides as public PDFs and link them through document_link.
7. Move the 3–5 questions your support team answers most into question_and_answer.
8. Declare real relationships with related_product: accessories, spare parts, substitutes.
9. Compute popularity_rank from actual sales and refresh it periodically.
10. Decouple price and stock updates from the full feed cycle.
11. Check that the landing page says exactly what the feed says.

None of the eleven points requires a migration. They are fields added to the same file you already generate. The difference between a catalog an assistant can recommend and one it can only list sits, almost always, in the first seven or eight.