What Merchant Center conversational attributes are and how to use them

A product page can state the price, dimensions and color, yet leave open questions that influence the purchase: does it work on carpets?, which accessories does it need?, what is the difference between its variants?

Google Merchant Center lets merchants provide that context through six conversational attributes: question_and_answer, document_link, related_product, item_group_title, variant_option and popularity_rank. They are optional catalog fields aimed at AI experiences such as AI Mode in Google Search. According to Google, they can also improve traditional search experiences. Official guide to conversational attributes.

For an ecommerce business, this extends the work on product information. Part of what now sits in manuals, customer service inquiries or sales reports can be added to the feed: the data source used to send the catalog to Google.

The opportunity lies in providing useful, verifiable information. Implementing it requires choosing which data to send, who will maintain it and how results will be evaluated.

In summary

All six attributes are optional. They complement catalog data, and Google states that adding them does not change the approval status of existing products.
Each field meets a different need: answering questions, providing documentation, relating products, describing variants or communicating popularity based on sales.
The route Google recommends is a supplemental data source, linked to the products that already exist in the primary source.
The documentation does not guarantee improvements in rankings, traffic or sales. A pilot with comparable products makes it possible to evaluate results, provided that other changes that could explain them are recorded.

What they add to ecommerce SEO and GEO

Conversational attributes make it possible to describe aspects of the product that a basic product page may leave out. A measurement tells how much space a vacuum cleaner takes up; a validated answer can clarify which surfaces it is suited for. An identifier distinguishes an item; a relationship can indicate which accessory is compatible.

From our perspective, this reinforces a task that ecommerce SEO already needs: keeping information consistent across the product page, the catalog and the product documentation.

These attributes should be distinguished from the technical requirements of a web page. Google Search Central states that no special AI files or specific markup are needed to appear in AI Overviews or AI Mode. Conversational attributes belong to the Merchant Center specification and are optional. Our reading of both guides is that they make it possible to enrich the catalog without becoming an additional requirement for a page to appear in those features. Google documentation on AI features and websites.

This distinction also helps frame SEO for AI search, or GEO: identifying which information is missing, where it belongs and how to maintain it.

The six conversational attributes and when to use them

1. Question and answer: `question_and_answer`

Lets you submit frequently asked questions with their answers about a product. It can help clarify what comes in the box, which uses it supports or which features are worth knowing before buying. Google aims it primarily at conversational experiences such as AI Mode. question_and_answer specification.

Its main rules are:

Up to 30 question-and-answer pairs per product.
Up to 1,000 characters per question and 1,000 per answer, with a combined maximum of 10,000 characters per product.
Information about the product, without prices, dates or keyword lists.
Avoid repeating data already submitted in title, description, product_detail or product_highlight.
If the same information is in documents submitted through document_link, Google states that it will extract the FAQs from there and recommends not duplicating it in this attribute.

Customer service inquiries, return reasons and questions on product pages can help identify what the buyer needs to know. The answers, however, must be validated against product information: a review or an inquiry does not, by itself, prove a feature.

In text files, each pair is expressed as "question":"answer" and pairs are separated by commas. Google recommends TSV over CSV and requires following the quoting and escaping rules when values contain reserved characters.

2. Product documentation: `document_link`

Lets you link manuals, user guides, assembly instructions and other documents in PDF. It is useful when the information needed to resolve a question is already set out in product documentation. document_link specification.

The requirements include:

Up to five PDFs per product.
A maximum of 50 MB per file and 2,000 characters per URL.
Public access, without a login or special permissions.
Access allowed for Googlebot, without robots.txt blocks.
Stable URLs that do not expire.
Rights to share the documents for marketing purposes.

The content must explain the product. A company presentation does not serve that purpose.

Before submitting a link, it is worth checking that the file matches the correct model, can be downloaded and remains valid. The robots.txt and HTTP response checks we describe in the bot accessibility test help detect access problems.

3. Related products: `related_product`

Reports relationships with other products in the merchant's inventory: accessories, spare parts, alternatives or items that are often bought together. Google describes its use in conversational experiences to suggest products that can be bought together with the item being viewed or instead of it. related_product specification.

Each relationship requires three sub-attributes:

relationship_type: the type of relationship.
identifier_type: gtin or id.
identifier: the identifier of the related product.

Up to 30 relationships per product are supported. The available types are part_of_set, required_part, often_bought_with, substitute, different_brand and accessory. The identifier only accepts alphanumeric characters, underscores and hyphens.

For example, a camera can be related to a compatible battery through accessory and to an equivalent model through substitute. The relationship chosen must describe the link correctly: an optional accessory and a part required for the product to work play different roles.

For often_bought_with, we recommend starting from actual orders. The intention to sell two products together is not enough to claim that customers usually buy them that way.

4. Item group title: `item_group_title`

Gives a shared name to a product sold in different variants. It is used together with item_group_id, while each variant keeps its own title. item_group_title specification.

For example:

Group title: Travel backpack 40 L.
Title of one variant: Travel backpack 40 L — Blue.
Title of another variant: Travel backpack 40 L — Gray.

The group title accepts between 1 and 150 characters and must be identical across all products that share an item_group_id. Google recommends putting the most important information first, because users often see the first 70 characters or fewer.

It must describe what the variants have in common, without properties exclusive to one of them, prices, shipping, dates or promotional text. Adding the store name as promotion is not appropriate either; the product's brand may be included when it helps differentiate it.

5. Variant options: `variant_option`

Describes what changes between the versions of a product: color, size, memory, processor or other dimensions. Google states that it uses it to present variants both in conversational experiences and in traditional Search. variant_option specification.

Each option contains name and value, with up to 250 characters per sub-attribute. Up to 30 options per product are supported.

For the group to be consistent:

All variants with the same item_group_id must use the same set of names.
Each variant must have a unique combination of values.
The values must match what its landing page shows.
The corresponding standard attributes, such as color, size or material, must be kept; variant_option makes explicit which of those properties distinguish the variants.

An example in text format:

memory:128 GB,color:black

If a product only resembles another one but is not a variant of it, this attribute does not apply. The relationship must reflect the actual organization of the catalog.

6. Popularity: `popularity_rank`

Communicates how a product sells relative to others in the catalog through a value from 0 to 100. The higher the value, the better its relative performance. Google recommends basing it on recent sales and comparing products within the same general category. popularity_rank specification.

The format allows at most one decimal place and has no % sign. For example:

95.5

That number represents a relative popularity position. It should not be read as the percentage of total sales that the product contributes.

Google mentions the last month as an example period and asks for the value to be updated when popularity changes substantially, but it does not set a calculation formula.

One methodological option is to calculate the percentile of units sold within each category over the last 30 days. This is our proposal, not an official Google formula. Applying it would also require defining how to handle ties, new products and out-of-stock periods.

If the merchant cannot sustain that calculation and its updates, it is better to postpone the attribute.

How to add them without duplicating the primary feed

Google recommends using a supplemental data source, although it also accepts adding them to the primary source or sending them through the Merchant API. A supplemental source complements or updates existing products; it cannot add or remove products on its own. Merchant Center data sources guide.

An implementation process can be organized in five steps:

Choose a set of products. Prioritize items that matter to the business and have enough activity to evaluate results. Frequent inquiries, hard-to-interpret variants and available documentation help decide where to start.
Gather and validate the information. Review product pages, manuals, inquiries and sales data. Assign owners to validate answers, compatibilities and documents, and to keep them up to date.
Prepare the supplemental source. Use a file, a Google Sheets spreadsheet or an API integration. The id must match the primary source exactly, as must the feed label and language used to link them. Google states that the supplemental sources tab requires enabling the advanced data source management add-on.
Check processing. Review errors and confirm that the attributes were associated with the intended products. Compare the variants with the landing pages and verify access to the PDFs.
Record the intervention. Keep track of which products changed, which attributes were added and on what date. That record makes it possible to interpret results later and correct the implementation.

This simplified example shows a supplemental source in TSV. The identifiers, features and values are illustrative:

id	question_and_answer	related_product	popularity_rank
VAC-100	"Does it work on carpets?":"Yes. It includes a brush for low-pile carpets."	accessory:id:FIL-20	82.5
VAC-200	"What is in the box?":"The vacuum cleaner with two nozzles and a spare filter."	substitute:id:VAC-100	47.0

The columns are separated by tabs. To carry it over to a real catalog, the related products must exist in the inventory and each claim must correspond to the model indicated.

How to measure results

The documentation reviewed does not guarantee a ranking improvement or describe a report that attributes results specifically to these six attributes. That is why seeing more clicks after loading them is not enough to conclude that they were the cause.

We recommend designing the comparison before implementing:

Define a baseline. Record the prior performance of the products that will receive the attributes and of those that will serve as a reference.
Choose comparable groups. Consider category, price, demand, availability and seasonality. Comparing best-selling products with low-activity items can distort the reading.
Separate ads from organic traffic. Merchant Center lets you view impressions, clicks and CTR, and filter traffic by ads or organic. Product performance documentation.
Compare with sales. Review Google Analytics data and store orders, first checking that ecommerce measurement is reliable.
Record other interventions. Promotions, price changes, advertising spend, product page changes and stockouts can explain part of the evolution.

A useful comparison considers how much each group changed relative to its starting point. It also needs a time window suited to the volume of traffic and sales: a handful of transactions does not support a firm conclusion.

If several attributes are added at once, the analysis evaluates the change as a whole. It does not make it possible to identify which field explains a difference.

A favorable result can justify expanding the pilot. Proving that the improvement was caused by the attributes requires a design that adequately controls for the other variables.

What to review to keep them useful

Each attribute adds a responsibility for catalog quality. The most relevant errors are:

Answers that became outdated. A model change or a change in box contents can make a previously valid answer incorrect.
Inaccessible or wrong documents. The PDF must remain available and correspond to the product it is associated with.
Unvalidated relationships. An incompatible accessory or a substitute that does not serve the same function can misguide a purchase.
Inconsistent variants. The feed, the groups and the landing pages must describe the same options.
Popularity that is not updated. A value calculated only once may stop representing recent sales.
Repeated information. Before adding questions and answers, it is worth reviewing which data was already sent in other attributes or documents.

Review should become part of routine catalog maintenance. Otherwise, the feed can accumulate information that no longer describes what the merchant sells.

Where to start

The priority depends on which information is missing and on the capacity to maintain it:

If variants are hard to interpret, start with item_group_title and variant_option.
If the same questions come up before purchase, review question_and_answer and document_link, avoiding sending the same information through both.
If accessories, spare parts or alternatives matter, work on related_product with verified relationships.
If there is consistent sales data and an update process, evaluate popularity_rank.

Our recommendation is to start with a limited group of products, add the attributes that meet a specific need and review both data quality and results.

If the catalog still has contradictory product pages, poorly grouped variants or inaccessible documentation, those corrections are part of the same work. The usefulness of the new fields depends on the information they receive.

Nor do the attributes replace keeping product pages indexed and up to date on the web: a sitemap with an honest lastmod keeps the background inventory, and IndexNow notifies Bing and the other search engines that take part in the protocol of every URL that changed.

To review crawler access, structured data and content for a store, see our SEO for AI search (GEO) service or learn about CookingMetrics' Google Analytics and SEO consulting.

Frequently asked questions

Do they replace the product description?

No. They complement existing data. Google states that there is no need to duplicate in conversational attributes what was already provided in description, product_highlight or product_detail. The product page remains necessary for the buyer to find information consistent with the catalog. Conversational attributes guide.

Do they also work for ChatGPT or other assistants?

The documentation reviewed describes these attributes within Google Merchant Center and their use in Google experiences. It does not support the claim that loading them there makes them available to ChatGPT or other assistants. That integration must be verified separately for each platform.

Do they guarantee more traffic or sales?

No. The documentation reviewed does not promise better rankings, traffic or sales, and it does not offer a report that isolates the effect of these attributes. To evaluate them, a pilot works best: apply them to a group of products, compare it with a similar group that does not have them and record promotions, price changes and stockouts during the test.

Official documentation reviewed on October 26, 2026. Requirements and specifications may change.