The AI Search Mistake That Costs Ecommerce Sites Sales: Publishing Once and Never Circling Back
AI search does not work off a single page, so the most expensive mistake an ecommerce operator can make is treating a product or category page as a one-time publishing task; instead you need fan-out coverage, which means the same answer showing up in many places, phrased many different ways. A model receives a question from a shopper, breaks it into sub-questions, searches several of them at once, and stitches together a reply from whichever blocks it can lift most cleanly. Ranking in AI search in 2026 depends less on any one hero page and more on whether your store owns the whole cloud of related questions around a product. That is the practical difference between competing for ten blue links and optimising for the answer a model gives, which the industry now calls Generative Engine Optimization.
The SEO.Domains Mastery Summit in Sofia, running 9 to 11 September 2026, has built its agenda around aged domains, PBNs, authority transfer and LLM visibility. Its sessions are deliberately not recorded, so speakers can share live experiments and it means whatever is shared in the room does not reach the open web unless an attendee writes it up. This piece is a working guide for operators who would rather run the steps than wait for the write-ups.
Step 1: Understand what fan-out actually does before you change anything
Fan-out is the moment a model turns one shopper question into a dozen internal queries and searches them in parallel. A person asks an assistant "what is the best waterproof backpack for commuting with a laptop", and the model expands that into cheaper sub-questions such as waterproof backpack laptop compartment dimensions, backpack that fits a 16-inch laptop, how to clean a waterproof backpack, and whether a roll-top or zip closure keeps rain out. It then answers from whatever content it finds on each. This is why AEO, or Answer Engine Optimization, is a coverage problem rather than a page-optimisation problem.
Two mechanisms matter here. The first is embeddings, which let a model match "laptop" with "notebook", or "refund" with "return", without an exact keyword match. The practical consequence is that you do not need to repeat a keyword mechanically, but you do need to use the full range of natural language your customers use. The second is chunking, which describes how AI systems read small self-contained blocks rather than whole pages. A 500-word block of warm-up copy may never be read, because the model indexes that block on its own and finds nothing worth lifting.
Together, fan-out, embeddings and chunking mean your job is to publish many small, self-contained, plainly worded answers on the same subject, across more than one page.
Step 2: Map the fan-out for your five most valuable products
Before writing anything, list the sub-questions a model is likely to fire off for your top products. Do this per product, not per site. Open a spreadsheet with one row per sub-question and one column for the question in the shopper's own words.
- Write the main buying question as a shopper types it, including the messy bits: "cheap waterproof backpack that doesn't look like a hiking bag".
- List the attribute questions (dimensions, weight, materials, closure type, warranty length).
- List the comparison questions (this versus the model above it, roll-top versus zip, coated nylon versus TPU).
- List the anxiety questions (will it actually survive a downpour, does the laptop sleeve fit a 16-inch machine, what happens if the seam fails).
- List the use-case questions (commuting, cycling in winter, cabin bag for a budget airline).
You will usually end up with 15 to 40 sub-questions per product. That list is your content plan for the next quarter. If you want to pressure-test it against how a model would actually expand the query, you can talk it through on a call (https://seojesus.com/clickbomb-strategy-call/) rather than guessing in isolation, but the list itself you can build today with a blank document and twenty minutes.
Step 3: Give every sub-question its own self-contained block
Each answer block should open with a direct factual answer the model can lift in one line. Everything after that line is supporting detail.
Take this structure and apply it to every item on your fan-out list:
- The liftable line: a single sentence that answers the question completely, with the number or fact in it. "The roll-top closure keeps rain out in sustained heavy rain because there is no zip seam exposed on the top face."
- Two or three sentences of support: material, test conditions, why the alternative is worse.
- The qualifier: when this answer does not apply.
- A question-phrased heading above it: "Does a roll-top backpack keep a laptop dry?" rather than "Closure systems".
To help a model match a block to the question a person asked, headings can be phrased as questions. If you have a technical product with specifications, put the specification answer in plain HTML in the same block, because A model is blocked from reading an answer when it is buried in JavaScript. If your size guide renders through a script that populates a table on the client, the model sees an empty space. Ship the values as text.
Step 4: Spread the coverage across a hub and spokes
One long page cannot cover 40 sub-questions without becoming unreadable. Split it deliberately.
The hub is the product or category page, and it answers the top three commercially loaded questions. The spokes are supporting pages that each own one cluster: a care and cleaning page, a sizing page, a materials comparison page, a use-case page, a returns page written to answer questions rather than to state policy. Each spoke links back to the hub with descriptive anchor text. This is ordinary internal linking, but the purpose is different. You are not passing link equity primarily, you are giving the model a dense map of one subject so that when it fans out, it finds you on four of its ten sub-queries instead of one.
Step 5: Make sure the model can actually crawl the spokes
A well-covered site that no AI crawler reads scores nothing. Ordinary analytics will not show you this traffic, because AI crawlers often appear only in your raw server logs.
Ordinary analytics records no AI crawler user agents, whereas server log analysis reveals them. Do this once a month. Filter your access log for known AI agent strings, then check three things: are the spokes being fetched at all, are they returning 200 rather than 403 from a badly configured firewall rule, and how often is something being fetched. If a security plugin is blocking AI agents wholesale, your fan-out coverage exists on paper and nowhere else. Compare what you find against your platform analytics and you will see the gap immediately.
Step 6: Reinforce the entity behind the answers
Models do not just match text, they match entities. Your brand is an entity, and it is verified by consistency across the open web rather than by anything on your own domain. Strengthening entity verification depends on name, address and description being consistent across directories. In ecommerce terms: the same business name with the same description and the same contact details on your About page, your footer, your review platforms, your marketplace seller profiles and your trade directories. Inconsistency here is common and quietly expensive, because a model reconciling two versions of your business has less reason to treat either as authoritative.
If you buy or hold a second domain for a niche, note that aged domains carry existing authority that transfers to the pages published on them. That is one of the themes the summit agenda covers, and it is worth understanding before you start publishing a hub and spoke structure on a fresh domain when a stronger one is already in your portfolio.
| Layer | What it covers | Where it usually breaks |
|---|---|---|
| Hub page | Top 3 commercial questions | Product copy written for humans only, no liftable answer |
| Spoke pages | Attribute clusters, use cases, care, returns | Never published, or published as blog posts with no internal links |
| FAQ block | Anxieties phrased as typed questions | Answers buried in accordions or JavaScript |
| Entity layer | Brand consistency off-site | Different descriptions on every directory |
| Crawl layer | AI agents reaching the pages | Firewall blocking agents, no log review |
Every layer is cheap on its own; the failures come from leaving one of them empty, because a model that finds you at the hub and nowhere else still has little to quote.
Step 7: Phrase your FAQ the way people actually type
Your FAQ block should phrase questions the way a person types them into an assistant. "Do you refund postage on international returns" beats "Returns policy". The difference is not cosmetic: conversational phrasing matches the shape of the fan-out query, and the answer below it can be lifted as a single chunk if you keep it to a standalone opening sentence plus a short qualifier.
Add a comparison table on the pages where a real one helps, such as two closure systems or two bundle tiers. Put a one-sentence takeaway directly beneath it, because instant-mode models skip table rendering and will only carry the sentence. The table gives human readers the grid; the sentence gives the model the quote.
Step 8: Track whether the coverage is working
Measurement for AI search is still rough, so pick indicators that move for reasons you can explain. Track how many of your mapped sub-questions now have a live, crawlable block that answers them. Track AI agent hits in the server logs month over month. Track the ratio between hub sessions and spoke sessions, because a working fan-out structure pulls traffic into the spokes. Track whether the entity details on your top ten directory listings match each other. If you want a single headline number for the whole picture, you can measure your ASS score (https://assmetric.com), which frames the work around Authority, Sources and Specificity: what the model already knows about you before it searches, what it finds when it does search, and how precisely your page answers the exact question it was asked.
One more thing about visibility in this space: a lot of the practical detail gets shared in places that do not publish. The summit format is a good example, and communities such as the Church of SEO Jesus (https://www.skool.com/church-of-seo-jesus) exist partly to get that kind of working detail into written form, which is the only form an AI system can index later.
FAQ
Do I need to rewrite all my product pages for AI search?
No, you need to add a liftable answer block to them rather than rewrite them. Keep the existing sales copy, then place a short direct answer near the top of each key page and build the spokes underneath.
How many pages do I need to cover one product properly?
Most single products need one hub plus three to six spoke pages to cover the fan-out responsibly. If your fan-out list has 40 sub-questions and three pages, you are concentrating everything into blocks too large for a model to lift usefully.
Why does my traffic not show any AI referrals when the logs show AI crawlers?
Because AI agents mostly crawl without sending referral traffic, and standard analytics only records user agents it recognises. Server logs are the only reliable record, which is why the monthly log review matters.
What to do first
Pick your single highest-revenue product and build its fan-out list today. That is the whole first move, and it takes under an hour. Then add one liftable answer block with a question-phrased heading to the existing product page, check the server logs for whether AI agents are reaching it, and fix the top listing where your business description differs from your own site. Four small changes, all reversible, all measurable within a month. The wider fan-out map, the spokes, the tables and the entity cleanup all follow from that first list, and they will keep following from it every quarter for as long as search keeps expanding queries instead of matching them.