How to Optimize Ecommerce Product Feeds for AI Search in 2026

Adobe Analytics measured traffic from generative AI sources to US retail sites climbing 1,300% year over year across the 2024 holiday season, and it kept accelerating right through 2025. The people arriving that way behave differently once they land, spending around 32% longer on site and viewing roughly 10% more pages before they buy. The part almost nobody optimizes for is the step that happens before any of that, the moment an assistant decides which products are worth naming at all.

That decision rarely happens on your product page. ChatGPT reads a structured merchant feed as its primary source of truth about your catalog, and Google grounds its AI shopping answers in the same Merchant Center data that already powers Shopping ads. So the real question for an ecommerce brand has moved past how your pages rank. It is now whether the data behind those pages gives an AI enough to recommend you with any confidence, and most feeds still do not.

Why AI assistants read your feed before your page

A large language model does not browse your site the way a shopper does, clicking through a filtered product listing and reading the fine print. It works from structured data it can parse cleanly, and for products that data lives in your feed. OpenAI's product feed spec makes this explicit, treating the merchant feed you submit as the authority on your own catalog, refreshable as often as every fifteen minutes, with core fields that a product cannot appear without. Google's version is the Merchant Center feed, the same pipe that feeds Shopping now also feeding AI Mode and Gemini's shopping answers. When your rich product page and your thin feed disagree, the assistant trusts the feed, because that is what it was built to read. This is where AI Search for ecommerce actually begins, well upstream of the content and schema work most teams start with, and it is also why a beautiful PDP with an empty feed loses to a plain competitor whose feed is complete.

Answer real buyer questions inside the feed

In 2026 Google added a set of conversational attributes to Merchant Center, and the first one, question_and_answer, lets you attach up to ten question and answer pairs directly to a product. The point is to hand an assistant the exact questions your buyers ask and the answers you would give, so it can lift a clean response into a conversation instead of guessing from your description. OpenAI's feed spec carries the same idea with its own q_and_a field, which tells you both major AI shopping surfaces want this information supplied rather than inferred.

The questions worth putting there are the ones that decide a purchase, and you already have them. They sit in your support tickets, your on-site product Q&A, your reviews, and the reasons written on returns. "Will this fit a 2019 Civic." "Does the plug work with European outlets." "Is the cover machine washable." Each of those is a moment where a shopper stalls, and answering it in the feed removes the stall before a human ever reads the page.

Keep each answer plain and specific to one question, and resist turning the field into another marketing slot. An assistant quoting your answer to a nervous buyer is doing sales work for you, and it can only do that if the answer reads like a straight reply rather than a tagline.

Map the products that belong together

The related_product attribute lets you connect an item to as many as five others in your catalog and label how they relate, using relationship_type values like required_part, often_bought_with, substitute, different_brand, and accessory, each paired with the product's identifier. It is the same structure OpenAI uses, down to nearly the same relationship names, so the mapping you build once travels across surfaces.

For an AI agent trying to assemble a complete answer, this is the difference between naming your product and actually solving the shopper's problem. Someone buying a camera body needs the compatible battery and the lens that fits, and if the model they asked about is out of stock, the assistant needs a substitute you would endorse rather than a competitor it picks on its own. Spell those relationships out and the assistant cross-sells your catalog for you, inside the answer, at the exact moment intent is highest.

Tell AI which products actually sell

When a shopper asks for the best or the most popular option in a category, the assistant has no window into your sales unless you give it one. The popularity_rank attribute is how you do that, expressed as a percentage of your own inventory, where a value like 95.5 marks a product that outperforms almost everything else you carry. OpenAI's spec offers a parallel popularity_score on a zero to five scale, so the signal is portable.

Base the number on real sell-through, not on the margin you wish you were moving, and refresh it as your catalog shifts through seasons and launches. An assistant that learns to trust your popularity signal will keep surfacing your genuine best sellers, and a signal you have inflated to push slow inventory tends to get exposed the moment the recommendation collides with reviews and return rates that say otherwise.

Clear up sizes, specs, and variants

Variants are where AI shopping answers go wrong most often, recommending the 55-inch television when the shopper measured for the 65, or the wrong thread on a replacement part. The variant_option attribute exists to prevent that, letting you describe up to five variant-defining properties as name and value pairs, color and moonstone, size and king, tied together through item_group_id so the assistant understands one product line rather than a pile of unrelated SKUs. OpenAI handles the same job with its variant fields and a size_system code for apparel.

This matters most for the products where a wrong pick is expensive to return, mattresses and their overlapping size charts, screws and their thread pitches, clothing sold across US, UK, and EU sizing at once. The more precisely you spell out each dimension, the less the assistant has to interpolate, and interpolation is exactly where it invents a spec that is not real.

Complex catalogs are the ones that benefit most here, because they are also the ones where a human shopper gives up and asks an assistant to sort it out. Give that assistant clean variant data and it becomes a reliable narrator of your range instead of a source of confident mistakes.

Attach the manuals and spec sheets

The document_link attribute takes up to five PDF URLs per product, meant for the manuals, assembly guides, compatibility sheets, and safety documents that sit behind a technical purchase. For anything with a real spec, an appliance, a power tool, a piece of hardware, this is often where the buyer's actual question lives, and it is content you already produced and rarely surface. Linking it in the feed lets an assistant point a shopper to the manual or pull a specific figure out of it, which turns a document you buried on a support page into something that closes a sale.

Give the whole product family one name

The item_group_title attribute gives a single parent name to a product that ships in several variants, Google Pixel 9 standing over every color and storage tier beneath it, and it works alongside item_group_id to keep the family bound together. It reads like housekeeping, and it is, but it is the housekeeping that lets an assistant parse your catalog as coherent product lines instead of thousands of loose entries. Without it, a large range fragments into hundreds of near-identical rows that an AI struggles to reconcile, and it starts treating variants of one product as separate products competing with each other. When the parent is named clearly, the whole hierarchy underneath it inherits that context, and the assistant can talk about your product the way a person does, one thing available in a few forms. On a big catalog this single field does a lot of the work that keeps the rest of your variant data legible.

Where the feed fits in an AI Search program

None of these attributes work in isolation, and none of them replace the rest of the discipline. AI Search for ecommerce runs on two things at the same time, the structured feed an assistant reads to know what you sell, and the authority that decides whether it trusts you enough to recommend it. The feed makes you eligible. Authority makes you the answer.

That authority is what the two frameworks I run are built to construct. Topic Ownership Strategy earns you the query space around your products, a pillar and its clusters covering the what, why, compare, benefits, reviews, and buy intent that surround a category, so the assistant keeps meeting your brand wherever the buyer's research leads. Total Graph Authority is the strength that sits behind it, measured across the entity, citation, link, content, and interaction graphs an AI reads, with your reviews and reputation feeding the citation graph that acts as the bridge between how people talk about you and what an assistant is willing to repeat. A complete feed with weak authority gets you listed. Strong authority with a broken feed gets you overlooked. You need both moving together.

Start with the data an assistant can read

The brands showing up inside AI shopping answers are the ones whose feed can resolve a buyer's real question without a human in the loop, and the six attributes above are the most direct way to build that, provided you keep them accurate as your catalog changes. Most competitors have not touched any of this yet, and that is the opening, because the feed is a place you control completely and can fix this quarter.

If you want to see how ChatGPT, Gemini, and Google's AI Mode currently describe and recommend your catalog, and fix where they get your products wrong before the rest of your market catches on, here is how to work with me.