How to diagnose AI visibility in your category Beyond generic SEO signals.

Separate the outcomes before you explain them

Read What Is AI Citation Share? for source definitions and You Rank on Google, but AI Still Skips You for the SEO/AI split.

Define the category, prompt cluster, and buyer evidence map

Before you measure anything, write down the basics. Specify the offer, market, buyer role, buying stage, comparable alternatives, provider/mode, and test window.

Then decide in advance which buyer questions you will track. Group them into clusters, for example:

• Discovery — first-look questions from a new buyer
• Shortlist — narrowing down a set of options
• Comparison — weighing this brand against alternatives
• Risk validation — checking for dealbreakers
• Urgent availability — can this brand help right now

For each cluster, map the buyer facts that actually matter, such as:

• Integrations
• Security
• Implementation
• Service area
• Hours
• Qualifications
• Price policy

Lock the exact prompt wording, outcome rules, run count, location/language, and competitor cohort before you start. Keep unavailable citations as N/A, not zero. This prevents after-the-fact storytelling and makes it possible to compare results later.

Five candidate-variable families—not ranking factors

B2B SaaS and urgent local service can show different patterns

Measurement design and controls

Fictional illustrative two-cohort example

Everything below is fictional: not client data, a benchmark, or causal proof. Northstar Workflow, a fictional B2B SaaS company, tests 24 prompts: 216 scheduled / 208 valid . Harbor City Heating, a fictional urgent local service, tests 18 prompts: 162 scheduled / 156 valid . Results stay within each fixed market/provider panel; they are not pooled.

The only defensible summary: different evidence gaps were associated with different outcomes in fictional, defined panels. Samples are not benchmarks; confounding remains plausible.

Use an ethical test plan and remeasure

Some tactics are off-limits, no matter how tempting. Do not:

• Manufacture reviews
• Buy undisclosed endorsements
• Create fake citations
• Manipulate online communities

Instead, remeasure the same panel after doing real work. When you report results, include valid runs, N/A citations, provider context, and the change log. Say “associated with” and “worth testing.” Never say “caused.” See Why One AI Visibility Scan Is Not Enough and Where Should You Publish Next? .

Code the answer before you look for an explanation

Teams often call every brand appearance a “win.” That turns a mixed answer into a flattering metric, which makes later diagnosis impossible. Write the coding rules before you collect a panel. Apply them to every valid run, and keep the raw answer beside the coded result. A person who did not write the hypothesis should be able to inspect the rule and reach the same label.

Keep a separate unknown state. If an answer says “may offer 24/7 service,” treat that as a mention. It is not automatically an accurate availability claim. If a provider shows a domain with no clear link to the sentence, record the citation as displayed. Leave claim support marked unknown. These distinctions protect both the score and the buyer from false certainty.

Plan for valid runs, exclusions, and uncertainty

A scheduled run is not necessarily evidence. A response can fail in several ways:

• Fail outright
• Return a safety refusal
• Ignore the requested market
• Truncate before a list
• Expose no citations
• Be so malformed it cannot be coded

Define exclusions in advance. Keep every excluded run in the export, with its reason. Never quietly remove a result because it weakens a narrative.

There is no magic sample size that turns an AI visibility scan into a causal study. The right panel size depends on the number of buyer intents, markets, products, and decisions at stake. What matters is that the panel is large enough, and repeated enough, to support a decision. The team also needs to state its uncertainty honestly. If only eight runs were valid for a high-intent cluster, say so. Do not dress it up with percentages that imply more certainty than you have.

Look for competing explanations before funding a “driver”

Category comparisons are especially easy to get wrong. Recommended companies can differ in many ways at once, so a pattern you notice may not have the cause you assume. A competitor might simply have:

• More reviews
• Clearer pages
• Longer market history
• Stronger direct demand
• A better-known founder
• Different availability
• Sources that changed during the collection window

An observed relationship does not isolate any one of those differences.

A useful counterfactual question is: What else changed, or what else differs, that could plausibly explain this result? If the answer is “several things,” fund the most buyer-useful, reversible improvement. Label it a test, not a proven lever. This is more honest than claiming that a backlink, DA score, review count, or citation created a recommendation.

DA and backlinks belong in the evidence file only as candidate SEO measurements. They can line up with other useful things, like discoverability or editorial coverage. But DA is a proprietary third-party metric, not a universal AI selection factor, and neither is any other single measure. A high-DA site with weak claim fit may be less useful to a buyer than an accurate specialist, local, or product-specific source. Do not buy links, fabricate endorsements, or treat authority scores as a shortcut around evidence quality.

A practical 30-day diagnostic cycle

The goal of a cycle is not to “hack” an answer. It is to make one material buyer fact more useful, measure a defined outcome, and decide whether the next action still deserves attention.

1. Days 1–3: frame the decision. Name the buyer segment, question cluster, market, products, competitor cohort, outcome definitions, and baseline window. Identify the decision that would change if the evidence moves.
2. Days 4–7: collect and code the baseline. Run the fixed panel with planned repetitions. Keep track of scheduled, valid, excluded, and citation-unavailable counts. Verify the key answer facts against primary records.
3. Days 8–11: inspect the evidence gap. Compare accurate owned facts, eligible profiles, documentation, independent context, and competitor framing. List alternative explanations before proposing work.
4. Days 12–20: ship one truthful, buyer-useful improvement. For example, clarify a verified implementation requirement, correct an eligible service-area profile, or publish a supportable comparison. Keep the owner, approval, URL, date, and policy constraints in the log.
5. Days 21–30: re-check and decide. Re-run the same priority cluster where feasible. Compare outcomes with the change log and cohort, and report the uncertainty honestly. Then continue, adjust, or stop based on what you learned, not on one lucky answer.

Some work needs longer than 30 days to be discoverable or to change buyer evidence. That is fine. The re-check can confirm publication and factual availability before it claims any AI outcome. Do not force a conclusion simply because a reporting calendar ended.

Keep a decision log that a buyer can audit

A dashboard score alone cannot explain why a team spent money or why a recommendation changed. Instead, keep the smallest useful record: one row per hypothesis, with one linked folder of evidence. A future reviewer should be able to see the claim, the baseline, the actual change, and the uncertainty. They should not have to reverse-engineer a presentation to find it.

What the two fictional cohorts would do next

For Northstar Workflow, the buying committee needs implementation, integration, and security facts accurate enough to survive a risk-validation question. The right next action is not “get more backlinks.” It is to verify the product documentation against primary records. It also means making the implementation boundaries clear, and letting legal and security owners approve claims before publication. The re-check should ask two things: do the answers remain accurate, and is the product framed as an eligible option? It should not ask whether a documentation page “caused” a selection.

For Harbor City Heating, an urgent buyer needs a real service area, live availability, qualification, and safe contact path. The team should correct the facts it controls and use legitimate platform correction processes. It should not create fake local coverage, filter out negative reviews, or claim emergency service it cannot deliver. The next panel should measure factual accuracy and shortlist inclusion separately. It should also record any provider or weather-driven changes that could explain the result.

Frequently asked questions