How ChatGPT, Gemini, Perplexity and Copilot choose which products to name, which GEO advice is real, what to fix in your product data and feeds, how to measure AI referrals, and a ten-point checklist.
Author
Anichur Rahaman
Part 1 of this series followed the owner of a small outdoor-gear store whose best-selling jacket an AI shopping agent never showed. She fixed her product data, and agent orders began to arrive. Now, on a Tuesday at 8:40 in the morning, she tries a different door. She types into a general AI assistant what a customer might type: "a waterproof jacket under 150 dollars that arrives by Friday." Four jackets come back, each with a reason and a link. Her best seller, at $129, is not among them.
When she looks into it, the problem is not ranking. Her page says $129, but her product feed still carries last month's $159, and lists a size as in stock that the page shows as sold out. The assistant met two versions of the same product, could not verify either, and named neither. (The numbers are illustrative, not a real store.)
That changes the question for a store owner. The old question was "how do I rank?" The new one is "will the assistant know my product exists, trust my data, and name it?" The practice built around it is called generative engine optimization, or GEO. Below: how assistants assemble recommendations, which GEO advice holds up, what to fix in product data, how to measure the result, and a ten-point checklist.
This is part 2 of a three-part series, "Selling to AI Agents". Part 1 explained what agentic commerce is and what was live by August 2026. Part 3 covers agent-ready checkout and payments.
Each assistant is built differently, but the shape of the process is similar. It reads the request, gathers candidates from several kinds of sources, drops what it cannot verify, then writes a short ranked answer.
The sources fall into four groups:
Step three is where recommendations are won or lost. A product with a missing price, a conflicting stock figure or no stated return policy is not ranked lower. It is usually just left out, because an assistant that recommends something it cannot back up looks bad. This is the same "invisibility" risk described in part 1.
Much of what is sold as GEO is ordinary SEO with a new label. Google says so directly: in its guidance on AI features in Search, it states there are no additional requirements to appear in AI Overviews or AI Mode, no special files or markup to add, and that standard SEO best practices still apply (Google Search Central).
What does change is the emphasis. The table below compares the two.
| Question | Classic SEO | GEO for stores |
|---|---|---|
| What is the goal? | Rank a page for a keyword | Be named in an answer, with a link |
| Who reads your page? | A crawler, then a person | A retrieval system that quotes or summarises it |
| What wins? | Relevance, links, page experience | Verifiable facts, consistent data, independent proof |
| Which content helps most? | Pages targeting a search phrase | Pages that answer comparison and "best for" questions in plain language |
| How do you measure it? | Rankings, clicks | Referrals from assistants, mentions, orders by source |
| What do you submit? | A sitemap | A sitemap plus product feeds where platforms accept them |
Keep doing the SEO basics, and add a second layer of work on product data and independent proof.
Search engines learned to read product pages years ago, and assistants build on the same signals. Four pieces matter most.
A GTIN (the number under a barcode), or a brand plus MPN for products without one, lets a system recognise that your listing and a competitor's listing are the same item. Without an identifier, you are matched by title, and titles are messy.
Use schema.org markup in JSON-LD. For a store, the useful types are Product, Offer (price, currency, availability), AggregateRating and Review, plus MerchantReturnPolicy and OfferShippingDetails for the policies. Google documents these as product, merchant-listing and return-policy structured data. The markup is not a ranking trick. It is a machine-readable copy of what is already on the page.
The price in the markup, on the page and in your feed must match, and must match what the cart charges. Mismatches are the most common reason a feed is rejected and a product is distrusted. This is a data-architecture problem: if price and stock are edited in three places, they will drift.
"Free returns within 30 days, you pay nothing, refund to the original payment method in five working days" is a fact. "Easy returns" is not. Publish delivery cost and time by region, cut-off times and the return window as plain sentences, and mirror them in markup.
A feed is a file listing your products, uploaded to a platform on a schedule. As of August 2026, the situation is more open than a year earlier, but it differs by assistant. Check each programme's current terms before you rely on any of this, because they change often.
| Surface | How product data gets in | What to do |
|---|---|---|
| Google AI Mode, AI Overviews, Gemini shopping | Google's Shopping Graph, fed by Merchant Center and by page markup | Set up Merchant Center, enable free listings, keep the feed fresh |
| ChatGPT | OpenAI's merchant programme accepts product feeds, in its own JSONL format or in Google-compatible CSV or TSV | Apply through the merchant programme and keep availability current. Hosted platforms may supply data for you |
| Perplexity | Merchant Program that works with Google-style product feeds | Enrol and reuse your Merchant Center feed |
| Microsoft Copilot | Copilot Merchant Program, based on Microsoft Merchant Center | Submit a clean feed with return and support policies |
First, the Google-style product spec has become the common language: most of the surfaces above can take it, so one well-kept feed does most of the work. Second, OpenAI's own feed specification requires nine fields for every row: item ID, title, description, URL, brand, seller name, image URL, availability and price with a currency code (OpenAI developer documentation). If you cannot fill those nine fields reliably for your whole catalog, fix that before anything else.
Part 1 noted that ChatGPT's in-chat checkout was scaled back in March 2026. The feed still matters, because it supports discovery even when the purchase happens on your own site.
Assistants answer questions like "best for small kitchens", "alternative to brand X" or "which one lasts longest". Your site can answer those questions better than anyone, because you know the product.
Try this test: read your product page as if you were an assistant with no photos. Could you tell who the product is for, what it costs, when it arrives and what happens if it does not fit?
You will see advice to add an llms.txt file to your site. Its status as of August 2026 is below.
llms.txt is a proposal, not a standard. It was suggested in 2024 by Jeremy Howard as a markdown file that points AI systems to the most useful pages on a site, and it is documented at llmstxt.org. No standards body governs it. Google's guidance says you do not need new machine-readable files or AI text files to appear in its AI features, and Google's John Mueller has said publicly that no AI system currently uses llms.txt. An SE Ranking analysis of about 300,000 domains also found no measurable link between having the file and being cited more often by AI assistants.
It costs little to publish, and it can be reasonable for documentation sites. For a store, it is not where your time pays back. Product data, feeds and independent proof are.
Assistants send visitors, but they do not always label them clearly. A practical approach has four parts.
Expect small numbers at first. The value of the tracking is learning which pages and products the assistants prefer, so you can copy what works.
When a product is missing from answers, run four checks in order. Each one gates the next: perfect markup on a page that is not indexed changes nothing.
The third check is the one that tends to recur, because crawling and markup are set up once, while price and stock change every day. The jacket in the opening scene was lost to one stale feed row.
Run through this in order. Each step supports the next.
If you do only steps one to five, you will already be ahead of many stores, because they fix the data every other step relies on.
Back to the owner and her $129 jacket. Once she made the product record the single source for page, markup and feed, the stale $159 row disappeared. A month later she asked the assistant the same question, and her jacket came third of four, at the right price, with the return window quoted. The jacket had not changed. Only the data had. (Still the same illustrative scenario.)
Being recommended is only half the job. When an assistant sends a shopper to you, or tries to complete the purchase itself, the checkout and the payment have to work for an agent as well as for a person. Part 3 covers that: how agents pay, what guardrails exist, and how to keep fraud and refunds under control.
Anichur Rahaman is a software architect and the creator of StoreConsole. He designs commerce and ERP systems for growing businesses, with a focus on event-driven architecture, data integrity and self-hosted operations.
About the Author
Anichur Rahaman
Continue Reading
