Implementing Only Conversational Attributes in Google Merchant Center Is Self-Inflicted Busywork

It has been about three months since conversational attributes were added to Google Merchant Center in May 2026.

In my previous article (Japanese), I walked through the specification of each of the six attributes and suggested that anyone interested try implementing them through a supplemental data source.

Since then, I have started to see “conversational attribute support” appear as a headline item in service offerings. It is natural for a new attribute to produce a new service menu. But seeing conversational attributes packaged as a standalone deliverable gives me pause.

Implementing only conversational attributes is, from the merchant’s side, self-inflicted busywork. This article is about whether you should implement conversational attributes at all, and if so, in what order: what to check before taking that work on.

The specification of each attribute is covered in the previous article, so I won’t repeat it here. That article introduced Google’s note that the attributes are unnecessary if the information already exists in other attributes. This article goes one step further back: does the information exist on your product page at all?

Conversational attributes are a list of what shoppers want to know on the product page

Google Merchant Center Help describes conversational attributes as a way to help “AI systems and conversational agents better understand the specific nuances of your products.” On the surface, they are attributes for AI.

But if you translate each of the six into a question a shopper might ask, this is what you get.

Five of the six are things that should already be on the product page. They are less what AI wants to know than what shoppers want to know.

This is consistent with how Google treats product data generally. The variant option [variant_option] Help page lists, as a minimum requirement, that the product details shown on the landing page must match the values you submit. The product data specification requires the same for title [title] and description [description]: they must match the landing page. What you put in product data is expected to exist on the page. That is the baseline assumption in Google Merchant Center.

So the conversational attribute specification can be read, quite literally, as a list of what shoppers want to confirm on your product page.

What the busywork actually is

“Implementing only conversational attributes” means writing those five items in a place only Google can read, in a Google-specific format, without putting them on the product page.

The Q&A you submit in question and answer [question_and_answer] does not appear on your product page. The “often bought with” items you submit in related product [related_product] do nothing for on-site navigation. The only reader is Google’s system. A shopper who lands on your site leaves with the same unanswered question.

You do this for every product. You update it every time the catalog changes. When a variant is added, you add a variant option [variant_option] entry. Because this runs through a supplemental data source, every product addition or removal is a maintenance task.

Writing text that shoppers will never read, one product at a time, indefinitely. That is the busywork.

Is the order backwards?

I think the intended order looks like this.

1. Write what shoppers want to know on the product page.
2. Pass that to Google in a form it can read: structured data, or the description [description], product detail [product_detail], and product highlight [product_highlight] attributes.
3. If something still can’t be passed that way, supplement it with conversational attributes.

When “conversational attribute support” is carved out as a service, it tends to deliver step 3 alone. Steps 1 and 2 are skipped, and only the fields that might surface in AI Mode get filled in.

Because conversational attributes carry an “AI-ready” label, they can look like a new kind of work, separate from the product page maintenance that should have been done already. The substance is almost identical. If you can think of what to write in question and answer [question_and_answer], you can write it on the product page. If you can define related product [related_product] relationships, you can show them in the related-items block.

Anything you can write into a conversational attribute is something you could have written on the page.

“But structured data is easier for AI to read”

Anyone who knows Google Merchant Center well will probably object here: a paragraph of prose on a product page and a structured Q&A pair in question and answer [question_and_answer] are not the same thing to an AI system.

That’s true. I’m not arguing against structuring the data.

But structuring means taking information that already exists and putting it in a machine-readable form. If the source information doesn’t exist on the product page, that isn’t structuring. It’s writing new content that exists only for Google.

Write it on the product page, then structure it into question and answer [question_and_answer] as well. In that order, the attribute is a copy of the page, and fixing the page fixes the attribute. Skip the page and write only the attribute, and the attribute becomes the sole home for that information: never reaching shoppers, maintained on its own.

Only the second case is busywork. The dividing line isn’t whether you structure the data. It’s whether the data was on the page first.

One more objection: “If you generate the attributes from your product master with AI, there’s no ongoing writing burden.” Manual or automated isn’t the point. Generated text that reaches Google but never reaches shoppers has the same structure either way.

Google’s Help says something close to this

This isn’t only my reading. The conversational attributes Help page includes this note:

Note: If you already provide specific details in the description [description], product highlight [product_highlight], or product detail [product_detail] attributes, you don’t need to duplicate that data in the conversational attributes.

Google itself says: if it’s already in existing attributes, don’t add it to conversational attributes. And if it’s in existing attributes, in most cases the product data is in order, which is very nearly the same as saying it’s on the product page.

In my previous article I presented this note as “cases where you can skip conversational attributes.” Thinking about it again, the order is the other way around. Not “existing attributes cover it, so conversational attributes are unnecessary,” but “existing attributes and the page come first, and conversational attributes come last.”

I should also say that I don’t yet have data from the Japanese market on how much these attributes change what appears in AI Mode. If you are in a market where you can measure it and the attributes do help, that’s useful to know. But it doesn’t change the structure: the return is a variable, and the cost of writing and maintaining these fields for the entire catalog is fixed from day one. Implementing the attributes first, before the page, still gets the order wrong.

Use the specification as a checklist

What to do before taking on the busywork is simple: hold the six attributes up against your own product pages.

• Does the page answer the questions shoppers actually ask?
• Can shoppers reach the manual or spec sheet from the page?
• Are required parts, accessories, and companion products shown on the page?
• Are variant options presented in a structured way (dropdowns, swatches)?
• Does the product group have a name distinct from the individual variant titles?

If the answer is yes, you don’t need conversational attributes for now. If the answer is no, what you need to add isn’t the attribute. It’s the content on the page.

Conversational attributes become useful the moment you stop reading them as an AI to-do list and start reading them as a list of questions your product page isn’t answering.

The exception: popularity rank [popularity_rank]

One of the six is different. Popularity rank [popularity_rank] is a 0–100 relative score of how well a product sells within your own catalog. Help describes it as a way to convey “how well a product is selling, such as recent bestsellers.” Many sites already surface this as a bestseller badge or a ranking page, so it isn’t information hidden from shoppers.

But the per-product relative score itself isn’t written on any product page, and it isn’t realistic for Google to derive each product’s score from a site’s ranking page. It’s information that can only be delivered by computing it from sales data and passing it in the feed. In my previous article I said it looked like a weak signal for getting a store recommended during product discovery, and I still think so. Setting aside how much it matters, though, it’s the only one of the six that conversational attributes alone can deliver.

If you generate it from sales data automatically, there’s no manual work at all. If you’re going to implement conversational attributes, this is the one to start with.

When conversational attributes are still the right call

“Fix the product page” is easy to say. Some merchants can’t.

On platforms where the product template is locked down, adding an FAQ block or a related-items block may not be an option. In that situation, conversational attributes are a legitimate workaround: a way to pass Google information that can’t be put on the page.

But it’s a workaround for a constraint, not an AI strategy. Using the attributes because you can’t change the page, and knowing that’s why, leads to different decisions than using them because they look like the new AI initiative. In the first case, the day you can change the platform, you’re released from the attribute work. In the second, you keep writing attributes even after the page becomes editable.

This isn’t only about conversational attributes

The same structure existed before conversational attributes.

Product highlight [product_highlight], for example, is defined in Help as short points that “answer the most common consumer questions.” The role that question and answer [question_and_answer] is meant to play was already assigned to an existing attribute. Both product highlight and product detail [product_detail] are now described in Help as helping shoppers find product information on AI-driven surfaces like AI Mode. And the product detail [product_detail] specification explicitly says not to duplicate data already submitted in title, description, question and answer, or product highlight.

From the specification’s point of view, conversational attributes aren’t a separate “AI bucket.” They are part of a set of attributes that describe the same information and are meant not to overlap. Each time a new attribute appears, treating it as a new line item and filling it in without touching the product page produces the same result.

“Agentic commerce readiness” and “UCP readiness” have the same shape. As I wrote in “Don’t Rush into Agentic Commerce,” the exit may become a conversational agent, but how Google understands your products doesn’t change. Take inventory of product information, structure it, submit it correctly. Stack “readiness” projects on top of a missing foundation and all you get is more things to maintain.

Whenever a new attribute or protocol arrives, it’s worth asking whether it’s just a restatement of something that should already have been in place for shoppers. Conversational attributes happen to be a clean example. The pattern is not specific to them.

In closing

Conversational attributes aren’t so much new content to write for AI as a list of what should already have been written for shoppers.

If it’s on the product page, you don’t need conversational attributes for now. If it isn’t, the place to write it is the page, not the attribute. Implementing only the attributes means choosing to write Google-only text, for every product, indefinitely, in a place shoppers never see.

Before taking that on, hold the specification up against your own product pages. If someone proposes “conversational attribute support” to you, whether the conversation starts with your product page is a reasonable thing to judge them on. That, I think, is the most useful thing these attributes can do.