Win a niche, not the category: how small stores get cited by AI

Grounded answer engines select a limited source set for a response, and broad commercial questions attract strong competition. The exact number and selection are provider- and query-dependent; the APIs expose their chosen URLs through OpenAI citation annotations, Gemini grounding metadata and Perplexity search results.

Displacing an established editorial source on a broad category query is usually a poor first objective for a small retailer.

The good news is that this is the wrong fight to pick.

Where the buyers actually are

Consider two questions:

best running shoes

trail running shoes for wide feet under $150 that work in wet weather

The first is research. The person asking is three weeks from a purchase and mostly wants orientation. The second is someone with a credit card out.

The second question also has a different competitive shape:

• Fewer contenders. Most publishers write the broad guide, not the narrow one.
• The answer depends on product facts. Width fitting, price, membrane, outsole compound. Facts a retailer holds and a generalist review site often does not.
• It is answerable definitively. There is a right answer, and it can come from a product page.

That third point is the one people miss. Answer engines are not trying to rank pages; they are trying to compose a correct answer. A page that contains the specific facts needed to answer a specific question is useful to them in a way that a page competing on a generic phrase is not.

What "owning a niche" actually means

It does not mean stuffing "wide feet" into your product description forty times. It means being the source that can answer a cluster of related questions completely.

For a trail shoe, that cluster might be:

• trail running shoes for wide feet
• are trail shoes good in wet weather
• what is a rock plate and do I need one
• trail shoes for beginners on technical ground
• how long do trail running shoes last
• trail running shoes under $150

Every one of those is answerable from facts about your products — if those facts exist in a form a machine can read. Width fitting as an attribute, not a sentence in paragraph four. Membrane type as a specification. Price and availability in structured data. A short description that says what the shoe is for rather than that it is "engineered for performance".

Get that right across a cluster and you stop being a store that sells a shoe. You become the source that answers questions about that kind of shoe.

Why this works better than chasing the big term

Three reasons, in increasing order of importance.

One: you can actually win. Fifty narrow questions with two or three plausible sources each is a winnable fight. One broad question with fifty entrenched sources is not.

Two: the traffic converts. Someone who asked a question containing a price ceiling, a fit requirement and a use case is not browsing.

Three: it compounds. Answer engines build a picture of what a source is reliably good at. Being consistently useful on a specific cluster is a stronger signal than being marginally relevant to a broad one.

How to find your cluster

Start from what you actually know that others do not:

1. What do customers email you about? Those questions are your cluster, verbatim. Support inboxes are the most underused keyword research tool in ecommerce.
2. What do your products do that the category leader's do not? Wide fittings, unusual sizes, a specific material, local stock, a longer warranty. Constraints are niches.
3. What is the buying decision people find hard? "Which of these two", "will this work for X", "is it worth the extra £40". Comparison and suitability questions are where a retailer's product knowledge beats a publisher's.
4. Where are you the only serious option? Regional availability, specialist categories, unusual combinations of requirements.

Write those down as questions a person would type. Not keywords — questions.

Then make the answers machine-readable

A cluster of questions is worthless if the facts that answer them are locked in prose.

• Attributes, not sentences. "Available in wide fitting" as a structured attribute is retrievable. The same phrase in paragraph six is not.
• Complete Product markup. Brand, GTIN, price, availability and image. Google documents these and related properties in its Product structured data guidance.
• One self-contained paragraph per question. The passage that answers "does this work in wet weather" should make sense lifted out of the page entirely, because that is exactly what will happen to it.
• Crawl access. All of the above is irrelevant if robots.txt or an X-Robots-Tag header is quietly blocking the crawler. Check before you write a word.

What to measure

Not "am I ranking". Track, per question:

• Cited — the answer pointed at your URL. The outcome you want.
• Mentioned — your name appeared, but the link went elsewhere. Means you are known but not trusted as the source; usually a content depth or structured data problem.
• Absent — you were not part of the answer at all. Check crawl access first, then whether the facts even exist on the page.

That third column is a to-do list. "Mentioned but not cited" in particular is the most actionable diagnosis in this whole field, and it is invisible to any tool that reports a single blended number.

The honest summary

Nobody can promise you a citation. Anyone who does is selling certainty about a system they do not control, that changes weekly, and that returns different sources for the same question on consecutive runs.

What is genuinely controllable:

• whether a crawler can reach you
• whether your facts are machine-readable
• whether you have a passage worth quoting
• which questions you are competing for at all

That last one is the strategic decision, and it is the one most stores get wrong by aiming too broad. Pick the questions you can actually answer better than anyone else. Make the answers legible. Then measure, honestly, question by question.

That is a plan. "Rank in ChatGPT" is a wish.

Primary sources

• Google Search Central: Product structured data
• Google Search Central: Crawling and indexing
• OpenAI API: Web search and URL citations
• Gemini API: Grounding with Google Search
• Perplexity API: Sonar response citations and search results