How AI assistants choose which stores to recommend

The answer is the new results page

When a shopper asks an assistant which cooling mattress topper to buy, they get three to six brand names, with reasons, and links. Nobody scrolls to position eleven of an answer. If your brand is not in those names, you lost a buyer your analytics will never show you, because the click that did not happen leaves no trace.

I sample these answers professionally across ecommerce niches, and the pattern is consistent: in most categories, roughly four in ten stores that rank respectably in classic search are absent from the AI answers for their own products. The two systems overlap less than people assume.

Where an answer actually comes from

Two layers produce every shopping recommendation, and they move at different speeds.

The model's prior. What the model absorbed in training: reviews, comparison articles, forum threads, press, your own site as it existed months ago. This layer changes slowly. It is why legacy brands get named for categories they no longer lead.

Live retrieval. Modern assistants search the web while answering and read a handful of pages before they write. This layer changes as fast as the pages it reads. It is where a mid-size store can win, because the assistant is choosing sources at answer time, and the best-documented option gets quoted.

The practical consequence: you influence the prior over quarters by existing in the corpus, and you influence retrieval this month by being the page worth citing when the question is asked.

What the engines can and cannot read on your store

Retrieval reads your server HTML, not your intentions. Three checks decide whether your store is quotable.

Product schema with offers. Structured data that carries price, availability and ratings in the initial HTML gives an engine facts it can repeat safely. A surprising number of themes emit Product schema with no offers block, which is a spec sheet with the numbers torn out.

"@type": "Product",
"name": "Alpine Down Parka",
"offers": {
  "@type": "Offer",
  "price": "289.00",
  "priceCurrency": "USD",
  "availability": "https://schema.org/InStock"
}

Answers written in text. If your category page is a grid of images under a one-line heading, there is nothing to quote. The pages that get cited answer the buyer's question in words: who this product suits, how it compares, what it costs, what the trade-offs are. Spec tables in HTML, not in a JPEG.

Server-side rendering. Content that only exists after a JavaScript framework hydrates is content some retrieval systems never see. View source; if your product facts are not in it, you are invisible to the cautious half of the machines.

Being citable beats being clever

There is no durable trick for injecting yourself into answers, and the people selling one are selling the 2026 version of keyword stuffing. What works is duller and compounds: be the option that is easiest to recommend accurately.

That means comparison pages that name competitors honestly and specify who each option suits. Original numbers nobody else has: your sizing data, your return rates by category, your measured durability tests. Buying guides with concrete prices and dates. These are the assets assistants quote, journalists link, and the next training run absorbs. One honest comparison page tends to outperform ten optimized-but-empty category descriptions in answer share, because the assistant's job is to transfer trust, and it can only transfer what you documented.

Measure it like a channel

This only becomes an asset when you stop spot-checking and start tracking. Fix a query set in your buyers' words, twenty to forty questions across your money categories. Re-run it monthly, same wording. Track three numbers per question: are you present, how are you described, and who else is named. Share of answers over time is the metric; everything above is how you move it.

Treat it exactly like rank tracking circa 2010: unglamorous, monthly, and the first mover in each niche gets a lead that is expensive to take back.