Brand visibility in AI search

More and more people ask an AI before they decide: which provider suits this need, is this brand trustworthy. Yet most organisations have no systematic answer to a basic question: does the brand appear in those answers, and how is it described? Usually someone tried it once and took a screenshot. This article is not a research report. It is a research design: what we want to find out, how we collect, how we record, how we judge, and where things can go wrong. No findings are presented here. They will be published separately once a study round has been completed and checked.

The question, and why it matters

The primary question is simple. When real customers ask natural-language questions related to a brand, do different AI engines mention that brand, and do they describe it correctly? It matters because AI answers often give a short list directly, and the reader may never click through to a website. Not being on the list often means not being considered.

The secondary question is where differences come from. If the same question gives different answers across engines, days or phrasings, a single screenshot is not enough evidence. We need to understand stability first, and only then talk about improvement.

Building a prompt set from real customer questions

The prompt set should not be invented by marketers. It is assembled from real sources: frequent questions in support and sales records, site-search terms, the wording customers use on forums and social media, and questions raised at events. Personal data is removed, similar phrasings are grouped under one intent, and two or three natural phrasings are kept per intent so that we do not test only one wording.

• Layers of intent: awareness (what is this), comparison (how do A and B differ), choice (whom should I pick), trust (is it reliable, any complaints).
• Three brand-term groups: with the brand name, category only without the name, and with a competitor's name.
• Each prompt carries its source and date; when the set is revised the old version is kept so before and after remain comparable.
• Prompts use customer language, not industry jargon, and never hint at the answer.

Running across engines and dates

The same prompt set goes into several mainstream AI search and chat engines, and is repeated on different days and at different times. Each run starts from a clean conversation with no carried-over context. If an engine differs by login state or region, that is recorded too, because both can change the answer.

Repetition is central. Repeating the same prompt on the same engine within a day shows the answer's own randomness; repeating across dates shows drift caused by engine updates or changes in web content. The number of repetitions is fixed in the study plan before the run, based on budget, and not adjusted after seeing results.

What gets recorded for each answer

The raw answer is stored in full and never replaced by a summary. On top of it we code a fixed set of fields, with at least two coders working independently and their differences compared afterwards.

• Mention: yes, no, or only indirectly; and position (which item in the list, whether it is the top recommendation).
• Description accuracy: whether facts such as scope of service, location, price range and background match official information, with errors classed as outdated, confused or invented.
• Cited sources: the domains linked in the answer, grouped as brand-owned, third-party media, review platforms, encyclopaedic, unknown.
• Sentiment: positive, neutral or negative, with the quoted sentence that supports the call.
• Environment: engine name and version, date and time, language, region, login state, prompt id and repetition number.

How results are judged and scored

We do not plan to collapse everything into one opaque score. A more honest approach is to show a few readable indicators side by side: mention rate (share of runs where the brand appears), first-position rate, accuracy rate, and brand-owned source rate. Each indicator is reported with the range of variation between repetitions, so readers see roughly where it falls rather than a falsely precise point.

Accuracy is checked against the brand's official information, but that information may itself be out of date, so coders mark uncertain cases as 'to verify' instead of forcing a verdict. Scoring rules are written before the study and are not changed during it. If a change is unavoidable, the date and reason are noted and results are computed under both old and new rules.

Factors we will examine

Once results exist, the useful question is why one brand appears and another does not. We list factors that can be examined, but until data is in, they are hypotheses and not conclusions.

• Structured data: whether the site marks up its organisation, services and common questions in a standard way.
• FAQ pages: whether there are short, direct pages answering common questions in customers' own words.
• Third-party sources: whether independent media, directories, review sites or encyclopaedic entries describe the brand.
• Name consistency: whether the brand name, address and service names are written consistently, and not confused with other organisations.
• Freshness: whether official pages are current and show clear update dates.

Correlation is not causation. Even if a factor appears alongside a higher mention rate, we check for common causes; a larger organisation may simply have more data and more coverage.

Prioritising fixes and re-testing

Fixes are ranked on three dimensions: how many high-value prompts are affected, cost and controllability, and likelihood of effect. Factual errors and name confusion usually come first, since they damage trust directly and can often be handled by updating official pages or correcting third-party entries.

After a fix, the same prompt set and engines are run again and compared with the earlier ranges. If the change falls within the original random variation, we do not claim an improvement. The retest schedule is planned in advance too, because engines need time to re-read content, and retesting too early gives meaningless results.

Limits, biases and how results will be published

The method has clear limits. Engine answers change over time, so results describe a sample on particular dates. We can only test the questions we thought of, and real customers ask many more. Coders' judgement, especially on sentiment and accuracy, adds error. Engines have different audience sizes, so a simple average is not real exposure. Tests run by a brand about itself tend toward confirmation, so raw answers and coding records are kept for third-party review.

When a study round is completed, we will publish the full method, a layered summary of the prompt set (with identifying and client information removed), indicators with ranges, a statement of limits, and a note on which observations were too unstable to conclude anything. Until then this page is a design note, and no number on it should be read as a finding.

First learn how much is visible and how accurate it is; then talk about improving it. And where a study is not finished, say plainly that there are no results yet.