Structured Product Data: Why AI Needs More Than a Title

A Title Is One Line. A Shopper’s Question Has Five Conditions.

Someone asks an AI assistant for “a waterproof hiking boot for wide feet, under $150, that ships in two days.” That sentence carries five separate conditions: the category, a construction property, a fit attribute, a price ceiling, and a delivery window.

Now look at your product title. Even a strong one, like “Merrell Moab 3 Men’s Waterproof Hiking Boot, Brown,” answers two of them. That is not a bad title. It is a title, and a title is one line of text with a character limit. The other three conditions live in the structured product data fields that most feeds leave empty.

This is usually what people mean when they say a feed is not AI-ready. It is rarely one broken thing. It is a catalog where the only field carrying real information is the title, and the title has been asked to do a job it was never sized for. You can write it perfectly and still lose the recommendation, because the assistant had no way to confirm the boot comes in a wide fit.

Structured product data is what closes that gap. It is also the part of feed work almost nobody does, which is the interesting part.

What Structured Product Data Actually Means

Any product fact stored in a labeled field rather than buried in a sentence is structured data.

“Waterproof to 5 metres” written inside your description is prose. The same fact written as an attribute named Waterproof with the value “Yes, to 5m” is structured. To a person reading the page, those two are identical. To a machine they are not close.

Reading prose means inferring. The model has to decide whether “keeps you dry when the weather turns” is a waterproofing claim, a marketing flourish, or a note about the lining. Reading a labeled field means looking something up. The first is a guess carried at some confidence level. The second is a fact the machine can act on and cite.

That difference matters more now because AI shopping surfaces match meaning rather than keywords. When an assistant builds a shortlist, it is trying to satisfy every condition in the question. Products whose data states those conditions plainly are easy to retrieve and easy to justify recommending. Products that hint at them in a paragraph get skipped in favor of ones that did not require guesswork.

Google added a set of optional product fields for exactly this, introduced as conversational attributes at Marketing Live 2026. They do not affect whether your products get approved in Merchant Center. Approval and AI readiness are two different tests, and passing the first tells you nothing about the second. What these fields do is hand Google’s AI surfaces explicit product knowledge instead of a paragraph to interpret.

The Four Fields That Carry What a Title Cannot

There are eight conversational attributes in total, and the full field-by-field breakdown is worth reading. Four of them do most of the work.

product_detail holds specifications as rows, each with a section name, an attribute name, and a value. This is where the wide fit, the waterproof rating, the sole compound and the shell material live. It answers the conditions your title ran out of room for.

product_highlight holds short benefit statements, four to six of them, each up to 150 characters. Benefits, not specifications. These are the lines an AI answer card tends to surface as the reason a product is being suggested, so they work as a retrieval signal and as your pitch at the same time.

question_and_answer puts FAQ pairs directly in the feed. Google’s own documentation describes the field as primarily intended for conversational experiences such as AI Mode, which is unusually direct as hints go. It works because it mirrors the shape of the query. A shopper asks “does this run narrow?” and your feed already contains that question with an answer attached.

variant_option states how variants differ from one another. Without it, an assistant looking at eleven near-identical rows has to work out whether it is seeing eleven products or one product in eleven sizes, and it will usually decline to guess.

Fill these and your product stops being a name with a price. It becomes something a machine can reason about.

Why Your Description Doesn’t Cover This

The usual objection here is that all of this is already in the description. That is normally true, and normally not enough.

Descriptions are written to persuade a person who has already landed on your page. Different reader, different job, and it produces copy that reads well and specifies little. “Engineered for the trail” is good marketing and poor data. A machine reading it learns that the product is outdoor-adjacent and nothing else.

There is a structural problem too. A description is one unlabeled block of text. Even when the facts are all in there, they are not addressable. Nothing can filter your catalog for wide-fit boots by reading paragraphs, so a product whose only mention of fit sits in sentence four is invisible to a query that requires it.

Your description tells a shopper why to buy. Your structured attributes tell a machine what the thing is. Only one of them gets you onto the shortlist.

Keep writing good descriptions. They still sell. Just stop expecting them to carry data.

Filling These Fields Across a Real Catalog

None of this is hard for one product. Write four spec rows, five highlights, three question and answer pairs and a variant statement, and you are done in fifteen minutes.

Multiply that by 3,000 SKUs, in whatever language your market speaks, inside Google’s character limits, without inventing a claim that trips a policy check, and it stops being a data task. It becomes a hiring decision. That is the real reason these fields sit empty across most of e-commerce, and why they are still worth something to anyone who fills them while they remain optional.

The workable route is to generate the structure from product knowledge you already have. UCP Radar connects to your Google Merchant Center, reads your catalog, and gives every product a 0 to 100 AI-readiness score so you can see which products are thin before you spend anything. From there it rewrites weak titles, fills missing attributes like color and material, and generates the highlights, spec rows, question and answer pairs and variant options that AI surfaces read.

All of it ships as a supplemental feed, a secondary feed that merges onto your primary feed by product ID inside Merchant Center. Your primary feed keeps owning price, availability and identifiers, and the enrichment layer adds structure on top. You register that feed yourself, since no tool submits on your behalf. It runs across the whole catalog in eight languages, checks against more than 50 Merchant Center rules, and leaves your brand names and identifiers exactly as you wrote them, which is what makes a bulk rewrite safe to run.

The scale of the change is easier to see on one product. A men’s shirt exported from a store as “Blue Shirt Men,” with no color field, no material and no structured detail, scores 28. Enriched into “Premium Sapphire Blue 100% Cotton Men’s Casual Dress Shirt, Breathable and Lightweight,” with the attributes filled and the highlights and specs written out, it scores 92. The shirt did not change. What changed is that a machine can now read it.

Start where the money is. Sort by revenue, find your best sellers with the thinnest data, and fix those first. Nobody can promise you a ranking, and any tool that does is selling something. What you can control is whether the machine has enough to work with. The same structured data also feeds Google Shopping and Performance Max, which build ads from your attributes, so the work pays twice.

Conclusion

The product title was the whole game for a decade because keyword matching was the whole game. Both changed. An assistant answering a real question in plain language needs facts it can check against conditions, and one line of text runs out of room somewhere around the second condition.

Structured product data is how the rest of what you know about your products reaches the systems now deciding which items get named. The fields are open and optional, and they make no difference to your Merchant Center approval either way, which is why most catalogs still have them empty. If you want to know where yours stands, UCP Radar will score your feed and show you the gap before you commit to anything.