How to Build a Buyer-Question Panel for GEO Measurement

To measure whether AI-generated search answers represent your business well, start with the questions buyers ask when they compare options, check fit, or assess risk. GEO, short for generative engine optimization, is work to improve how a business appears in AI-generated answers. A buyer-question panel is a fixed set of these questions that you run against selected products and record over time.

Use the panel to compare brand mentions, citations, and answer accuracy over time. It cannot capture every real buyer’s experience or prove that an answer led to a visit or sale. Build the panel from evidence about customer needs. Keep its question set stable, and record exactly how you run each test.

Choose questions that reflect buying decisions

Start with the decision you need to make. For example, you might want to know whether answers describe your product accurately, help buyers find credible comparisons, or address a particular concern. That decision determines which questions to include and which results to measure.

Use real buyer language from sales and support conversations, interviews, and feedback forms. Add site search and relevant search data as sources too. Record each question’s source. Mark whether it is an observed customer question, an edited version, or a question written for testing. An edited question can improve clarity or protect privacy, but do not present it as a direct customer quote.

Search data can reveal useful themes, but it does not show every query. Google says Search Console omits some anonymized queries from its query tables. Treat the available query list as one input, alongside customer conversations and research, rather than as a complete record of buyer language. (Google’s explanation of Search Console data limits)

Group questions by what the buyer is trying to do. For example, a panel might cover learning about a category, comparing alternatives, checking whether an option meets a requirement, or investigating cost or risk. Give each question one main task and a second label if it covers more than one.

Keep branded and unbranded questions separate. A question that names your company tests how the system responds when a buyer already knows your name. An unbranded question tests whether the company appears when the buyer asks about a need or category without naming it. Combining the two can make brand visibility look stronger than it is for discovery.

Keep a stable core and track changes

Use a stable core panel for comparisons across dates. Keep each question’s wording and ID unchanged. Also preserve its category and scoring rules. When you discover a useful new question, place it in a separate discovery set first. Add it to the core only through a documented panel revision.

Keep the sets separate because changing the mix of questions can change the results even if the answers stay the same. For example, adding questions about a topic where your brand already appears can raise the overall mention rate just because the panel now has more favorable questions.

Test different wordings when variation in phrasing matters. Link each version to the same buyer need so you can tell whether a system addresses that need across different wordings or responds to one prompt by chance. Do not silently replace a question in the stable panel with a differently worded version.

There is no established universal panel size. The right size depends on the decision and the range of buyer needs. It also depends on the effort required to repeat the tests consistently. Start with the questions that matter to the decision, then expand when a clear gap appears.

Record the conditions for every run

To understand a result, record what produced it: the panel version, question ID, and exact prompt. Note the platform and specific surface, plus the date, locale, and session conditions. Save the full response and cited URLs too. Also note known changes to the product or test setup. If you use a follow-up prompt, save it with the original question and response.

Name the actual surface rather than recording only the provider. Google says AI Overviews and AI Mode can use different models and techniques, so their answers and links can differ. A combined “Google AI” result can conceal those differences. (Google’s guidance on AI features)

Run the tests on a schedule you can maintain, using the same panel and conditions for each comparison. Repeating them shows whether an observation happens again, though results will not necessarily match every time. A 2026 preprint found that citations varied across repeated tests of a limited set of product topics and search experiences. The findings are a reason to treat single runs with caution, but they do not set a standard number of runs for every business. (The study of AI visibility uncertainty)

Score mentions, citations, and accuracy separately

Define each measure before running the panel, including its denominator, the total number of runs used in the calculation. For example, calculate brand mention prevalence by dividing the valid response runs that name the brand by all valid runs in the selected question set. Site citation prevalence counts runs that visibly cite a page on your site. Keep these measures separate from whether an answer recommends the brand, describes it accurately, or addresses the buyer’s stated constraints.

A citation does not necessarily mean the answer used the cited page correctly. Read the response and source together when accuracy matters. Record whether the answer gets material details right, such as product capabilities, availability, or stated limitations. A correct mention, an inaccurate mention, and a useful recommendation are distinct outcomes.

Also separate branded questions from unbranded questions in reporting. For each result, show the number of valid runs and the panel version. A zero means the panel did not observe the outcome in those runs under those conditions; it does not establish that the brand never appears.

Use platform reports as additional evidence

Platform reports cover different questions from a buyer-question panel you run under controlled conditions. As of November 11, 2026, Google said its generative AI performance reports had rolled out worldwide in Search Console. These reports add platform data to prompt tests, but they do not confirm every result in a panel whose questions you selected manually. (Google’s Search Console report announcement)

Bing Webmaster Tools’ AI Performance report shows combined citation activity and themes from queries used to support answers. Bing describes those queries as grouped phrases rather than complete user questions, and says the data is sampled. Use the report to find broad themes and cited pages, not to reconstruct every buyer prompt or explain why a system selected a source. (Bing’s AI Performance documentation)

Crawler access is a separate signal. A crawler is software that requests pages from a site. A server log showing such a request, or a site rule that allows it, does not show that a platform indexed the page, used it in a particular answer, cited it, or affected a business outcome. OpenAI documents different crawler roles, including one for search discovery and another that may support model training. Neither role alone proves that a page appeared in an answer to a buyer question. (OpenAI’s crawler documentation)

Watch for misleading comparisons

A general keyword list may miss the constraints buyers care about. Include questions about real comparisons, fit requirements, costs, implementation concerns, and risks. A panel with too many questions naming your brand can overstate how often buyers discover it. If you change the panel without recording a new version, before-and-after comparisons become unreliable.

Combining results from different platforms or surfaces can hide differences in their behavior. A single score that combines mentions, citations, accuracy, and recommendations can hide those differences too. Keep the measures separate, save the original answers, and check what changed in the responses before drawing conclusions.

Because the panel tests a chosen set of scenarios, its counts describe those scenarios rather than market demand or how often buyers ask each question. A citation alone does not establish traffic or sales. Use the panel to identify observed answer patterns and content gaps, then check traffic and business outcomes through separate evidence.

Key Takeaways

• Build from buyer evidence: Use customer conversations, research, and search data, and label observed questions separately from questions written for testing.
• Protect comparability: Keep a stable core panel and track new questions in a separate discovery set until you formally revise the panel.
• Record every test condition: Preserve the exact prompt, platform surface, date, locale, session context, answer, citations, and panel version.
• Separate the outcomes: Measure mentions, citations, recommendations, accuracy, and buyer fit as distinct results. Report stated denominators for them.
• Treat results as sampled observations: Repeated runs and first-party reports add evidence, but neither establishes market-wide visibility or business impact.

What I'm building

Delegate tasks. Get software.

Give Vroni a GitHub issue, bug report, spec, or rough idea. It reads the repo, plans the change, writes code, runs checks, and works toward a review-ready pull request.

Take a look at vroni.com