How to Choose Competitors for LLM Visibility Monitoring

Share of voice looks like a fact about the market. It is not. It is a proportion computed inside a list of entities that somebody typed into a settings screen, and changing that list changes the number without anything changing on the web. Choosing the list is therefore a measurement decision, not an administrative one, and it deserves the same care as writing the prompts.

What the competitor set actually does to the arithmetic

Share of voice in SiteRank AI is defined as: observations mentioning your entity ÷ observations mentioning any tracked entity, over a stated prompt set, provider, model and window. The competitor list is what "any tracked entity" means. It sits in the denominator.

Two consequences follow immediately, and both are counterintuitive the first time you meet them.

Adding a competitor can only hold your share flat or push it down. Every observation that mentions the new entity and not you adds to the denominator alone.

Removing a competitor can only hold it flat or push it up. This is why a competitor set that is quietly curated toward the entities you happen to beat produces a number that is arithmetically true and substantively worthless.

A worked example makes the size of the effect obvious. Suppose 100 valid observations, in which your site is mentioned 30 times.

Nothing about the site, the model or the web changed between those rows. Only the list changed. Any tool that reports share of voice without showing you the tracked set alongside it is reporting a number you cannot interpret, and any comparison of your share of voice against a figure published by someone else is meaningless unless both sets are identical — which they never are.

The practical rule that falls out of this: the competitor set is part of the metric's definition, and it is versioned like the prompt text. SiteRank AI treats a change to the tracked set the same way it treats a prompt edit — as a discontinuity in the series rather than a continuation of it. The methodology page records which set produced which stored row.

Choose the entities that appear in the answers, not the ones on your battlecard

The instinct is to paste in the competitor list that sales uses. That list was built for a different purpose: it names the companies you lose deals to. The tracked set for visibility monitoring needs to name the entities that occupy the answer space for your prompts, which is an overlapping but genuinely different population.

Three groups reliably show up in generative answers and are missing from most battlecards.

• Incumbent generalists. For "best project management tool for a small agency", a model will very often name the two or three largest products in the category regardless of fit. They are not your competitors commercially. They are absolutely your competitors for the sentence.
• Editorial and aggregator entities. Review sites, marketplaces and "top 10" publishers get named as entities in their own right, not only cited as sources. Whether to track them as competitors depends on what you are trying to learn, and the answer is usually no for mentions and yes for citations — a distinction developed below.
• Adjacent-category substitutes. The answer to a buying question is frequently a different category ("just use a spreadsheet", or a general-purpose tool). If a substitute is consuming the answer, tracking it tells you something you cannot learn any other way.

The empirical method is better than any of this reasoning: run the prompt set once without a competitor list, read the responses, and build the set from what you find. This is the only step in the process that involves no guessing.

1. Run the approved prompt set at a small sample size — enough responses to see the shape, not enough to spend real money. Costs are metered per run and shown before it starts.
2. Read the raw responses, not a summary. Write down every organisation, product and brand named.
3. Count how many distinct prompts each one appeared in, not how many responses. An entity that dominates one prompt is a fact about that prompt.
4. Anything appearing across several prompts is a candidate. Anything appearing once is noise until it repeats.

This produces a set grounded in observation rather than in assumption, and it has a useful side effect: the entities that surprise you are the most informative output of the whole exercise. A competitor you did not expect to see is a finding. A competitor you added because you assumed it would be there, which then never appears, is a warning that your prompts may not be asking what you think they are asking.

That last row is worth dwelling on, because it is a tempting shortcut. Asking a model "who are the competitors of X?" and importing the answer produces a competitor set whose provenance is a single ungrounded generation. It is circular in a specific way: you would then be measuring share of voice against a set the same family of models invented. If you do it at all, treat the output as a candidate list for a human to approve, and record that this is where the names came from.

Aliases are the largest source of silent error

An entity is not a string. "Acme", "Acme Inc.", "Acme Software", "acme.com" and "AcmeCloud" may all be the same thing, and a model writing prose will use whichever form fits the sentence. If your extractor matches one surface form, every other form is counted as a non-mention, and the resulting rate is wrong in the direction that flatters or damages you at random.

For every tracked entity, record the surface forms deliberately:

• Legal name and trading name, where they differ.
• The common short form people actually use in speech.
• Product names distinct from the company name, which is the case most often missed. If the model names your product but not your company, is that a mention? Decide once, write the decision down, and apply it to every competitor identically.
• Former names, which persist in model outputs long after a rebrand because they are all over the training data.
• The primary domain, plus any secondary domains, documentation subdomains, and shortened link domains.

Two hazards deserve explicit handling.

Ambiguous short names. If a competitor is called "Notion", "Arc" or "Linear", a naive substring match will fire on ordinary English. The fix is not a cleverer regex; it is to require a more specific form, and to route the uncertain cases into a separate bucket rather than forcing a binary. SiteRank AI counts near-misses as uncertain rather than as a mention, because an inflated numerator is worse than a known gap.

Shared names across categories. Two unrelated companies with the same name will both be named by a model at different times. Domain-level evidence in the citations can disambiguate; prose alone often cannot. Where it cannot, the honest answer is to record the ambiguity.

Symmetry is the discipline that makes the whole thing defensible: your own alias list is always the most complete one in the system, because you know your own names best. That asymmetry biases share of voice upward. The correction is to spend real effort on competitors' alias lists too, and to re-run the extraction over stored raw responses when you improve one. This is only possible because raw responses are retained — a system that stores only derived counts can never fix an extraction error retrospectively.

Domains matter for citations, and they are a different set

Mentions and citations are separate measurements with separate denominators, and the competitor set does different work in each.

A mention is an entity named in the answer text. A citation is a source attribution the provider returns as structured data. OpenAI's web search tool returns url_citation annotations carrying the URL, title and position within the text, and separately a sources list of everything consulted, which the documentation notes is broader than what is cited. Citation share therefore compares domains, not brands.

That distinction changes who belongs in the list.

The domain list needs its own maintenance. Resolve redirects and provider link wrappers before matching, or a competitor whose links pass through a tracking domain will be systematically undercounted. Include documentation and support subdomains, which are cited far more often than marketing pages for technical questions. And decide explicitly whether a subdomain counts as the parent domain — either answer is defensible, neither is defensible if applied inconsistently across entities.

Set size, and why more is not better

There is no correct number of competitors, but there are clear failure modes at both ends.

Too few (one or two). Share of voice becomes a head-to-head that swings wildly on small samples, and it flatters you by excluding the entities actually consuming the answers.

Too many (twenty or more). Every entity's share shrinks toward the floor, the differences between them fall inside the confidence intervals, and the chart becomes a band of overlapping noise. There is also a real extraction cost: each additional entity brings alias ambiguity, and false positives accumulate across the whole set.

A working range of five to ten tracked entities, chosen from observation, tends to be enough to be representative and small enough to maintain honestly. The test is not the count, though — it is whether every entity in the set can be defended with the sentence "this appeared in responses to our prompts", and whether every alias list has had the same effort spent on it.

Sample size interacts with set size in a way that is easy to miss. Share of voice is a proportion, and its 95% Wilson interval is computed at the actual number of observations mentioning any tracked entity — not at the total number of observations. Adding competitors increases that denominator and narrows the interval, which can make a set look more precise while the underlying evidence about you has not improved at all. Read the interval next to the numerator, always.

Reviewing the set over time

A competitor set is a standing decision that decays. Categories change, companies rebrand, new entrants appear in answers within weeks of launching, and models update.

A defensible review rhythm:

• Every run: the system flags entities named in responses that are not in the tracked set, ranked by how many distinct prompts they appeared in. This is the single most valuable maintenance signal, and it costs nothing extra because the responses are already stored.
• Quarterly: review the flagged list, add what has become material, and record the change as a versioned event.
• On any rebrand or acquisition: update aliases and domains, and re-extract over historical responses so that the past is measured with the same rules as the present.
• Never mid-comparison: do not change the set and then present a before-and-after as if it were one series.

When the set does change, the chart must show a break rather than a continuous line. A tracked-set change is a change to the instrument. Drawing a smooth line through it manufactures a trend out of an administrative edit — and someone will read that trend as the result of work they did.

There is a related discipline for the entities you drop. Removing a competitor because it stopped appearing is legitimate; removing one because it was beating you is not, and the difference is invisible in the output. Recording the reason for each change is what makes the set auditable later, including by you, six months on, when you no longer remember.

What the number cannot tell you

Even a well-chosen set supports a narrow claim. Share of voice over a tracked set is a statement about how often your entity is named relative to a group you selected, in answers to questions you wrote, from one model, under recorded conditions, in a window. It is not market share, not demand, not preference, and not a ranking — the answer is prose, and the order in which entities appear in a sentence is not an evaluation of them.

Nor does it support causation. Google's own documentation states there are no additional requirements or special optimisations for appearing in its AI features beyond ordinary SEO, and no provider documents an ordering function over entities named in generated answers. A rise in share of voice after you published something is association plus sampling noise, reported alongside a volatility figure that tells you how much of the movement could be nothing at all.

Key takeaways

• The competitor set is part of the metric's definition. Adding entities can only lower your share; removing them can only raise it.
• Build the set from entities actually observed in responses to your prompts, then have a human approve it. That is STRONG EVIDENCE; a battlecard is not.
• Alias lists decide whether a mention is counted. Spend as much effort on competitors' aliases as on your own, or the number is biased in your favour.
• Mentions compare brands; citations compare domains. They need different lists, and the consulted-sources list is not a citation list.
• Five to ten tracked entities is usually enough. Read every share alongside its numerator and interval.
• Review the set on a schedule, record every change, and draw a discontinuity rather than a continuous line when it changes.

Official sources & further reading

• Web search tool — OpenAI
• AI features and your website — Google Search Central
• Overview of OpenAI crawlers — OpenAI

Related reading

• What is share of voice in AI search?
• How LLM visibility monitoring actually works
• How to measure AI mention rate and citation rate
• Monitor the questions AI users ask about your brand
• AI visibility monitoring for WordPress