THE SHORT ANSWER
ChatGPT product surfaces assemble results from merchant feeds, Product and Offer structured data on the open web, and live browsing of retailer pages. The controllable inputs are a clean product feed, accurate schema with price, availability and currency, and consistent product naming across every place you are listed. This area is changing faster than any other part of AI search, so treat specific mechanics as provisional and monitor rather than assume.
Shopping inside an assistant is the least stable part of AI search, and anybody presenting it as a settled discipline in 2026 is guessing. The surfaces have been rebuilt repeatedly, merchant programmes have opened and changed terms, and what a given assistant shows can differ by country within the same week. That is worth saying up front, because the cost of building on a mechanic that disappears is high.
What has been stable is the underlying dependency. Assistants recommending products need machine-readable facts about those products: a name, a price, a currency, whether it is in stock, who sells it and what buyers said. Wherever the surface goes next, that dependency stays, which is what makes the preparation work safe even when the interface is not.
The numbers, at a glance
Three input routes: merchant product feeds, Product and Offer structured data crawled from the open web, and live browsing of retailer pages during a session
The four fields that decide inclusion: product name, price with an explicit currency code, availability status and a canonical product URL
Most common disqualifier: a price shown only as rendered text in an image or loaded by script after the crawl, leaving no readable value
Stability warning: shopping surfaces changed several times between 2024 and 2026, so build on feed and schema quality rather than on any one interface
Where an assistant gets product facts from
Three routes feed the same answer, and a product can arrive through any of them. Understanding which one you rely on determines what you can fix.
Direct merchant feeds. Structured catalogues supplied by the retailer under a programme agreement. Highest fidelity, updated most frequently, and available only to merchants who have joined.
Crawled structured data. Product and Offer markup read from ordinary product pages. Open to everyone, slower to refresh, and only as good as the markup.
Live browsing. The assistant fetches a page during the session and reads it like a person would. Most current, least reliable, and completely dependent on the page rendering readable text without script execution.
For a business without a merchant programme relationship, routes two and three are the whole game, and both reward the same discipline: put the facts in the HTML, in text, with the right properties around them.
The markup that carries the most weight
Product markup is widely implemented and widely implemented badly. The properties that consistently matter are name, image, description, brand, sku or gtin, and a nested Offer carrying price, priceCurrency, availability and url. Add aggregateRating and review only where the ratings are genuine and visible on the page, because fabricated review markup is one of the few things that reliably gets a site penalised rather than merely ignored.
Two specific errors account for most failures. First, price expressed with a currency symbol inside the price property instead of a bare number with priceCurrency set separately; parsers frequently discard the whole offer. Second, availability values written as free text rather than the schema enumeration, so a perfectly stocked product reads as unknown. Both are five-minute fixes that nobody finds because rich-result testers pass them with warnings rather than errors.
Naming consistency, and why it decides more than markup quality
Assistants match products across sources by name and identifier. If your own site calls it one thing, your marketplace listing calls it another, and your specification sheet uses an internal code, the system sees three weakly related items rather than one well-evidenced product, and confidence drops below the threshold for recommendation.
Pick one canonical product name and one identifier, then propagate them everywhere: your site, marketplaces, comparison sites, distributor listings, spec sheets and press material. This is duller than optimising markup and has more effect, because it raises the evidence count behind a single entity rather than adding a property to one page.
What this means if you sell a service rather than a product
Product schema fits a boxed item and fits a fitted heat pump badly. The nearest correct types are Service with an Offer, or Product where the deliverable genuinely is a supplied item such as panels or a boiler. Forcing service work into Product markup with an invented price produces answers that quote a number no customer can actually buy at, which is worse than being absent.
The workable pattern for installers and suppliers is to publish a price range with the conditions attached in readable text, mark the page up as a Service with an areaServed and an Offer carrying a priceRange, and let the assistant quote the band rather than a false point figure. Assistants handle ranges well and are visibly more comfortable citing a source that qualifies its own number.
Getting product facts into a state an assistant can use
Validate that every product page emits price as a bare number with a separate currency code.
Replace free-text availability with the schema enumeration values on every template.
Choose one canonical product name plus one identifier and roll it out across every external listing.
Remove any rating markup that is not backed by reviews visible on the same page.
Ask two assistants for your product by name each month and record what price and availability they state.
Want leads like this in your pipeline?
Flock runs the campaigns, screens the enquiries and hands you only the ones that match your service area, job size and capacity. You pay per lead, not per month.
Book a 15-minute fit check | See lead package pricing
Related answers
Frequently asked questions
Do I need to join a merchant programme to appear?
Not necessarily. Crawled structured data and live browsing can both surface a product without any commercial relationship. A merchant feed gives faster refresh and more control over price and stock accuracy, which matters most for high-turnover catalogues and much less for a short, stable product range.
Why does an assistant quote an old price for my product?
Almost always because the current price is not machine-readable: it sits in an image, arrives via script after the crawl, or lives behind a configurator. The assistant then falls back on a cached page or a third-party listing. Putting the number in plain HTML text fixes it faster than anything else.
Does having reviews help?
Yes, and specifically the count and the recency rather than the average. Assistants describing a product tend to mention how many people rated it, because volume is the part a reader can verify. A four-star average across three hundred reviews outperforms a perfect score across four.
How stable are these mechanics?
Less stable than anything else in this field. Interfaces and programme terms have shifted repeatedly since 2024. Invest in feed accuracy, markup correctness and naming consistency, which survive every redesign, rather than in tactics tied to a specific shopping panel.
NEED A CLEARER PLAN?
Let’s turn your next move into momentum.
Talk to us →