One Question Is Not a Measurement
The one-minute AI visibility test tells you whether you win one question. It cannot tell you which questions you could win, and that is the only number that changes a plan. Why a measurement needs many buyer questions across several engines, with a worked example where two tests agreed on the score and only one explained it.
We make one of the tools in this category, so treat this as interested testimony and check it. This piece names no vendor and no practitioner. It is about a method, and the method is one anyone can run for free.
What does the one-minute test actually tell you?
The easiest AI visibility test in the world takes about a minute. Open ChatGPT, ask who you should buy from in your category, and see whether your company comes up. Run it a dozen times and count. It is a fair test, it is free, and I recommend everyone do it once.
It is also the point where most AI visibility analysis stops, and that is the problem. A single question asked repeatedly tells you one thing with confidence: whether you win that question. It cannot tell you which questions you could win, which is the only number that changes what you do next.
Why does the category decide the answer before you ask?
When you ask an engine who to buy telecommunications equipment from, it names Cisco, Ericsson and Nokia. It will name them for a ten-person specialist and it will name them for a mid-size manufacturer with a real product. Not because the engine judged the specialist and found it wanting, but because the question was framed at a level where only the largest companies exist.
The same specialist asked about differently, at the level its buyers actually think, may already be winning. Nobody buys telecommunications equipment. A hospital IT director buys indoor cellular coverage for a new wing. An operator buys small cells for a shopping mall. A logistics firm buys a private network for a warehouse with bad Wi-Fi. Each of those is a different question, drawing on a different set of sources, with a different set of names in the answer.
So a zero on one broad question is not a verdict. It is the result of one framing. The useful work is finding the framings where you can win, and that requires asking many questions, not one question many times.
Where does the plan come from?
Buyer questions fall into three shapes, and each one is a separate market you either hold or do not.
Category discovery is the broad question: who are the best vendors for X. Problem-first is the buyer describing their situation without naming a category: how do I fix dead zones in a manufacturing plant. Head-to-head is the buyer who already has a shortlist: affordable alternatives to a named competitor.
A company can be invisible in category discovery, competitive in head-to-head, and absent from problem-first entirely, all at the same time. That pattern is the plan. It says the buyers who already know the category can find you, and the buyers who only know their problem cannot, so the content and off-site work go to problem-first questions, and the head-to-head pages you already have are working.
One question asked twelve times collapses all of that into a single number. Twelve questions across three segments, asked on several engines, show you the shape of your visibility. Only the second one tells you where to spend a dollar.
What does a measurement need before you act on it?
Five properties separate a number you can plan against from a number that felt convincing at the time. None of them is exotic. All of them are missing from the minute-long test.
- Several engines, not one. ChatGPT, Claude, Gemini and Perplexity retrieve from different indexes and weight sources differently. A company can be recommended by one and unknown to another. A single-engine result is a fact about that engine.
- Real buyer questions across the three segments. The question set should look like the questions your customers type, in their words, at the level they think. It should be written down and reused unchanged each month so that movement is real movement.
- Search-grounded answers separated from model memory. Some answers come from a live search. Some come from what the model absorbed in training, with no search at all. A zero from memory and a zero from search are different problems with different fixes, and a report that pools them hides which one you have.
- Failed runs excluded, not scored. Engines rate-limit and time out. A run that returned an error is not a run in which you were not recommended. Counting it as one quietly deflates every score.
- Every transcript stored, with its sources. If you cannot read the answer that produced the number, you cannot check it, you cannot see which pages the engine trusted, and you cannot find the moment it named a competitor's domain that turned out to be wrong. The transcript is where the plan lives. The score is only its summary.
A sixth property is worth adding for companies with a common name or a similar-named neighbor: does the report check that the engine was talking about you at all. Engines confuse entities constantly, and a recommendation attributed to the wrong company is worse than no recommendation.
What did two tests on the same company show?
A telecom equipment maker I know well ran both tests in the same month.
The minute-long version asked one broad question four ways on three engines. The company was recognized every time it was named and recommended zero times. Cisco was named eleven times. The conclusion offered was that the company needed authority signals and answer-shaped content.
The structured version asked twelve questions across the three segments on four engines, in the company's real category rather than the broad one. The company was again found every time by name, with accurate facts on every engine, and again recommended zero times. So far the two tests agree.
Then the structured version showed what the first could not. On the broad question, three of the four engines never searched. They answered from memory and named Cisco from memory. No page on any website reaches that answer. On the narrower questions where engines did search, the sources they drew from were a short list of industry publications and analyst profiles, and the company appeared on none of them. That is a specific, finite piece of work: get an accurate presence on those five or six sources and re-measure. The broad question, by contrast, has no finite fix at all.
Both tests said zero. Only one said why, and only one said where the first point would come from.
How do measuring and fixing fit together?
None of this is an argument against the people who do the fixing. Schema, entity records, directory listings, answer-shaped pages and patient off-site outreach are real work, and most small businesses will never do it themselves. Someone should do it for them, and the agencies and studios taking that on are doing something valuable.
The argument is that fixing and measuring are different jobs, and the measuring job has been undersupplied. A fix without a measurement is a hope. A measurement without a fix is a report. The businesses that move are the ones that hold a reproducible measurement in one hand, taken the same way each month with the same questions, and a set of hands in the other doing the work the measurement points at.
That is why I built the instrument and left the hands to others. Anyone can run the measurement in ninety seconds and read the full transcripts behind every number. Whoever does the work, the customer can see for themselves whether it moved.
Run the one-minute test. Then, before you spend anything on what it told you, ask twelve questions instead of one.
Related reading in this series: the primer on the difference between a mention, a citation and a recommendation at https://aeoanalyzers.com/what-should-an-aeo-tool-do, the tour of how the measurement is taken at https://aeoanalyzers.com/blog/how-it-works, and our own monthly numbers, published whatever they say, at https://aeoanalyzers.com/evidence.
Run the twelve-question version on your own site free at https://aeoanalyzers.com
AEO Analyzers (aeoanalyzers.com) was created and is solely maintained by Lindsay Hiebert, founder of PIGENAI LLC. It is unaffiliated with any similarly named browser extension, plugin, or tool.