Merchant Center: questions and answers in the product feed

Google Merchant Center offers six attributes that Google calls conversational attributes: questions and answers, links to PDF manuals, related products, a shared title for variant groups, variant options and a popularity rank (Google Merchant Center Help). They are optional, and according to Google they are meant to help customers discover product information across AI-driven surfaces such as AI Mode in Search (Google Merchant Center Help). For shops in Germany this is first of all a matter of feed quality, not a promise of visibility: Google lists no countries on the overview page in which the information appears, and in the European Economic Area Google has reorganized the free product listings in Search. This article explains the six attributes, shows how to fill the question_and_answer attribute from support tickets, manuals and reviews, and why a supplemental data source is the calmer route compared with rebuilding the main feed. AI data enrichment is well suited to drafting the answers, while approval stays with people.

Six attributes for products that need explaining

Google describes the conversational attributes as a complement to the existing product data specification, not as its replacement (Google Merchant Center Help). Core data such as title, price, availability and GTIN stays where it is. The new fields carry what so far mostly lived on the product page, in the manual or in the heads of the customer service team: answers to typical questions, technical documents, accessories and spare parts, the structure of a variant group and information on which items sell well within your own range.

Conversational attributes help AI systems and conversational agents better understand your products’ specific nuances.

Google Merchant Center Help, How to use conversational attributes

All six attributes are optional (Google Merchant Center Help). Merchants can submit them through a supplemental data source, which Google explicitly recommends, through the primary data source or through the Merchant API (Google Merchant Center Help). Nothing changes for the approval of existing products: according to Google, including the attributes does not affect the approval status of products you already have (Google Merchant Center Help). The following overview summarizes what the attributes are for and which limits the specification sets.

What Google commits to – and what remains open

On the overview page, Google justifies the attributes with AI-driven surfaces such as AI Mode in Search and also mentions traditional search (Google Merchant Center Help). The specification of question_and_answer is more specific: the attribute is primarily intended for conversational experiences such as AI Mode in Google Search (Google Merchant Center Help). For document_link, the documents are said to be used primarily in conversational AI experiences, for example to answer detailed questions about the product (Google Merchant Center Help).

What the pages do not say matters just as much. The overview page names neither countries nor languages in which the information is displayed. The individual specifications state that each of the attributes can be used in all countries (Google Merchant Center Help). That refers to submitting, not to display. Whether and where an answer from the feed shows up on a search surface cannot be read from the documentation.

question_and_answer: questions and answers in the feed

The attribute takes questions and answers that can come from users, the merchant or the manufacturer (Google Merchant Center Help). Technically it is a group of the sub-attributes question and answer, and both are required. Question and answer may each be up to 1,000 characters long (Google Merchant Center Help), up to 30 pairs are possible per product (Google Merchant Center Help), and all questions and answers of a product together are limited to 10,000 characters (Google Merchant Center Help). If you use many pairs, you need to keep them short. A few minimum requirements apply to the content (Google Merchant Center Help):

• Question and answer are submitted together; one sub-attribute on its own is not enough.
• Only information about the product itself: no prices, no dates and no other time-related information. There are separate attributes for that.
• No lists of search terms or keywords.
• Correct and informative answers, because customers base their buying decisions on them.

Beyond that, Google recommends a wide variety of questions: depending on the product, for example about specifications, ingredients, package contents or the occasions and activities the product is intended for (Google Merchant Center Help). Two recommendations concern duplication. Whatever is already in the title, description, product_detail or product_highlight should not be repeated in the questions. And if you provide a manual via document_link that already contains the answer, you can skip the pair: Google then extracts FAQ information from the document (Google Merchant Center Help). In a tab-separated supplemental source, an entry looks like this:

id      question_and_answer
WK-100  "Can the scale filter be removed?":"Yes, the filter sits in the spout and can be taken out for cleaning.","Does the kettle have a keep-warm function?":"No, it switches off after boiling."

In XML data sources, each pair sits in its own element with sub-elements for question and answer (Google Merchant Center Help):

<g:question_and_answer>
  <g:question>Can the scale filter be removed?</g:question>
  <g:answer>Yes, the filter sits in the spout and can be taken out for cleaning.</g:answer>
</g:question_and_answer>

Where the answers come from

Most shops do not need to invent the questions. They already exist, just scattered: in support inboxes and tickets, in phone inquiries, in customer reviews, in manufacturers’ manuals and data sheets and in the reasons customers give for returning goods. The work lies in filtering out the questions that recur and have a clear answer that can be backed up.

For support tickets and reviews, one rule applies: you take over the question, not the person. Names, order numbers and other details that point to a customer do not belong in the feed. The question is rephrased in general terms, and the merchant is responsible for the answer. This follows the principle of data minimization and prevents a single case from sounding like a general product property.

Drafted by AI, approved by people

With a large range, nobody can sift through the material by hand. This is where AI helps: it groups similarly worded inquiries into one question, assigns them to the right products and drafts answers from the manual and data sheet. How this works together with the shop and the product database is described in our article on AI data enrichment for product data.

The draft, however, is only half the work. Google requires correct and informative answers, because customers buy on that basis (Google Merchant Center Help). An invented statement about the load capacity of a shelf or the tolerability of a care product does more harm than a missing one. That is why every answer needs a source in your own records, and before it goes into the feed, someone who knows the product approves it. Our AI automation applies the same principle to category assignment: products below a defined confidence threshold are flagged for manual review there. For answers in the feed, a process like this one works well:

1. Collect: bring together inquiries, reviews and return reasons per product and remove personal data.
2. Group: merge similar questions into one and sort them by frequency.
3. Draft: write answers from the manual, data sheet and product data and note the source for each answer.
4. Check: does the answer match the product page and data sheet? If it contains prices, dates or search terms, it is removed.
5. Approve: a person with subject-matter responsibility confirms the answer; only then does it go into the supplemental source.
6. Follow up: if the product changes, the related answers are checked again.

document_link: connecting manuals as PDFs

With document_link, a product points to PDF documents: training manuals, user guides, assembly instructions, package inserts and the like (Google Merchant Center Help). According to Google, the documents are used primarily in conversational AI experiences to answer detailed questions about the product (Google Merchant Center Help). Up to 5 URLs are possible per product (Google Merchant Center Help), each URL may be up to 2,000 characters long (Google Merchant Center Help), and each file may be at most 50 MB (Google Merchant Center Help). On top of that come requirements for accessibility and rights:

• The URL starts with http:// or https:// and points directly to a PDF file.
• The file is publicly accessible without a login, and robots.txt does not block it for Googlebot.
• The URL is stable and does not expire.
• The merchant has the right to share the document for marketing purposes.
• The document is about the product, not about the company.

In many shops, manuals sit behind a customer account, in a download area with changing URLs or on a manufacturer server whose paths change. Logins and changing URLs in particular do not fit the requirements. The usual route is a dedicated, publicly accessible folder with descriptive, permanent file names that the shop serves to visitors and search engines alike. Whether robots.txt and server headers allow this is a question of crawlability, which we check in the technical part of search engine optimization.

Describing variants and accessories cleanly

Three of the six attributes concern the structure of the range. item_group_title gives all variants with the same item_group_id a shared title, while each variant keeps its own title (Google Merchant Center Help). The group title may be 1 to 150 characters long, must be the same for all variants in the group and should differ from the titles of the individual variants (Google Merchant Center Help). Size and color belong in the variant title, not in the group title.

With variant_option, each variant describes how it differs from the others, as pairs of name and value, for example shoe width and size (Google Merchant Center Help). Name and value may each be up to 250 characters long, and up to 30 option pairs are possible (Google Merchant Center Help). Discipline is what matters: all variants in a group carry the same names, each variant has its own combination of values, and the details on the landing page must match (Google Merchant Center Help). In a Shopware shop, the names correspond to the properties from which the variants are generated; if you reorganize the URLs of your variants, plan that together with the SEO URL templates in Shopware.

With related_product, a product links to other items from your own range. Each entry consists of relationship type, identifier type and identifier; the identifier is the GTIN or your own product ID, and up to 30 links are possible per product (Google Merchant Center Help). Google distinguishes six relationship types (Google Merchant Center Help):

The data for this usually sits in the ERP, the PIM system or the shop’s cross-selling assignments. For often_bought_with, the order history is worth a look; for required_part and accessory, parts lists and manufacturer information are more reliable than purchase patterns. Only letters, digits, underscores and dashes are allowed in the identifier (Google Merchant Center Help).

popularity_rank: calculating popularity on solid ground

The popularity_rank attribute indicates how well a product sells compared with the rest of the range; the higher the value, the better (Google Merchant Center Help). Allowed is a number between 0 and 100 (Google Merchant Center Help) with at most one decimal place (Google Merchant Center Help), without a percent sign. Google recommends deriving the value from recent sales, for example from last month’s sales volume, and comparing it with products in the same category (Google Merchant Center Help). A query for this can look like this:

-- Rank per category from last month's sales volume
SELECT product_number AS id,
       ROUND(100 * PERCENT_RANK() OVER (
         PARTITION BY category_id
         ORDER BY units_last_month
       ), 1) AS popularity_rank
FROM sales_last_month;

The query puts the item with the highest sales in a category at the top of the scale and the weakest at its lower end. Honesty matters more than the formula: Google requires a rank that reflects how well the product actually sells (Google Merchant Center Help). Pushing clearance items up artificially gives a false picture of your range. The value is updated when popularity changes noticeably, as Google recommends, for example through a supplemental data source (Google Merchant Center Help).

Supplemental data source instead of rebuilding the main feed

Google recommends submitting the attributes through a supplemental data source (Google Merchant Center Help). Such a supplemental source adds to products that are already in Merchant Center through the primary data source and is matched by product ID. In practice this has advantages: the proven export from the shop stays unchanged, and questions and answers can be maintained, approved and withdrawn at their own pace.

The attributes can also be submitted through the Merchant API (Google Merchant Center Help); what the switch to this interface means for feeds is covered in our article on the Merchant API and the 2026 feed rules. For Shopware shops, a separate export is a good fit: questions, answers and document URLs sit in custom fields on the product, and an approval status controls what is delivered. The Google Merchant Center integration then takes care of the regular transfer.

Measuring the effect without expecting too much

Because Google names no countries for the display of conversational attributes, you first measure what can be measured: the quality of your own data. Useful metrics are the share of products with approved questions and answers, the notices in Merchant Center diagnostics on the supplemental source and the development of support inquiries for products whose questions are answered.

The benefit does not depend on Google alone. The same questions and answers also belong on the product page, where they help customers directly and save follow-up questions. How product pages are prepared for AI answers is shown in our article on AI Overviews in shopping; the basics of feed maintenance are covered in the guide to Google Shopping feed optimization.

If you are also planning the switch from dynamic search ads to AI Max, you are working on product data and landing pages anyway. Both projects can be planned in one pass instead of touching the same products twice.

Roadmap for the first weeks

Getting started does not have to cover the entire range. As a rule, one category whose products trigger many follow-up questions is enough at first:

1. Take stock: which products cause the most support inquiries, where are the manuals, how are variants grouped?
2. Choose a pilot category: a category with products that need explaining and existing documents.
3. Collect and draft questions: group inquiries, draft answers with sources, remove duplicates of the description and product details.
4. Approve: subject-matter review per answer, set the approval status in the shop.
5. Create the supplemental source: export with id and question_and_answer, plus document_link if needed, set it up in Merchant Center as a supplemental data source and check the diagnostics.
6. Expand: further categories, then related_product, variant_option and popularity_rank.

How we support you with questions, answers and feeds

Conversational attributes need the sources within the company, a drafting and approval process and the technical transfer to Google to come together. We connect these parts:

Whether the effort pays off for your range can be assessed after taking stock. Get in touch via our contact page; we will look at your data and your existing feed together with you.