Your GEO report says mentions are up. Your orders are flat.

Both can be true at once, and not because the GEO work was done badly. Product data reaches AI assistants two different ways, by crawl and by feed. They behave differently, different teams own them, and the work most brands are buying only touches part of one of them.

The same split, put as two questions a shopper might ask, answered by two different machines:

"What are the best running shoes for beginners?"

"Wide fit road running shoe under $120, size 11, in stock."

The first gets answered out of text somebody wrote. The second gets answered out of a product record somebody supplied. Generative engine optimization, GEO, the work of getting your brand named correctly inside AI answers, works the first path. Orders come from the second.

One number sets the stakes. Of the ChatGPT product offers that came from a supplied feed, about 99.9% appeared in the first product slot, and the feed's share of retrievals has risen every month. Most offers still come off crawled pages, which is why the window is still open. The rest of this is the mechanism, the evidence, and the parts of the evidence that cut against us.

Where do AI shopping answers come from?

The split that matters is not brand content versus product data. It is how the information physically reaches the model.

The crawl chain. Anything the engine goes out and reads off the open web: your product detail pages (PDPs), and everything written about you elsewhere, from Reddit threads to media reviews to comparison articles. The engine has to find the page, parse it, and infer the fields.

The feed chain. Product records you or your platform supply as structured data, through the pipes built for exactly that: Shopify's Global Catalog, OpenAI's Agentic Commerce Protocol (ACP), a Universal Commerce Protocol (UCP) endpoint, a Google Merchant Center feed. Nothing is parsed out of prose. Fields arrive as fields.

Drawing the line by transport rather than by topic matters for one practical reason: it is the same line the available data uses. Profound, an AI search analytics company that tracks how AI assistants retrieve and cite content, published the study most of the numbers below come from, and it classifies every product offer as coming from a web product page or from a product feed.

The crawl chain holds two different kinds of material, and different teams own them:

  • The editorial slice. Your blog, your brand pages, third-party coverage and discussion. This is what a GEO or AEO engagement works on.
  • The product page slice. Your PDPs, owned by ecommerce and merchandising rather than by whoever does your GEO.

So a brand can be doing serious GEO work and still have nobody responsible for how its product pages read to a machine, and nobody at all responsible for the feed.

Two large labels, CRAWL with a left arrow and FEED with a right arrow. Crawl: the engine comes and reads your pages, then infers the fields. Feed: you send the records; nothing is parsed, and fields arrive as fields. Below, the same six fields a purchasable card needs, compared across the two transports: title, description and price usually survive a crawl; checkout image URL, brand, merchant subtitle and best-price tag arrive from a crawl 0% of the time and from a feed 100%. Payoff: 99.9% of feed-sourced offers land in the first product slot.

A shopping question is not routed once. The AI assistant breaks it into steps and retrieves separately for each, so both chains can be used inside a single conversation, with different weights. This is not a clean either/or.

In our experience the stronger the buying intent, the more the answer leans on the feed chain, because what the shopper wants is a specific product at a specific price in a specific size. That is our reading rather than a measured finding: the study below has no breakdown by query type.

How much of AI shopping already runs on feeds?

There is now data on exactly this split. Allen Wu's Profound study, published on 2026-06-24, covers roughly 548 million product offers across ChatGPT shopping sessions from November 2025 through June 2026, plus a 30 day snapshot of about one million offers.

Three numbers from it, in the order that matters.

One. The feed chain is growing fast. Feed retrieval went from 4.3% of shopping retrievals in late November 2025 to about 20% in the final six weeks of the window, around June 2026, and it rose every month in between. That is a bit under a fivefold increase in seven months. Profound's own summary calls it roughly 15x, a larger multiple than those two shares produce, so the shares are what we cite.

Two. The crawl chain is still much bigger. In the 30 day snapshot, 88.29% of product offers were pulled from product pages rather than from any feed. That does not contradict the first number. The feed chain has not replaced the crawl chain and it will not this year, so anyone telling you that merchants outside the feed chain are already excluded from AI shopping is overstating what the data supports. What the feed chain does is win wherever it appears, and it appears in more answers every month.

Three. Almost nobody has done it yet. Profound's analysis covers 150 unique merchants who have completed a product feed integration with ChatGPT. Not 150 thousand. Against the size of global ecommerce that is the definition of an early window, and it is a more useful argument for acting now than any projection.

Why does a feed almost always win first place?

Of all product citations derived from direct product feeds, about 99.9% appear as the first product offer.

That is not a ranking bonus. When the feed is the source, the feed is essentially always in first position.

The reason is not mysterious. Profound looked at field coverage and found that four attributes appear in product feeds at 100% prevalence and in scraped PDPs at 0%: Checkout Image URL, Brand, Merchant Subtitle, and the "Best Price" tag. These are the fields an engine needs to render a complete, purchasable product card. A product that cannot fill them cannot be rendered as that kind of card at all, whatever else is true about it.

That is the mechanism behind the abstraction "structured data matters." Not that structure is virtuous, but that a card has slots and the slots have to be filled from somewhere.

This is not the same as saying a crawler cannot read your product page. Your page shows a price, and a crawler can often read it. What the crawl does not reliably deliver is the set of fields a purchasable card requires, in the form the card needs them. Those four attributes sit at 0% from PDPs.

This is a correlation, and part of it is likely an artifact of how the engine assembles a response once a feed source is available. It is also not a promise that connecting a feed puts you first.

You connected a feed. Is it being used?

One line in the study does more work than any of the percentages:

"Even for merchants that have already integrated their product feeds with ChatGPT, 75.81% of offers are still derived from web PDPs."

These merchants did the integration. The pipe is connected. Three quarters of the time, the engine still went and scraped a web page instead.

The reasonable reading is not that the integration failed. It is that the feed could not answer the question that was asked, so retrieval fell back to the open web to find something that could. Which reframes the whole problem:

The question was never whether you are connected. It is whether what you sent can answer what people ask. A feed that is rich and on-target gets used. A feed that is thin, generic or off-target gets bypassed in favor of a scrape, and you are back to competing on the crawl chain without knowing it.

Connecting the pipe is a one-time project. Keeping the payload able to answer is not a project at all. It is an operating discipline.

Even without a feed, product context decides the order

Now the finding that cost us our favorite simple story, and gave us a better one.

Profound compared 294,913 rank 1 product offers against 657,282 rank 4+ offers. What separated them was how price and value were expressed, the presence of trust signals such as reviews, and whether the title actually stated what the product is for. Descriptive titles beat clever or niche ones.

That comparison is inside the scraped web page path. These are not feed products. They are pages.

So even when the answer is assembled by crawling, what decides the ordering is product level context, not brand level voice.

Put that next to the feed findings and the real shape of this emerges. The two chains are two transports. The thing that decides outcomes on both of them is the same payload: product context. A feed carries it cleanly and gets rewarded with the first slot. A crawl carries whatever your PDP happens to say, and ranks you on how well that says who the product is for. Neither transport rewards adjective density, and neither of them is fixed by more brand-level content.

What GEO does and does not cover

GEO and AEO, answer engine optimization, work the editorial slice of the crawl chain. They make it more likely that your brand is named, cited and described correctly when someone asks a question that calls for prose. That is real work, it is worth doing, and nothing in the data above says otherwise.

What that work does not reach:

  • Your product page slice, where the crawl chain actually decides product ordering. Descriptive titles and trust signals are merchandising decisions, not content marketing decisions.
  • The feed chain entirely. No amount of authority on the open web puts a variant, a stock status or a checkout image into Shopify's catalog or a Google Merchant Center feed.

So the honest version of the contrarian claim in this article's title is this: GEO covers one of three surfaces, and it is the one furthest from the order. If your AI traffic problem is that nobody names you, GEO is the fix. If your problem is that you get named and never appear as a buyable product, GEO is the wrong budget line.

Two categories dominate the conversation about this, and neither one reaches the feed. Agencies work the editorial slice, and that work is real. Monitoring tools score how often you get named, which is measurement rather than supply. Tooling for the feed side does exist, mostly sold as an integration. But connecting a pipe is a project with an end date and product context is not, so the question that outlasts any vendor choice is who owns it next quarter.

Four gates, not one problem

The complaint we hear most often is "AI never sends us anything." That is not one problem. It is four, and only the first one is a content problem.

Gate The commercial question Which chain feeds it What failure looks like
Mentioned Is the brand in the conversation at all? Crawl chain, editorial slice Never named, described wrong, only competitors appear
Listed Does a specific SKU or variant appear as a product, with correct price and stock? Feed chain, or a crawl of your PDP when a card can be assembled from it Not in the catalog, wrong variants, stale price or availability
Chosen Why should the AI assistant pick this product over the alternative? Both chains, and product context is what decides it on either one Copy too broad to match a constraint, no evidence, so the model has to guess
Bought Does the recommendation survive the click and become an order? Feed chain plus operations Price or stock conflict on arrival, checkout failure, fulfillment mismatch

Four icon cards in a row. Gate 01 Mentioned, named in the answer at all, crawl chain. Gate 02 Listed, shown as a buyable product with price and stock, feed or a crawl. Gate 03 Chosen, picked over the alternative and for the right reason, either chain. Gate 04 Bought, survives the click and becomes an order, feed plus operations. Footer: facts get a product listed, context gets it chosen.

The chains are not perfectly segregated, and under a transport-based split they are not supposed to be. Mentioned is almost purely the editorial slice of the crawl. Listed can be reached either way today, which is what the 88.29% tells you, though only one of the two ways reliably produces a purchasable card. Chosen is decided by product context on whichever transport delivered the offer. Only Bought genuinely needs live, supplied data, because a crawled page cannot be trusted for stock at the moment of purchase. The reason to keep the four apart is that they fail for different reasons and get fixed by different teams, so collapsing them into one AI visibility score guarantees you cannot tell which one is broken.

The short version: facts get a product listed, context gets it chosen. Which is also why we think product selection rate and merchant selection rate end up measured separately, the way paid media separated impression share from win rate. That argument deserves its own piece. Until then, the practical half is picking the queries you measure against.

OpenAI runs two selections, not one

Getting your product recommended and getting your store the sale are two different competitions. OpenAI's own shopping documentation says so, in a passage that is easy to skim past.

Selection 1: which product gets chosen? ChatGPT combines the shopper's question and context, including budget, stated preferences, Memory and Custom Instructions, with your structured product data, third-party evidence such as reviews, and its own policy constraints, to build a shortlist that matches the intent. Part of that list is about the shopper and out of your hands. The rest is about how well your product describes itself.

Selection 2: which merchant gets the sale? Click into a product and a second competition starts. If several merchants sell the same item, OpenAI says the ranking can consider:

  • availability
  • price
  • quality
  • whether you are the maker or the primary seller

In OpenAI's words, merchants are "ranked based on factors like availability, price, quality, and whether they are the maker or primary seller of that item". The merchant shown first is not necessarily the cheapest one.

These two selections sit inside the four gates rather than beside them. OpenAI's product selection is where Listed and Chosen get decided. Its merchant selection is a second contest that only opens when more than one store sells the same item.

ChatGPT shopping makes two selections. Selection 1, which product gets chosen: ChatGPT builds a shortlist from shopper intent and context, product data, third-party evidence, and model and policy context. Selection 2, which merchant gets the sale: it ranks merchants selling the same product on availability, price, quality and seller status. The product selection is where Listed and Chosen get decided.

Which selection matters depends on what you sell. The merchant contest mostly fires on items sold by more than one store: resellers, distributors, marketplace overlap. If you are a DTC brand and the only seller of your own product, it barely applies to you, and "maker or primary seller" works in your favor. Your whole fight is in the product selection, which is to say in Listed and Chosen.

Both platforms are also explicit that being in the system is eligibility and nothing more. Shopify, on being included in Shopify Catalog: it "doesn't guarantee that a product will appear in a specific AI answer, be ranked in a specific position, or be displayed by every channel", and "each channel controls the final ranking." OpenAI's commerce documentation makes the same split, between the fields required to display at all and the attributes that improve ranking. Nobody is promising you a placement. The placement is earned after the plumbing.

Where to actually make the change

If you are on a commerce platform, there is only one place to make the change. Product data is generally not sent to each AI assistant separately. It is written into the platform's catalog, and the platform distributes from there, so the direct recipient of any change you make is the platform catalog rather than ChatGPT or Gemini. Which means "optimizing separately for each AI platform" is mostly a fiction for platform merchants. What varies per platform is which fields get used and how, not where you put them.

So the work is not integration work. It is catalog work, and in our practice it has three parts.

Collect the context that is not in your catalog yet. Who the product is for, who it is not for, what it gets used with, what the return policy actually says, what reviewers keep repeating. Most of this already exists somewhere in the business, in support tickets, in reviews, in a founder's head, and almost none of it is in a product record.

Write it in the form the fields expect. Not as more prose in a description block, but as the attributes, variants, availability and media a purchasable card gets assembled from. This is the part that decides whether a feed gets used or bypassed.

Then keep revising it against what actually happened. Which questions surfaced you and which did not, which phrasing the answer picked up. Product context is not a migration you finish. It is a data set somebody owns and keeps current, the way somebody already owns inventory.

That loop is what we build for merchants, and we wrote up what it looked like across the first 18 catalogs. The first two parts are the ones a merchant can start without us.

One implementation detail: for platform merchants, syncing product data into Google Merchant Center can depend on a store level setting. Having a store on a platform is not the same as having your products in the feed.

Getting your data right is necessary. It is not sufficient.

Our own testing makes the same point from the other direction.

We tested one merchant's product across four AI surfaces and all four reported an in-stock product as backordered. One invented a 25% restocking fee against an actual policy of 20%, a number that appears nowhere on the merchant's site. Another misidentified the brand because of conflicting structured markup. After the data was fixed, the accuracy errors went to zero. Category visibility did not move. Accuracy and selection are independent dimensions, and fixing one does not deliver the other.

Which chain are you stuck on?

Two minutes, logged out, because your own history will hand you a flattering answer. Pick one product, ask a plain category question, then ask it again with a hard constraint attached: a size, a fit, a price ceiling. Read two things, and do not start by looking for your own name.

  • Did any answer list you as a product, with a price and a stock status, rather than naming brands inside a sentence? That is the card question, and it turns on whether the fields a card needs arrived at all.
  • Were you there on the plain question and gone once the constraint was added? That is the context question. The engine knows what you sell and not who it suits.

Absent from both is the usual first result, and the least informative one, because everything can be failing at once. The next step is not another prompt: check whether your products are in your platform's catalog at all, and whether the feed setting is on. Answers also move between sessions and locations, so one pass is a sample rather than a ranking.

Is it worth the work?

One health hardware brand we work with saw about 3.6% of its visits from AI surfaces turn into orders, against about 1.8% of site-wide visits, at an average order value over $200. The site did not change. The catalog did. Attribution is last click from our own dashboard rather than a third party, the case count behind numbers like this is in the single digits, and there was no control group, so read it as case evidence about traffic quality rather than proof of cause. The reason it is still worth reporting is the part that surprises people: these are not cheap commodity orders.

The bottom line

Three surfaces decide whether an AI assistant sends you an order: the editorial slice of the crawl, your own product pages, and the feed. GEO works the first one, and works it well. The order gets decided on the other two, and both of them read fields rather than paragraphs.

Three things worth doing regardless of who you work with.

  • Ask the three questions above about one important product, and note where you drop out.
  • For your top five products, write the line you have never written: who this product is not for.
  • Decide who owns product context as a data set, the way someone in your company already owns inventory.

The question we have not answered yet is whether buying intent actually shifts retrieval toward the feed chain. Profound's study has no breakdown by query type, so nothing published settles it. That is a measurable question and it is the next one on our list.

Facts get a product listed. Context gets it chosen. If you want that done across a whole catalog rather than five products, connect your store to Nile.