Google's New Merchant Center Fields for Agentic Commerce

Google just changed what a product feed is for, and most catalogs are not ready for it. At Google Marketing Live in May 2026, Google rolled out six optional conversational attributes in Merchant Center: feed fields built so AI systems and shopping agents can understand your products the way a good salesperson would. This is the data layer underneath agentic commerce, where an assistant does the browsing, the comparing, and increasingly the buying on a shopper's behalf.

The fields are easy to describe and genuinely hard to fill at catalog scale, which is the whole point of this post. I will cover what the six attributes are, why they matter for agentic commerce, and then the part most write-ups skip: exactly how we enrich them across thousands of products using AI agents and our own Merchant Center connector. That second half is where the real work lives.

What actually changed in Merchant Center

Google added six conversational attributes to Merchant Center. They are optional, they do not affect your existing product approval status, and you submit them through a supplemental data source (Google's recommendation), your primary feed, or the Merchant API. Three of them had no home in a standard feed before, because feeds were never built to carry that kind of information. The job of all six is the same: give the AI shopping experiences in Search and Gemini enough structured detail to represent your product accurately, instead of guessing from a title and a price.

The six conversational attributes, in plain terms

• Question and answer: FAQ-style pairs that answer what a shopper actually asks before buying. Net new, and the highest-leverage field of the six, because it feeds conversational answers directly.
• Document link: URLs to product PDFs such as manuals, spec sheets, care guides, and ingredient lists. Net new.
• Related product: structured links to accessories, required parts, substitutes, variants, or bundles, so an agent can answer "what works with this?" or "is there a cheaper option?" Net new.
• Item group title: the product family name, kept separate from the SKU-level title.
• Variant option: structured variant detail like size, color, or material, expressed as name and value pairs.
• Popularity rank: how a product ranks for popularity inside your own catalog, given as a percentage.

The first three are the real unlock, because that information had nowhere to live in a standard feed. The other three sharpen data Google already had a way to read.

Why this is really about agentic commerce

In January 2026 Google introduced the Universal Commerce Protocol, an open standard for agentic commerce that spans the whole journey, from discovery and buying to post-purchase support. Google built it with retailers like Shopify, Etsy, Wayfair, Target, and Walmart, and designed it to work alongside the other agent standards (Agent2Agent, the Agent Payments Protocol, and Model Context Protocol).

The thread connecting the protocol and the new feed fields is simple: an agent can only recommend what it can read. When an assistant is comparing options for a shopper, the product with clear answers, linked documentation, and sensible related items is easy to represent and easy to trust. The one with a bare title gets skipped. Structured product data is the fuel for the whole experience, which is the same argument we make in our ecommerce SEO and AI search guide and the shift we covered in Google's move toward AI checkout.

The catch: the data exists, it is just not in your feed

In the feed work we do, the hard part is rarely the schema. It is that the answers already live somewhere else in the business. The questions a buyer asks are sitting in your support inbox and your help center. The spec sheet is a PDF on a product page the feed never points to. The customers-also-bought logic lives in your merchandising tool. The new attributes do not ask you to invent anything. They ask you to collect what your brand already knows and put it where a machine can use it.

Then comes the catch: scale. A mid-size catalog is thousands of SKUs, six attributes each, several of them structured with required sub-fields and strict formats. Filled by hand in a spreadsheet, that is a multi-month project that is stale the day it ships. This is exactly the kind of structured, high-volume, repetitive work AI agents are good at, as long as you give them the right tools and the right source data.

How we enrich feeds with AI agents

We built a Merchant Center enrichment connector, an MCP server that an AI agent operates directly. Instead of a person clicking through Merchant Center or hand-editing a feed file, an agent calls the connector to read the spec, write enrichment values, validate them, and publish. Here is the pipeline end to end.

1. The agent learns the exact spec before it writes anything

The connector exposes the full attribute catalog: every field, its structure, sub-attributes, format rules, and a worked example. The agent reads that first, so what it produces is valid feed data by construction instead of a guess it has to clean up. Related product is a good example, because it is not a free-text field. It needs a relationship type (accessory, required part, substitute, variant, or bundle), an identifier type (id or GTIN), and the identifier itself. The agent gets that contract up front and fills it correctly.

2. It grounds every value in your first-party data

This is the guardrail that matters most. The agent does not invent answers. We point it at the brand's own material: the questions support and sales actually field, the help center, product detail pages, spec sheets, and reviews for Q&A; the catalog and merchandising relationships for related products and bundles; sales data for popularity rank. Generation is grounded in real sources, so a Q&A answer reflects the actual product rather than a plausible-sounding guess. Anything it cannot ground in a source, it leaves empty.

3. It generates structured values, per product, at catalog scale

With the spec and the sources in hand, the agent writes the actual enrichment: question-and-answer pairs that match real buying questions, related-product links with the correct relationship type and identifiers, document links, variant options, and popularity rank. It does this per SKU and in bulk across the catalog, which is the only way this is tractable for a real store.

4. It validates and previews before anything goes live

Before publishing, the agent validates the enrichment against the spec and previews exactly what Google will pull, so format errors and missing required sub-fields surface up front rather than after a product gets disapproved. We keep a human in the loop here to spot-check tone and accuracy on a sample, because grounded does not mean unsupervised.

5. It publishes through a supplemental feed, not your primary one

The enriched data goes out as a supplemental data source. Your primary feed is untouched, and because these attributes are optional, none of this risks your existing product approval. If anything looks off, we roll the supplemental feed back without disturbing the products that are already live and selling.

6. It keeps the data fresh

Catalogs change, new questions come in, and bestsellers shift. The same pipeline re-runs on a schedule, so the enrichment stays current instead of decaying into the stale-spreadsheet problem that kills most feed projects.

A worked example: one product, enriched

To make it concrete, here is the shape of what the agent produces for a single product, a countertop dishwasher. The values are illustrative, but the structure is exactly what lands in the feed.

Multiply that by a few thousand SKUs and it is clear why this is an agent job rather than a spreadsheet job.

Why we run this with agents instead of by hand

• Scale: thousands of products times six structured fields is a volume problem, and an agent does not get bored or sloppy on row 4,000.
• Structure: the fields carry required sub-attributes and strict formats, and an agent that reads the spec first gets them right every time.
• Grounding: pointed at real sources, the output reflects your actual products, and anything it cannot source is left blank instead of fabricated.
• Freshness: a pipeline re-runs on a schedule; a spreadsheet rots.
• Safety: validation, feed preview, supplemental-feed isolation, and a human spot-check keep it from ever risking the live catalog.

This is the same approach we take to AI work in general: give a capable model the right tools and the right data, keep it grounded in sources, and put guardrails around the output. The conversational attributes happen to be a near-perfect fit for it.

The commerce side of answer engine optimization

If this feels familiar, it should. It is the same idea as answer engine optimization for your content: structure what you know so a machine can quote it accurately. The feed is now an answer surface, the same way your guides and FAQs are. A product page that is invisible to AI has the same root problem we described in why your website is not built for AI visibility, and the fix rhymes: make the underlying data explicit. For the broader playbook, our ecommerce SEO and AI search guide is the place to start.

What to do now

Because these fields are optional, most catalogs will not have them filled for a while, which is the opportunity. Eligibility for AI shopping surfaces is decided by the quality of your product data, not just whether a field is present, so brands that enrich well and early get a head start while everyone else waits. Start with your top sellers and the question-and-answer and related-product fields, since those carry the most weight in a conversation.

If you want this done right, it is the work our team does every day: we run the enrichment pipeline on your catalog, grounded in your own data, validated, and published without touching your live feed. Book a call and we will take a look at your products.