How to Use Merchant Center Attributes for AI Shopping

Your product page may answer every obvious buying question and still leave your products poorly represented in an AI shopping conversation. The missing information often sits outside the core feed: compatibility answers, instructions, variant relationships, required accessories, substitutes, and evidence of which products shoppers prefer.

You can close that gap with six Google Merchant Center conversational attributes. The goal is not to repeat your product page. It is to give AI shopping systems structured, product-specific facts they can use when a shopper asks a nuanced question in AI Mode, Gemini, or another conversational experience.

Treat the feed as a decision map, not a second product page

A conventional product feed is good at identifying an item and describing its commercial state. Conversational shopping introduces a different set of questions: Will it work for my situation? What else do I need? How does this option differ from the other variants? Is there a manual? What could I buy instead?

Merchant Center’s six conversational attributes add machine-readable answers for those decisions. They cover questions and answers, product documents, related products, product-family titles, variant options, and relative popularity.

That distinction should shape your implementation. Do not treat the new fields as six more places to paste a marketing description. Give each field a specific job in the buying journey:

• Discovery: help the system connect a product to a use case, requirement, or natural-language question.
• Evaluation: expose documentation, alternatives, meaningful variants, and product-specific answers.
• Purchase preparation: identify required parts, accessories, sets, and products commonly bought together.
• Selection: provide a current internal popularity signal without presenting it as an external rating or percentage.

Begin your feed audit with the questions shoppers ask before buying, not with a list of empty attributes. For each important product family, write down the compatibility questions, setup concerns, variant choices, required components, likely alternatives, and relevant documents. You can then put each fact in the field built to carry it.

Give each conversational attribute one clear job

Use question_and_answer for product-specific uncertainty

The question_and_answer attribute consists of question and answer subattributes. You can submit as many as 30 pairs for one product, and each question and answer can contain up to 1,000 characters.

Existing product FAQs, manuals, merchant support records, and manufacturer materials are useful starting points. They are not ready-made feed content by default. Select only the questions whose answers are accurate for the individual product.

A good answer starts with the direct resolution and then adds the condition that could change it. If compatibility depends on a model, dimension, material, included component, or installation method, state that dependency. A vague answer such as “works with most systems” gives an AI assistant little dependable information. A product-specific answer that names the supported condition is much more useful.

Do not aim for 30 entries simply because the limit allows it. Five precise answers can cover more real buying intent than 30 variations of the same general question. Use separate pairs when the questions lead to genuinely different decisions.

Use document_link when the detail belongs in a PDF

The document_link attribute can attach as many as five relevant PDF documents to a product. Suitable documents include user guides, assembly instructions, training manuals, and package inserts. Each link must begin with http:// or https://, and the URL has a 2,000-character limit.

Choose documents by the decisions they resolve. An assembly guide may answer questions about tools and setup. A user manual may clarify operation, maintenance, or controls. A packing insert may explain what is included. Before submission, open every link and confirm that it resolves to the intended PDF rather than a general support page, login screen, obsolete version, or unrelated product family.

Do not force manual-sized detail into a question-and-answer field. Use the concise answer for the immediate decision and the document link for the deeper operating or setup information.

Use related_product to state the relationship, not just the recommendation

The related_product attribute supports several meanings: an item can be part of a set, a required part, often bought with the main item, a substitute, an alternative from a different brand, or an accessory. That meaning matters. A required component should not be represented as though it were merely an optional add-on.

Every related-product entry needs three subattributes:

• relationship_type describes how the two products are connected.
• identifier_type specifies whether the related item is identified by GTIN or ID.
• identifier supplies the corresponding GTIN or product ID.

You can add up to 30 related products to one line item. Use that capacity selectively. Verify that each identifier resolves to the intended item and that the relationship remains valid. A stale required-part relationship is more harmful than an omitted optional accessory because it can misstate what the shopper needs to complete the purchase.

Use item_group_title and variant_option as a pair

The item_group_title names the product family shared by its variants. It works with item_group_id, accepts 1 to 150 characters, and should exclude details that identify an individual variant. For example, a family-level title would name the shoe model, while color and size belong at the variant level.

Keep the title succinct, put the most meaningful family-level details first, and include only information that applies to every item in the group. Relevant search language can belong in the title, but only when it truthfully describes the whole family. Adding a color, size, material, or other detail that applies to only some members makes the grouping internally inconsistent.

The variant_option attribute then describes the structured choices through name and value subattributes. Typical option names include color, size, and material. Use the same name for the same concept throughout the catalog. If one family uses “color,” another uses “colour,” and a third uses “finish” for the same distinction, you have created three vocabularies for one shopper decision.

This attribute is available only for eligible products and is used with item_group_id and item_group_title. Submit the same variant-identifying attributes consistently across every member of a group. Otherwise, the family title may be correct while the individual options remain difficult to interpret.

Use popularity_rank as a relative internal signal

The popularity_rank attribute accepts a numerical text value from 0 to 100. A higher number means that the product is more popular relative to the rest of your catalog. It is not a percentage, so do not append a percent sign.

Base the ranking on recent sales and update it when your leading products change. The practical requirement is consistency: decide how current sales translate into a relative rank, apply that method across the in-scope catalog, and rerun it on a defined schedule or after a meaningful sales shift. Do not turn the field into a manual merchandising score unless that score genuinely represents relative product popularity.

Launch through a supplemental feed in a controlled order

You do not need to rewrite the primary product feed to begin. Google recommends adding conversational attributes through a supplemental data feed, which keeps the new information separate and makes it easier to update without disturbing established product data.

A controlled rollout also makes errors easier to isolate. Use this sequence:

1. Select a bounded product set. Start with one coherent family or category where you already have reliable FAQs, documentation, variant data, and relationship information. A narrow launch exposes naming and ownership problems before they spread across the catalog.
2. Inventory the existing facts. Record which products have current PDFs, verified compatibility answers, complete variant groupings, valid related-product identifiers, and enough recent sales information for a relative popularity rank.
3. Create a field-level source map. Assign each fact to one conversational attribute. Do not put required accessories into free-text answers when they can be represented as related products, and do not paste manual-length explanations where a document link belongs.
4. Normalize names before adding volume. Choose one catalog-wide vocabulary for variant option names and relationship handling. Correcting “size,” “dimensions,” and “format” after a broad launch is harder than deciding which term means what at the start.
5. Populate the deterministic fields first. Product-family titles, variant options, document URLs, and related identifiers can be checked directly. Add question-and-answer content next, then calculate popularity ranks with one consistent method.
6. Validate every hard constraint. Check character limits, entry counts, PDF URL schemes, mandatory subattributes, identifier types, group membership, and the 0-to-100 popularity range before submission.
7. Publish as supplemental data. Match the added attributes to the same products already represented in Merchant Center, then review processing results before expanding the rollout.
8. Assign update triggers. Recheck the supplemental data when a manual changes, a product relationship ends, a new variant launches, a product family is renamed, or recent sales alter the popularity order.

This order separates schema work from editorial work. It also prevents a common failure: polishing natural-language answers while the identifiers, product groups, and option names underneath them are still inconsistent.

Use catalog rules that keep the data dependable

Conversational fields invite more natural language, but they still belong to a structured catalog. Their value depends on repeatable rules. Write those rules before multiple teams or suppliers start filling the fields.

• Make every answer atomic. One question should resolve one main concern. Split compatibility, installation, and care into separate entries when each leads to a different decision.
• Lead with the answer. State yes, no, included, required, compatible, or not compatible before adding conditions and explanation.
• Carry qualifiers with the claim. If an answer changes by model, variant, material, configuration, or use case, name that condition in the same answer.
• Keep facts aligned. A variant value, included component, or compatibility claim should not conflict with the product page, manual, or other submitted product data.
• Control option vocabulary. Maintain an approved list of variant names and values so spelling, capitalization, and meaning stay consistent across families.
• Verify identifiers, not just labels. A related-product name may look correct while its GTIN or ID points to the wrong SKU.
• Retire obsolete documents. Replace a PDF link when the linked instructions no longer apply to the submitted product.
• Separate popularity from promotion. A product you want to sell is not necessarily a product that recent sales show to be relatively popular.

Keyword stuffing is especially counterproductive here. The item-group title can include terms you want the family to be found for, but those terms still need to describe the entire group. Questions should sound like real customer questions, and answers should resolve them. Repetition does not create a new fact for the system to use.

Ownership matters as much as formatting. Merchandising may own product relationships, support may own common questions, product teams may own manuals, and analytics may own popularity calculations. Give each attribute an accountable owner and a reason to revisit it. Otherwise, the feed will preserve yesterday’s answer long after the catalog has changed.

Measure query gaps by shopping stage, then revise the feed

Eligible merchants can use Merchant Center’s AI performance insights report to examine product and brand performance in conversational shopping queries across AI Mode and AI Overviews. The report includes share of voice, visibility across discovery, evaluation, and ready-to-buy stages, plus popular product attributes and search terms used in AI queries.

Use those signals to form testable feed hypotheses rather than treating every visibility change as proof that one attribute caused it:

• A recurring search term is absent from your structured product data: determine whether it describes a verifiable product fact. If it does, add that fact to the correct attribute rather than inserting the phrase indiscriminately.
• Discovery visibility is stronger than evaluation visibility: inspect whether shoppers can find specific answers, documents, meaningful variant choices, and credible alternatives after the initial match.
• Evaluation visibility is stronger than ready-to-buy visibility: check required parts, accessories, sets, and often-bought-with relationships for missing or stale entries.
• One variant appears while sibling variants remain weak: audit the shared item-group title, option-name consistency, group membership, and variant-identifying attributes.
• Visibility centers on products that are no longer leading sellers: recalculate popularity ranks from recent sales and confirm that the values remain relative to the current catalog.

Record what you changed at the product and attribute level. That gives you a usable audit trail when visibility moves and prevents the team from making several unrelated edits, seeing one result, and assigning credit to the wrong change.

Key takeaways

• Use conversational attributes to represent buying decisions that the core feed does not express clearly.
• Put each fact in its proper structure: answers in question_and_answer, PDFs in document_link, and product connections in related_product.
• Keep family titles free of variant details, and use consistent name-value pairs for eligible variant options.
• Calculate popularity as a current relative rank from 0 to 100, not as a percentage or a promotional preference.
• Roll out through supplemental data, validate a bounded product set, and use AI query insights to decide which factual gaps to fix next.

Choose one product family and build its complete decision map before scaling. If you can answer its real buying questions, connect its variants, verify its documents, and explain its product relationships in structured data, you have a repeatable model for the rest of the catalog.

References

• Search Engine Land – Google Merchant Center’s 6 conversational attributes explained