Measure AI search visibility without mixing the metrics

Give every number a precise job

Decide whether the immediate objective is discovery, accurate representation, website visits or qualified enquiries. Assign one primary measure to that objective. Keep supporting measures nearby, but do not combine them into a single visibility score with unexplained weights.

A citation can be valuable without producing a visit. A visit can produce no useful action. A brand mention can describe the wrong service or location. Record these separately so a better-looking answer does not automatically become a claim of commercial growth.

Use the current Google report, not an outdated assumption

Google now documents a dedicated Generative AI performance report for Search. It reports impressions for supported AI features, including AI Overviews and AI Mode. The same activity is included in the overall Web performance data: adding the two totals would double-count part of the exposure.

Use the available page, country, device and date dimensions to locate changes. If the report is absent, check its documented eligibility and data-volume conditions before interpreting the absence as zero visibility. Keep an export and its date range with the scorecard.

Do not relabel overall organic clicks as AI-only clicks. A metric belongs to the report and definition that produced it. When an interface supplies an exposure measure, use it as exposure; evaluate visits and outcomes with the relevant traffic and conversion records.

• Write the report name and search type beside every export.
• Compare matching periods and the same page set.
• Keep native Google observations separate from manual ChatGPT, Claude or Perplexity checks.
• Mark a missing or unavailable value as unavailable rather than entering a measured zero.

Build a prompt panel around real decisions

Collect questions from customer conversations, sales objections, support requests and on-site searches. Group them by intent: understanding a problem, choosing an approach, comparing options and finding a suitable provider. Keep branded and unbranded questions in separate groups.

For each question, write the intended audience, market and answer criteria before running it. A useful criterion might be whether an answer links to the relevant service page and states its service area correctly. Avoid selecting only prompts that already name the business: that tests a different task from being discovered without the name.

Freeze the initial panel for a review cycle. Add new questions to a separate candidate list rather than changing the denominator halfway through a comparison. If a question no longer fits the business, retire it with a dated reason.

• Question ID and exact wording
• Intent, audience, language and market
• Product, mode and relevant settings
• Collection date and time
• Linked URL, mention and accuracy observations
• An action owner and the next review date

Use rates that another person can reproduce

Define a cited-answer rate as the number of eligible answer runs containing a qualifying link divided by all eligible runs in that panel. Define a qualifying link before collection: for example, a link to an owned page relevant to the question. Report the numerator and denominator alongside the rate.

Count each run once for the rate even if it contains several owned links. Record multiple links in a separate detail table. Keep timeouts, blocked pages and incomplete answers outside the valid-run denominator, but report how many runs were excluded and why. Otherwise a failing collection process can make a rate appear to improve.

Repeat the same panel on a documented schedule and keep individual observations. One answer is a useful reading sample; a trend needs comparable observations. The repeatable comparison protocol explains how to keep collection conditions consistent.

Connect referrals to the landing experience

Inspect the actual landing URLs and source information your analytics receives. Preserve observed campaign parameters and referrers through redirects. Build channel rules from those observations instead of assuming every assistant always sends the same referral signal.

Then review the landing page and the next useful action. Does the page answer the question behind the visit? Can the visitor identify the service, audience and location? Is an enquiry or booking event recorded consistently? A rise in assistant-related visits is less useful if the destination creates a new obstacle.

For a local-service implementation perspective, the published visibility-to-enquiry framework connects discovery, service pages and lead follow-up. Use that operational chain to choose outcome measures; use the platform reports to establish exposure.

Run a short review that ends in decisions

Review the scorecard in this order: data quality, changes by question group, cited landing pages, factual representation, referrals and qualified outcomes. Each meaningful finding should end in a specific action: repair an inaccessible page, clarify a service boundary, improve a source passage or investigate a tracking break.

After a change, preserve the previous record and start a new comparable collection window. Keep release dates alongside the observations so a later reader can tell what was changed and when. The scorecard becomes useful when it explains the next decision, not when it produces the largest number.

• One defined objective and one primary measure
• Separate native exposure, observed citations, visits and outcomes
• Stable prompt panel and documented exclusions
• Saved source exports and answer records
• A clear action, owner and review date