How to optimize a product feed for search and AI agents

This is the correction practitioners keep having to make, so it belongs at the top. Submitting a product feed gets your items into a system's inventory of things it could show. It does not decide whether they get shown.

OpenAI's merchant feed carries two separate eligibility flags, one for appearing in search results and one for in-chat checkout. Eligibility is the entry ticket. After that, an assistant weighs whether your item answers the question, whether the data is current, and whether it can defend the recommendation to the person who asked.

The second half of that judgment reads your store rather than your file. Assistants pull from product pages, policies, and structured data on the page as well as the feed, which is why brands with a clean feed still watch a competitor get named for the query they thought they had covered.

We read 22 live DTC catalogs on 10 August 2026, 1,017 products and 8,424 variants, to see what a feed built from them would actually say. The median product description ran 46.5 words. Five of the 22 stores sat under 25.

That is enough for a fabric, a color, and a mood. It is not enough to say who the product is for, what it is worth wearing with, how it fits against the size above it, or which of the three questions a shopper actually asked it answers. A system that has to justify a recommendation reaches for that material and finds a mood.

The fix is unglamorous and it is not a mapping rule. Descriptions get longer by someone writing the attributes down, which is why most feed optimization projects stall at exactly this step.

Identifiers are the second lever, and they fail quietly. Across the 8,424 variants we read, 15% carried no SKU. On the product pages, 6 of 22 exposed a GTIN or MPN in their structured data.

An item with no identifier cannot be reconciled with the same item sold anywhere else. Price comparisons skip it, availability checks cannot confirm it, and an agent asked to find the best price on a specific product has no way to know your listing is that product.

Roll-up matters as much as the identifier itself. OpenAI's feed reference is explicit that a file carries one product or variant per row. When sizes are flattened into an options string instead, an assistant can say the product exists and cannot say whether the medium is in stock. The operational side of that work is covered in product feed management.

• SKU on every variant. It is the minimum unit of being referred to.
• GTIN wherever one exists. Private label and bundles are the legitimate exceptions, and MPN plus brand covers those.
• Variants as rows, not as text. One row per buyable thing.
• One identifier scheme everywhere. The feed, the page markup, and the order record should agree on what the product is called.

Optimizing the file while the page contradicts it is the most common way this work gets wasted. Google names conflicting data between your feed and your website in its own list of what causes disapprovals, alongside missing identifiers and missing variant attributes. If the feed says 89 dollars and in stock while the page says 79 dollars and back-ordered, you have taught two systems two different facts about one product.

Structured data on the page is where that agreement is usually broken. On the 22 stores we read, 17 carried Product markup, 17 stated availability, and 10 named a SKU. The markup is present and the fields underneath it are half filled.

Access is worth checking too. Eight of the 30 verified Shopify stores in the sample blocked or broke their public catalog endpoint. That is a defensible choice, and it means every reader now depends entirely on the feed you publish and the pages you render, so both have to carry the whole story.

Ordered by what returns the most for the least. The first three are data work. The last three are hygiene that stops the first three from decaying.

• Find every product under 50 words and rewrite the worst 50 first. Sort by revenue, not alphabetically.
• Fill the empty description field. An empty field is a product that cannot be recommended at all.
• Add SKU to every variant, and GTIN where one exists. Then confirm both appear in the page markup as well as the feed.
• Reconcile price and availability between feed and page, and pick the update frequency your inventory movement actually requires.
• Check what your product page renders without JavaScript. Structured data that only appears after hydration is structured data most crawlers never see.
• Re-read your titles as a stranger. Internal naming conventions and size codes in a shopper-facing title cost you the first-pass match.
• Confirm your images show the product, not a lifestyle crop where the item is 8% of the frame.
• Watch what assistants say about you after the changes land, because that is the only place the result shows up.

Nothing on that list is a mapping rule. Feed tooling moves data faster and has no opinion about what the data says.

Kinect reads your catalog, writes the attributes that were never captured, and keeps that enriched record consistent on your product pages and in the feeds leaving your store. It is the step the checklist above stalls on, done once and then maintained.

The same intelligence runs an AI sales rep on the storefront, so the data written for machines also answers the shoppers already there. Brands running Kinect see 3 to 6% more revenue, measured against their own baselines. It is an integration rather than a theme rebuild, and it goes live the same day.