Google Merchant Center Conversational Attributes: The 6 Fields for AI Mode

Google Merchant Center conversational attributes are six optional fields, launched at Google Marketing Live in May 2026. They help AI Mode, Gemini, and Business Agent understand a product in natural language: FAQs, parts and accessories, PDF manuals, variant families, variant axes, and internal popularity.

They do not replace the Google Merchant Center feed. They do not disapprove a SKU. Google is explicit: submitting them has no impact on the approval status of existing offers. They are also not a documented Shopping ranking lever. They are a layer of facts, read mainly by AI systems, to answer, compare, and recommend.

Timing matters for a European retailer. UCP checkout / Universal Cart remains largely US-first. These six fields, by contrast, are already global. This is the Merchant Center lever you can pull now, before the agentic purchase journey lands in your market.

Why the classic feed is no longer enough

The feed was built to match a title to a short query. AI Mode answers something else: a buying question, with constraints and follow-ups (“a breathable running jacket for rain, size 42, and the filter that goes with it”). A title and a one-line description cannot carry that material.

Google first announced this in January 2026 at NRF, among the Merchant Center guidelines for agentic commerce. In May, at Google Marketing Live, the spec became concrete: six attributes, documented in Merchant Center Help, available in all countries.

The January teaser mentioned “dozens” of attributes. Only six are documented and submittable. Work from the current spec, not a roadmap.

Three fields did not exist in the standard feed, because the format was never built for them:

• question_and_answer
• related_product
• document_link

The other three refine concepts already in the spec (item_group_id, color, size): item_group_title, variant_option, popularity_rank.

Google’s mapping rule: if the information is already in description, product_highlight, or product_detail, do not duplicate it in conversational attributes.

This layer sits on top of the foundation. It will not rescue a catalog designed only for Shopping ads. Title, GTIN, site-aligned price, stock, images: without those, the AI has nothing solid to cite.

The 6 attributes, one by one

1. question_and_answer — FAQ attached to the SKU

This is the most useful field to fill first. It serves questions a shopper actually asks, not a list of keywords.

Official limits (question_and_answer spec):

• up to 30 pairs per product
• 1,000 characters per question, 1,000 per answer
• 10,000 characters total for the product
• available in all countries

Google forbids: prices, dates, promotions, lead times, company name, lists of search terms. It asks for factual, grammatically correct answers, and a variety of questions (specs, ingredients, package contents, use, care), not five rewrites of the same benefit.

Often missed: do not submit Q&A if the same content is already in document_link. Google says it will extract FAQs from the PDFs. Both fields in parallel, on the same material, is noise.

TSV format (one pair):

"Is it dishwasher safe?":"Yes, delicate cycle at 40 °C, no tumble dry."

Home-appliance example, in the spirit of Google’s documentation:

What are the temperature settings? Five settings: 80 °C (green tea), 92 °C (oolong), 93 °C (French press), 100 °C (boil).

What is the capacity? 1.7 litres, with a visible water gauge.

How long does keep-warm hold the temperature? Up to 15 minutes at the selected temperature.

On a catalogue of several thousand SKUs, these pairs are not written by hand. They are generated from the product page, specs, and PDPs, then pushed in a supplemental feed. That is the kind of processing Feed Enrich orchestrates, without touching price or availability on the primary feed.

2. document_link — crawlable PDFs

URL(s) to product documentation as PDF: manual, user guide, assembly instructions, package insert, tech sheet, INCI list. Google uses them to answer questions too long for a description.

Limits (document_link spec):

• up to 5 PDFs per product, 50 MB each
• http:// or https:// URL, ASCII characters, RFC 3986
• the file must actually be a PDF
• public: Googlebot without login, no robots.txt block
• the merchant must hold marketing-use rights
• stable URL that does not expire

This is not a brand brochure or a corporate catalogue. The document must be about the product (optionally a small family of related products).

Multiple URLs, comma-separated:

https://example.com/manual.pdf, https://example.com/assembly.pdf

URL-encode commas (%2C). A PDF behind a customer login or a CDN that blocks bots is useless. Same reflex as with Merchant Center errors on images: the file has to be actually crawlable, not just “in the PIM”.

3. related_product — typed catalogue relationships

This is not “you may also like” merchandising. Six relationship types, each with an identifier (feed id or gtin). Max 30 relationships per product. All three sub-attributes are required: relationship_type, identifier_type, identifier.

part_of_set — same series / same range. Example: a chair from a table-and-chairs set.

required_part — required for the product to work. Example: a coffee-machine filter, a lamp battery.

often_bought_with — frequently purchased together. Example: a case with a phone.

substitute — a comparable alternative. Example: another printer model, same use.

different_brand — the same product under another brand. Example: a private-label equivalent.

accessory — optional accessory. Example: a webcam for a desktop.

TSV format (related_product spec):

required_part:id:AZ7A,required_part:id:AZ7B,accessory:gtin:811571013579

One entry per related product. Do not list multiple IDs in the identifier sub-attribute. Allowed characters in the identifier: alphanumeric, _ and - only (no comma, :, quotes, backslash).

This is the field that lets an agent reason in bundles, spare parts, or substitutes, instead of attaching a random accessory.

4. item_group_title — family name

title remains the SKU name (Men's organic cotton T-shirt black M). item_group_title is the parent name (Men's organic cotton T-shirt). Max 150 characters. The same value for every variant that shares an item_group_id.

In France (and for variants in Shopping and free listings in other markets including the US and UK), item_group_id is already required for variants. item_group_title completes that grouping for AI: present the family first, then drill into the requested variant.

Without that group title, an agent sees N neighbouring SKUs, not one product in variants.

5. variant_option — axes that distinguish the variant

name + value group (250 characters each, up to 30 pairs, 5,000 characters total). Use it with item_group_id and item_group_title.

display:XL,memory:512GB,color:moonstone

Consistency rule: every variant in a group must share the same axes (name). Each variant is distinguished by a unique combination of value. Do not submit variant_option if the product is not a variant.

Google still recommends sending color, size, material, pattern, gender, and age_group when those fields identify the variant: the classic attributes also apply to non-variant products; variant_option tells the AI which axes actually make the size/colour grid.

This is the field that answers “the same jacket, in 42, navy”.

6. popularity_rank — internal percentile, not a rating

Float from 0 to 100, decimal with a period (.). Example: 95.5.

This is your popularity ranking across your inventory (sales, volume, store performance), not a Trustpilot score, not a Google rank. The higher the number, the better the product performs versus the rest of the catalogue.

Google uses it for queries such as “your best-selling running shoes”. A 12.3 is not an error: it is a long-tail item. An honest, regularly recalculated percentile beats a 99 on every SKU.

How to submit them

Three paths, per Google:

1. Supplemental feed (recommended): conversational columns only, join on id / offer_id. The primary feed (price, stock, Shopping title) does not move.
2. Primary feed: possible, but you mix transactional data and the AI layer.
3. Merchant API: questionsAndAnswers, documentLinks, relatedProducts, variantOptions, itemGroupTitle, popularityRank. Client libraries were not yet up to date at rollout; the documented workaround is custom attributes until the SDKs catch up.

Prefer TSV over CSV: Q&A and relationships are full of commas and colons. In Google Sheets, escape , : \ in sub-attribute values. You can also split question_and_answer or related_product into several columns with the same header.

A malformed value on this layer does not disapprove the Shopping SKU. That does not mean Google will read anything: an unreachable PDF URL, a related_product identifier missing from the feed, or inconsistent variant axes in a group, and the field is simply unused.

Where to start (without treating 50,000 SKUs)

The foundation remains the classic feed. Conversational attributes do not offset an empty title or a wrong GTIN. Same conclusion as in what changed in the product feed in 2026: Performance Max, Meta, and agents read the same catalogue. The conversational layer is additive; it does not replace the rest.

A realistic order of work:

1. Segment the top 5–10% of the catalogue (Shopping traffic, margin, or internal best-sellers). That is also the basis for a credible popularity_rank.
2. question_and_answer on that segment, from FAQs already on PDPs, support, and specs. No slogans.
3. related_product where merchandising already exists (accessories, parts, cross-sell). Type the relationship; do not dump everything into often_bought_with.
4. document_link on electronics, flat-pack furniture, DIY, regulated beauty: the PDFs often exist, they are just not in the feed.
5. item_group_title + variant_option on fashion and electronics, where the variant grid is already a Merchant Center topic.
6. popularity_rank last, calculated (sales, orders, or an internal proxy), not typed SKU by SKU.

A feed audit is still the right entry point: completeness of the foundation, then whether the conversational layer is feasible on the segment that is worth it. Operational detail (titles, classic attributes, AEO prep) is also in the complete product feed optimisation guide.

FAQ

Are conversational attributes required? No. Optional, complementary, with no effect on approval of products already in Merchant Center.

Do they improve Shopping ranking? Google does not document that. Stated use: AI surfaces (AI Mode, and conversational experiences more broadly), plus a complement to classic search. Treating this as a Performance Max boost would be speculation.

Should they go in the primary feed? Possible, not desirable. A supplemental feed limits operational risk and keeps offer data separate from understanding data.

Can we fill Q&A and also send the PDF? Yes, if the content is distinct. If the FAQ is already in the PDF, Google asks you not to resubmit question_and_answer.

Is agentic checkout (UCP) related? Related in Google’s strategy, not in the same deliverable. UCP handles the purchase journey on AI surfaces. Conversational attributes handle product understanding. In Europe you can (and should) fill the latter without waiting for the former.

Which field first if we only do one? question_and_answer on the top of the catalogue. It is closest to real questions, and often the easiest to source (PDPs, support, manuals).