Product Descriptions Agents Can Read: Attributes First, Schema Consistent, Same as the Feed

What is a product description an agent can read?

A product description an agent can read is product content written not to persuade a person but to let an AI agent identify the product correctly, compare it and, when needed, transact on it. The classic product description was shop-window copy: a fluent tone, benefits, a "buy now" call. In 2026 your product page has a second reader, and that reader sees fields, not tone. What recommends your product to a user in a ChatGPT shopping query, in Google AI Mode, in Amazon Rufus or in Perplexity is not the adjectives in your copy; it is the consistency of title, attribute list, identifier, price, stock, delivery and returns data.

We first published this article in February 2025 under the question "how should a product description be written". Since then OpenAI has published its product feed specification, Google has added dozens of Merchant Center attributes for AI Mode, and Amazon Rufus has started reading the whole listing. The definition of a product description changed, so we rewrote the article. At Webtures we put it as a thesis: the agent does not read your page, it consumes your data. A good product description is now good product data.

Why does an agent read a product description differently?

A person looking at a product page scans the image, the price and two sentences and fills in the rest by intuition. An agent has no intuition. It sees the same product on four layers: the web page (the text the user sees), the product schema (Product and Offer markup), the product feed (Merchant Center, the OpenAI feed) and the product API (live price and stock). When the four layers say the same thing the product is "comparable". If the page says 189, the schema 199 and the feed 209, the agent cannot tell which number is true and drops the product from the shortlist.

The picture our team has measured is clear. In-chat checkout was the promise of 2025; by March 2026 the model had settled into "discover in AI, buy on site". In one industry survey half of consumers said they bought after researching with an AI tool, while only 22% completed the purchase inside the AI. The agent's job is discovery and comparison; your product description is either in that comparison or out of it. And the condition for being in it is not a persuasive sentence but parseable data.

How three platforms read product content makes this concrete:

• ChatGPT: OpenAI's product feed specification defines nine required fields: item_id, title, description, url, brand, seller_name, image_url, availability, price. The description field is defined as "factual product details", not persuasion. Search and checkout eligibility are separate flags (is_eligible_search, is_eligible_checkout); checkout requires a returns policy and seller terms URLs. The feed can refresh every 15 minutes.
• Google AI Mode and Gemini: on 11 January 2026 Google announced dozens of new Merchant Center attributes for conversational commerce. The eight that matter most: product_highlight (4 to 6 short benefits), product_detail (sectioned specifications), variant_option, item_group_title, related_product (part, accessory, substitute), question_and_answer (up to 30 pairs), document_link (manual PDFs) and popularity_rank. The new form of the product description lives inside these fields.
• Amazon Rufus: reads the whole listing: title, bullets, A+ content, Q&A and reviews. If it can answer the shopper's natural-language question ("can I wear it in summer heat, does it crease, does it ship to Europe") from the listing, it recommends the product. Keyword density does not decide; the attribute sentence that answers the question does.

What are the components of an agent-friendly product description?

The mandatory field set our team defined for the product data cluster in the Agentic Commerce Assessment Set answers this question: SKU, GTIN, product name, category, dimensions, weight, material, origin, customs tariff code, package size, price, stock status and delivery time. If these are missing, the quality of the description is beside the point; the agent cannot match the product. The layers on top look like this:

The right-hand column says it: the product description is no longer one text box but a data set spread across page, schema and feed. The text is only the human-facing surface of that set.

How do you write a product description for an agent?

1. Open with a definition sentence. The first sentence says what the product is, who it is for and what distinguishes it: "100% linen, 190 g/m², lightweight men's summer shirt; sizes 38 to 46, delivered to Europe in 3 to 5 working days." An agent can cite that sentence on its own.
2. Give attributes as name-value pairs. Not "breathable fabric" but "Fabric: 100% linen, 190 g/m²". Every attribute on the page has the same value in the schema as additionalProperty and in the feed as product_detail.
3. Add sentences that answer the shopper's questions. The average AI Mode query is three times the length of a traditional search. The answers to "does it crease", "is it machine washable", "is gift wrapping available" sit on the page as plain text and in the question_and_answer attribute.
4. Separate the variant in the title, define the group separately. For colour and size variants share an item_group_title and give each variant title its own attribute. An agent can only match "blue, size 42" at variant level.
5. Move delivery and returns onto the product page. A return window buried on a policy page does not exist for the agent. Fill MerchantReturnPolicy and OfferShippingDetails per country; carry the same data in the OpenAI feed's accepts_returns, return_deadline_in_days and shipping fields.
6. Cut persuasion, delete fake signals. Unverifiable phrases such as "limited stock" or "everyone's favourite" are noise for an agent and sometimes a loss of trust. Real scarcity is a stock number; real popularity is popularity_rank.
7. Feed the four layers from one source. Page, schema, feed and API are generated from one product record. A hand-updated copy drifts sooner or later, and where it drifts the agent recommends a product that does not exist at the wrong price.

What are the most common product description mistakes?

• The product without identity. GTIN and MPN empty; the agent cannot cluster the product with competing listings and it drops out of the comparison. Our target is 100% identifier coverage; for bespoke products the field is not left blank, it is set to identifier_exists: false.
• Contradiction between layers. Different price or stock on page, schema and feed. Stale data is more dangerous than no data: invisibility is a lost opportunity, inconsistency is lost trust at the moment of purchase.
• A description loaded by JavaScript. Most major AI bots do not execute JavaScript; a client-rendered description is absent from the raw HTML. Render on the server.
• Keyword stuffing. "Linen shirt men linen shirt summer shirt" is repetition for the agent and repellent for the person. Once, in the right place.
• Keeping policy away from the page. Without delivery time and return terms on the page and in the schema, the agent treats delivery as unknown; in multi-market cross-border trade that means dropping out of the recommendation.
• One update a day. A daily file is not enough for fast-moving stock. Daily full snapshot plus intraday API updates; OpenAI accepts a 15-minute refresh.

What should cross-border brands pay attention to?

Most brands we work with in Turkey run on ready-made platforms such as Ticimax, ikas or İdeasoft. The task is not to replace the platform but to audit the product data it emits: check id, price, stock, brand, GTIN and MPN in the feed output; look for inconsistencies between page, schema and feed; establish whether updates travel by file or by API; raise a technical ticket where something is missing. In our internal decks these steps are defined as a discipline called Product Feed Engineering, and the result is re-verified with the Feed Validator.

The target market also changes the shape of the description. In our own export matrix the United States and the United Kingdom are B2C-heavy, Germany B2B-heavy. In B2C markets the focus is the Merchant Center feed and enriched product content; in B2B markets a PIM-based golden record and an API. In the Gulf, Arabic structured product data is an almost empty field; the brand that publishes its description in the target language and in machine-readable form looks unrivalled today. Translating the description is not enough; tariff code, origin and country-level delivery data are part of the description too.

To measure readiness we use a five-dimension score: product identity, data completeness, data consistency, price and stock freshness, platform fit. 0 to 39 not ready, 40 to 69 needs work, 70 to 84 largely ready, 85 and above agentic ready. If identity is 92 and freshness 84 but platform fit is 42, the problem is not the description but how the data is delivered to the platform. You can find your score with the free scan on our Agentic Commerce Readiness page.

Why should product descriptions be rewritten for the agent era?

Everything the classic guide said still holds: know your audience, state the benefit, be original. What changed is who the reader is. The new reader of your product page is an agent; it sees fields not tone, compares numbers not adjectives, reads schema not policy. The brand that writes its product description on two layers, text for the person and data for the agent, tells both readers the same truth.

The order to start with is simple: identity and four-layer consistency first, then the attribute list and Q&A, then delivery and returns data, tone last. The reasoning behind that order is in our protocol map, the way to measure whether an agent finds your brand is in our dark AI traffic article, and the site's overall readiness for agents is in the agent-readiness scan. To audit how an agent reads your product descriptions, talk to our Agent Experience team.