How to measure AI visibility

A team checks a buyer question in ChatGPT, sees its product named, and calls the job done. The next answer leaves the product out. Someone reports the first result in a meeting, and the team spends time optimising for a signal that was never stable. The cost is wasted content work and a false sense of progress.

If you are asking how to measure AI visibility, start with a sample rather than a screenshot. Measure AI search visibility across the buyer questions and engines that matter to you. Record whether the answer names you, whether it cites you, which page it cites, and how often the result holds when you repeat the test. That gives you a number you can defend in the next meeting, not just a screenshot.

How do you define AI visibility before you measure it?

AI visibility is not one outcome. It splits into being named and being cited, and they behave differently. A response can name your company without linking to your site. It can cite one of your pages without naming your company in the prose, so treating both as one score hides the difference between recognition and usable source coverage.

The first measure is the named rate: the share of sampled answers that name the product or company. The second is the cited rate: the share of sampled answers that cite your domain or an exact page from your site. Keep the denominators visible. A count of mentions is not a rate, and a count of citations is not a rate either.

You also need to record the engine. Perplexity, Gemini, the ChatGPT family and Claude do not produce the same source pattern in the sample. Across the CiteGraph scan data, Perplexity averaged 5.3 sources per answer, Gemini averaged 4, the ChatGPT family averaged 3.4, and Claude averaged 4.8. Those are different retrieval environments, so one combined number can make a change look better or worse than it is.

A short glossary covers the terms you will meet. A named rate is the share of answers that mention you. A cited rate is the share that cite your domain or page. A sample is the set of answers you tested, not every answer an engine could produce.

The engine figures come from a defined sample, not a promise about your next prompt. Claude named the scanned product in 6% of 1,467 sampled answers, according to the CiteGraph methodology. That line is useful because it gives both the outcome and its denominator. It still describes only the sampled answers, so use it as evidence rather than as a universal rate for every Claude response.

“Sources cited per answer”

Attributed to the CiteGraph methodology.

That phrase is a useful reminder that source coverage is a separate measurement from naming. It points you towards the number of sources attached to an answer, not towards a brand visibility score. You still need to record whether your domain or page appeared and whether the answer named your company.

How do you choose the questions and engines?

Build the sample around buying decisions, not around questions that are easy to test. Include questions about category choice, comparison, alternatives, use cases, pricing and fit. Keep the wording stable between runs. If you change the question while measuring the result, you are testing a new sample, even when the topic appears similar.

Choose the engines your buyers use or your team needs to understand. The available scan sample covers 60 scans of 41 sites in 44 categories, with 442 distinct buyer questions. It produced 7,260 AI answers and 45,309 recorded citations. That scale helps show patterns, but it does not remove the need to define your own question set.

Record the answer, the engine, the question, the date, the product name, the cited domain and the exact cited page. Do not record only the visible answer text. The source list tells you whether the answer used your site, a review site, a directory or another page that describes you. The page-level detail is where the next content decision usually starts.

You can use the free AI visibility checker for a quick first pass, then read the fuller methodology for how CiteGraph measures before comparing results. The weekly research on who owns AI answers is useful for wider patterns, but your own sample still decides whether a page matters to your business.

How do you calculate named and cited rates?

For each engine, divide the number of answers that name your product by the number of answers sampled. That gives the named rate. Then divide the number of answers that cite your domain by the same engine-specific answer count. That gives the cited rate. If you want an exact page rate, use the number of answers citing that page as the numerator and label it clearly.

Do not use total citation count as the numerator for a named rate. One answer can cite several sources, and the scan contains thousands of answers and tens of thousands of citations, as noted above. The same answer can also name more than one product. Answer-level counts and citation-level counts are measuring different things, and mixing them up will distort your rate.

The sample gives a useful illustration. Perplexity named the scanned product in 8.2% of 1,787 sampled answers, Gemini named it in 6.8% of 1,784 answers, the ChatGPT family named it in 4.4% of 1,781, and Claude named it in 6% of 1,467. These are named rates by engine, not a single universal AI visibility score.

When you report the result, write the numerator, denominator and engine beside the rate. Then show the cited rate separately. If the site is cited often but the brand is rarely named, your pages may be supplying evidence without winning recognition. If the brand is named but the site is rarely cited, the answer may rely on other sources.

How do you add a margin to the result?

A rate from a sample is an estimate. A margin tells the reader how much uncertainty surrounds that estimate. Without one, a small difference between runs can look like a real improvement when it may be ordinary sample variation.

Use a margin appropriate to the sampling design, and state the confidence level and denominator beside it. Keep the calculation at the engine level when you compare engines. A combined margin can conceal the fact that one engine has many more sampled answers than another.

We don't have a calculated margin for these engine figures, so we're not going to invent one. Treat the rates as directional until you calculate your own. We measure samples and print margins when the calculation supports them, but we don't know what we haven't measured, including how your own question set will behave outside this sample. That limitation is part of the result, not an afterthought.

For your own report, show a line such as: named rate, engine, sampled answers, margin, date. Repeat the same format for cited rate. If the sample is a practical monitoring set rather than a random draw from all possible questions, describe it as a sample and avoid claiming that the margin represents every answer an engine may give.

This matters when a buyer asks whether a movement is real. A result that rises from one run to another without a margin is a lead to investigate. It is not yet proof that visibility improved.

Why do single runs mislead you?

AI answers vary with the question, the engine, the available sources and the time of the run. A single answer is a useful observation. It is a poor measurement system. The mistake is easy to make because the answer is concrete and the missing answers are invisible.

The scan data shows why repeat measurement matters. In a project on CiteGraph's own site, 34 of the 40 domains cited at least three times in the first scan were still cited 17 days later. Only 41 of the 179 exact pages cited in that scan appeared again 17 days later. Counting every cited domain, 69 of 102 came back.

The pattern is straightforward. Heavily cited domains were more persistent than exact pages, while the long tail was mostly sampling rather than change. A page can disappear from one answer without the whole domain losing its place in the wider source set. That is why you should track both domain-level and page-level results.

Run the same question set again, keep the engine labels, and compare rates with their margins where a margin can be calculated. If a page appears once, mark it as observed. If it returns across runs, it has stronger evidence behind it. The aim is not to make every answer identical, which would be a strange ambition, but to separate a repeatable pattern from a lucky response.

How do you run the measurement method?

The method has a clear sequence. First, define the outcome: named rate, cited rate, or both. Next, build a fixed set of buyer questions and assign each question to the engines you want to track. Run the sample and save the complete answer and source list. Calculate each rate by engine, adding a margin where the design supports one, then repeat the sample on a schedule and compare it with the earlier run.

Keep the procedure consistent: use the same wording, count answers rather than screenshots, and preserve the exact URLs that engines return. If you change the question set, label it as a new sample rather than quietly comparing it with the old one. For the full step-by-step version, see the measurement method guide.

Use this checklist before you publish a result:

• You have defined whether the result measures naming, citations, or both.
• You have recorded the engine and the number of answers sampled.
• You have kept the buyer questions stable between comparable runs.
• You have separated domain citations from exact page citations.
• You have calculated the rate from answers rather than from total citation counts.
• You have included a margin or stated why the available data does not support one.
• You have saved the source pages so someone else can inspect the result.

This method also makes tool comparisons clearer. A tool may show a visibility score, but you still need to know what it counts, which engines it covers, how many answers it samples and whether it exposes the cited pages. The label matters less than the underlying denominator.

How do you turn the result into a useful decision?

Start with the largest reliable gap. If your named rate is weak across engines but your cited pages return repeatedly, improve the way your company and product are described around those pages. If your site is rarely cited, inspect the pages that answer buyer questions and compare them with the sources that do appear. If one engine differs sharply from the others, keep the engine-specific result rather than averaging it away.

The wider source set can help you find context. The scans recorded 7,624 distinct domains and 16,506 distinct pages. That tells you the source set is broad, but it does not tell you which page to copy or which domain guarantees visibility. Use it to identify recurring source types and missing buyer questions, then test your changes in the same sample.

A useful report has the sampled answers, named rate, cited rate and margin for each engine. Add the strongest recurring pages underneath. This gives a founder a decision, a marketer a content brief and an SEO a testable page change. It also prevents the team from celebrating a single mention as if it were a trend.

We measure samples and print margins when the calculation supports them, but we don't know what we haven't measured, including how your own question set will behave outside this sample. That limitation is part of the result, not an afterthought.

At the start, the team saw an answer name the product and treated it as proof. After this method, that answer is an observation inside a named rate and a cited rate, split by engine and checked against repeated samples. It can be read alongside a margin where one can be calculated, rather than treated as proof on its own. The screenshot still exists. It simply no longer runs the meeting.