How to Write product_highlight, product_detail and question_and_answer

Optional to Submit, Not Optional to Get Right

Three of Google’s conversational attributes carry most of the load in AI shopping: product_highlight, product_detail and question_and_answer. All three are optional. Filling them will not fix a disapproval, and leaving them empty will not cause one.

That is where most merchants stop reading, which is why these fields tend to get filled badly on the rare occasions they get filled at all.

Open Google’s help page for any of the three and scroll past the format table. There is a section headed Minimum requirements, and on the product_highlight page it opens with the sentence Google attaches to rules it actually enforces: if you don’t follow these requirements, we’ll disapprove your product and let you know in your Merchant Center account.

So the honest version is narrower than “optional.” You do not have to submit these fields. If you do submit them, they have to be right.

The rules are not arbitrary either. Each field has a job, and most of the requirements exist to stop you doing one field’s job in another field’s slot. Get that division right and the rest of the spec mostly follows. If you want the wider map first, the eight conversational attributes post covers all of them; this one is about writing the three that matter most.

product_highlight: Selling Benefits, Four to Six of Them

product_highlight takes short bullet fragments, 1 to 150 characters each. Google allows a minimum of 2 and a maximum of 100, and recommends 4 to 6. Take the recommendation. Nobody, human or machine, gets value out of 40 bullets.

What goes in them is settled by one line in Google’s best practices, and it is the line worth remembering:

Use the product highlight attribute to focus on selling benefits, while using product detail to focus on providing technical, verifiable data.

For a cordless stick vacuum, that looks like this:

• Converts to a handheld for stairs and car interiors in one click
• Sealed filtration keeps fine dust from blowing back into the room
• Battery releases without tools, so a spare doubles your run time
• Wall dock charges the unit and stores both floor tools

Each fragment answers something a shopper would otherwise have to hunt for, in one readable line.

Google’s requirements then rule out most of what merchants instinctively write. No promotional text, which covers prices, sale dates, shipping and delivery times, and your own company name. No capitals for emphasis, because “POWERFUL SUCTION” reads as spam to a classifier and to a person. No comparisons with other products; Google’s wording is that customers can research those on their own. Nothing about accessories, compatible models or your returns policy. And no keyword lists, which is the temptation that ruined product titles for a decade.

The requirements read like an editorial style guide because that is what they are. A highlight is a fragment written for a human, which happens to be the exact form an AI answer card can lift and quote.

product_detail: Confirmed Facts, in Named Rows

Where a highlight sells, product_detail states. It is a group attribute with three parts: an optional section_name, then a required attribute_name and attribute_value. In practice you are building a spec table one row at a time.

Two of the requirements here are easy to skim past and worth pinning up.

The first: only submit a name and value when the value is confirmed. Google’s own example is a food product where “Vegetarian: False” gets sent because False is what an empty spreadsheet column defaults to, not because anyone checked. A wrong spec row is worse than a missing one. A missing row leaves you unmatched; a wrong one gets the product returned.

The second: sentence case. “Focal length”, not “Focal Length” and not “focal length”. That sounds trivial until you have 5,000 products and three people entering data, at which point inconsistent casing is exactly the kind of noise that makes a machine treat one fact as two.

Beyond the obvious specifications, this field takes anything a buyer would want confirmed: package contents, ingredients, power requirements, installation notes, finish, scent, flavour, the occasion or activity a product is meant for. A decent rule of thumb is that if your support team has answered it twice, it belongs in a row.

question_and_answer: The Field Built for AI Mode

Google’s page for question_and_answer opens with a note the others do not carry: this attribute is primarily intended for use in conversational experiences such as AI Mode in Google Search.

That is Google telling you what the field is for. It is not page decoration. It exists to be read by an assistant that is answering somebody’s question.

The format is a question and an answer, each up to 1,000 characters, up to 30 pairs, capped at 10,000 characters in total. The requirements are short: submit both halves, keep it about the product, no time-sensitive information like prices or dates, no keyword lists, and give correct and informative answers, because shoppers make decisions on them.

The interesting part is deciding what to ask. The best source is not your imagination, it is your inbox. Presales emails, chat transcripts, review questions and returns reasons are all records of something a shopper wanted to know and could not find on the page. Those are the questions worth answering in the feed, and they are usually the ones an assistant gets asked as well.

Written well:

Written badly: “Is this the best vacuum?” answered with “Yes! Order today for free next-day delivery.”

That one breaks three requirements in a single line, and worse than that, it answers nothing. An assistant reading it learns that you are enthusiastic. It still cannot tell a shopper whether the machine is loud.

The Rule That Ties All Three Together

All three pages carry the same best practice, worded slightly differently each time: do not duplicate data you have already submitted in another attribute. Google names them, title, description, product_detail, product_highlight and question_and_answer, so there is no ambiguity about which fields it means.

This catches people out, because the instinct with an empty new field is to paste the description in and move on. What you get is one fact stated four times and nothing new for anything reading the feed.

There is a quieter version of the same rule. If you submit document_link and the same facts are in the linked manual or spec sheet, Google says not to submit them again in the attribute, because it will pull that information out of the document instead. Sending both is not thoroughness. It is a second copy of something Google already has.

So treat the three fields as three surfaces that do not overlap. A fact belongs in exactly one of them, and which one depends on what the fact does: sell, verify, or answer. This is the same argument as the structured data case for AI shopping, applied at field level.

Doing This Across a Real Catalog

Everything above is manageable for one product. Four highlights, ten spec rows and five Q&A pairs for a vacuum is maybe twenty minutes of work.

Now do it for 5,000 SKUs. In sentence case, inside the character limits, without promotional language, without repeating the description, without inventing a specification nobody confirmed, and in the language of every market you sell into. That is not a data task, it is a staffing decision, which is why so many catalogs still ship these fields empty while their owners know perfectly well the fields matter.

Automating it is what UCP Radar is for. It reads what your feed already contains, generates the highlights, spec rows, variant options and Q&A pairs from that source data, and emits them as a supplemental feed that merges onto your primary feed by product ID inside Merchant Center. Price, availability and identifiers stay where they belong, on the primary feed, untouched. You register the supplemental feed yourself, since no tool submits on your behalf.

The guardrails matter as much as the generation. Brands and identifiers are never rewritten. Material and demographic fields are only set when something in your data supports them, which is the automated form of Google’s “only when the value is confirmed” rule. Health and supplement claims are blocked outright. And because every run records a before and after AI-readiness score, you can see what the enrichment changed instead of assuming it helped: a typical starting catalog sits in the twenties or thirties, and an enriched one lands in the nineties on the UCP Score.

Conclusion

These three fields are the closest thing to a free option in feed work at the moment. They are optional, so most catalogs skip them, which means the catalogs that fill them properly stand out to the surfaces that read them. That edge lasts exactly as long as the fields stay unusual, and Google has been fairly clear about where it is heading.

Getting them right is not complicated. Benefits in product_highlight, confirmed facts in product_detail, real shopper questions in question_and_answer, and nothing said twice. The complicated part is scale, and that one is solvable. Scan your feed first and see how many of your products have anything in these fields at all, then decide how much of it you want to write by hand.