Writing product_detail and product_highlight Values Google Will Accept, With Worked Feed Rows

Google's product_detail attribute accepts up to 100 entries per product, each 1 to 150 characters long, and product_highlight asks for at least 2 and recommends 4 to 6 short benefit statements per item, according to Google's own product detail and product highlight specifications. Both are optional, so most feeds skip them or paste in a spec table that Merchant Center flags as badly formatted.

Google says product_detail helps products show on AI surfaces such as AI Mode, and in May 2026 it added more conversational attributes on the same idea.

This reference is for feed managers and agencies sending product data to Google Merchant Center. By the end you will be able to write both attributes in TSV and XML, escape the characters that break them, keep out banned content, and score a row before submitting.

What product_detail and product_highlight are for

The two attributes look similar and are often filled from the same source, but Google gives them different jobs. product_detail carries technical, verifiable specifications that are not covered by another attribute: package contents, connectivity, ingredients, power requirements, finish, scent and similar facts. product_highlight carries short selling benefits written as plain sentences.

Our quick test: if the line fits a spec table with a label and a value, it is a product_detail. If it reads as a sentence a shop assistant would say, it is a product_highlight. Google's highlight spec makes the same split and asks you not to repeat one in the other.

The specification at a glance

These are the limits as Google publishes them today. Google lists no schema.org property for product_detail, so it is not picked up from your structured data markup; it has to be in the feed.

Sources: Google Merchant Center Help, Product detail [product_detail] and Product highlight [product_highlight].

How to write product_detail in TSV, XML and the Merchant API

The format is where most rows fail. Each detail is three values joined by two colons, in the order section name, attribute name, attribute value. Google is explicit that in text feeds every detail must have two colons, and that supplying a different number of sub-attributes than your header declares produces an invalid sub-attribute format issue under "Needs attention".

TSV header and a single cell

Declare the sub-attributes in the column header, in parentheses and separated by colons. Once they are named in the header, the values can follow in any order you declare. Without the declaration, Google assumes section, name, value.

product_detail(section_name:attribute_name:attribute_value)

A cell with three details then looks like this:

General:Brew type:Turkish coffee,General:Capacity:4 cups,Power:Rated power:1000 W

If a detail has no section, keep the leading colon and leave the first field empty:

:What's in the box?:"Machine,Measuring spoon,User manual"

Escaping colons, commas and quotes

Google's quoted attributes rules apply to group attributes like this one:

• Wrap any sub-attribute value that contains a comma or a colon in straight double quotes. Quote the individual value, not the whole group.
• Write a literal double quote as two double quotes. Google's own example is "APS-C max. 12""" for a value ending in an inch mark.
• Do not use backslash escaping. Google reads a backslash as a literal character.
• Quoted fields are not supported for Google Sheets data sources. For existing file sources, quoted fields have to be switched on in the data source setup.

XML

In XML each detail is its own element with three children, so no colon or comma escaping is needed:

<g:product_detail><g:section_name>Materials</g:section_name><g:attribute_name>Body</g:attribute_name><g:attribute_value>Stainless steel, BPA-free plastic</g:attribute_value></g:product_detail>

For spec-heavy categories, XML is the safer format because natural commas and colons stop being a parsing risk.

Merchant API

Through the Merchant API, each detail is a ProductDetail object with sectionName, attributeName and attributeValue fields, per the API client reference.

How to write product_highlight

Highlights are simpler: one string per highlight. In a text feed, separate highlights with commas and wrap any highlight containing a comma or colon in double quotes. In XML, give each highlight its own <g:product_highlight> element.

"Brews up to 4 cups in one cycle","Foam sensor stops brewing before the pot overflows","Switches off automatically after brewing","Stainless steel body wipes clean"

Keep each one to a single benefit. Google asks for professional, grammatically correct language with no all-caps emphasis, no symbols and no promotional wording.

Content Google does not allow in either attribute

Formatting mistakes produce visible errors. Content mistakes are quieter: a row can be accepted and still break policy. This table combines the bans from both specifications.

Google adds one more rule that is easy to miss: if you submit document_link files that already contain the same information, leave it out of these attributes and let Google extract it from the documents.

Worked example: a spec table turned into accepted rows

Below is a typical row from a store that exports its product specifications as one free-text field. The product is an electric Turkish coffee machine; the store sells in Turkey and in English to Gulf markets.

Before

product_detail: Brand: Acme, Power: 1000W, Material: Stainless Steel, Plastic, FREE SHIPPING, best turkish coffee maker cheap

Five problems in one cell. Separators are mixed, so the colon count does not match the header. "Stainless Steel, Plastic" is unquoted, so its comma splits the detail. Brand duplicates the brand attribute. "FREE SHIPPING" is shipping text in capitals. The last fragment is a keyword string.

After, English feed

General:Brew type:Turkish coffee,General:Capacity:4 cups,Power:Rated power:1000 W,Materials:Body:"Stainless steel, BPA-free plastic",Safety:Automatic shut-off:Yes,:What's in the box?:"Machine,Measuring spoon,User manual"

Brand moved to its own attribute, shipping moved to shipping, keywords deleted, values in sentence case as Google recommends, and every value with a comma quoted. "Automatic shut-off: Yes" stays because the manufacturer confirms it; a field your platform defaults to "No" would not.

After, Turkish feed

Google asks for section names, attribute names and values to be localized in each language feed, so the Turkish feed gets its own row rather than the English one:

Genel:Demleme türü:Türk kahvesi,Genel:Kapasite:4 fincan,Güç:Nominal güç:1000 W,Malzeme:Gövde:"Paslanmaz çelik, BPA içermeyen plastik",:Kutu içeriği:"Makine,Ölçü kaşığı,Kullanım kılavuzu"

Two regional points for teams outside Turkey. First, keep the Turkish letters. Google's recommendation of ASCII is a preference, not a requirement, and its highlight spec explicitly allows accented letters; transliterating "Paslanmaz çelik" to "Paslanmaz celik" produces a misspelling, which conflicts with Google's grammar and spelling guidance. Second, if a rule lowercases or sentence-cases these values, it needs locale-aware casing so that "İ" and "I" do not become the wrong letters, a problem we covered in our Turkish title casing guide.

How to build the values from your catalog

We fill these attributes in four passes, in this order.

1. Map structured sources first. List every specification your platform already stores as a label and value pair, such as a spec tab, a metafield or an ERP attribute. Each pair becomes one product_detail, with the source group as section_name. Use a feed layer such as feed rules or a supplementary feed so the source catalog stays untouched and the Google output can differ from other channels.
2. Remove anything another attribute owns. Drop brand, colour, size, material, price and shipping lines if they are already in their dedicated attributes. Then drop any detail whose text already appears in the title or description.
3. Write highlights by hand or with reviewed AI drafts. Highlights are where AI enrichment helps most and fails most. A model will happily write "Ideal gift for coffee lovers", which is promotional, or invent a feature the product does not have. Generate drafts only from confirmed specifications, and review them against the ban table above.
4. Validate length and syntax before export. Check that every detail and every highlight is 150 characters or fewer, that every detail has exactly two unquoted colons, and that the highlight count per product is at least 2.

A scoring rubric to run before you submit

Score a sample of 20 rows per category. Each check is pass (1) or fail (0), for a maximum of 10 per row. We treat 9 or 10 as ready, 7 or 8 as fix-then-ship, and anything lower as a sign the source data needs work before these attributes are worth sending.

Where this guide breaks down

We do not know how much these attributes move ranking or click-through. Google says product_detail helps products show for relevant queries, including in AI Mode, but publishes no figure, and we have not seen a controlled public study. Treat vendor percentages with suspicion until they come with a method.

This is a Google reference. OpenAI's product feed specification has no general key-value specification field or highlights field; it uses flat fields such as material, dimensions and weight, plus a 5,000-character description. If you also send that feed, your specifications have to be mapped into those fields or the description instead. We did not verify Meta or TikTok equivalents for this guide.

It also leaves out the newer conversational attributes, such as question_and_answer and document_link, beyond the rule above about overlap. Several feed vendors, including Channable and Productsup, published mapping guides for those earlier than we did, and they are worth reading if you need that set now.

Finally, if your catalog has no structured specifications, this method cannot create them, and AI drafts without a confirmed source are what Google's "submit only confirmed values" rule exists to stop.

Frequently asked questions

Is product_detail required in Google Merchant Center?

No. Google lists it as optional for every product. It is worth adding where you hold verified specifications that no other attribute covers, because Google says it helps products appear for relevant queries, including on AI Mode.

How many product highlights should I submit?

Google requires at least 2 and allows up to 100, and recommends 4 to 6 per product. Each highlight can be up to 150 characters.

Why does Merchant Center say my product_detail has an invalid sub-attribute format?

The number of sub-attributes in a value does not match the header, usually because a detail is missing a colon or an unquoted comma or colon inside a value split it. Quote any value containing those characters and keep two colons per detail.

Should I use Turkish characters in a Turkish feed?

Yes. Google accepts Unicode and recommends ASCII only as a preference, while its highlight guidance allows accented letters and asks for correct spelling. Stripping Turkish letters creates misspelled words.

Can AI write my product highlights?

It can draft them, but only from specifications you have confirmed, and every draft should be checked for promotional wording, comparisons and invented features. Google bans the first two in highlights, and an invented feature is simply false product data.

Does Google Sheets support quoted product_detail values?

No. Google's quoted attributes guidance says quoted fields are not supported for Google Sheets data sources, so spec values with commas or colons are better sent through a TSV file, XML or the Merchant API.

Check your feed before you add these attributes

These attributes only help if the fields they build on are clean. Run your feed through the free product feed audit tool to see completeness, quality and technical issues per product before you start writing details and highlights.