AI Search Visibility Tracker Template

An AI search visibility tracker should preserve the exact prompt version, run conditions, answer evidence, mentions, citations, review verdict, owner, and next verification date. It should keep “not run,” “tool unavailable,” “no mention,” and “no visible citation” as different states. Without those distinctions, a clean-looking dashboard can produce false trends.

The short answer

Start with one flat tracker if the team is learning the workflow. Use one row per prompt-surface run and include stable prompt IDs, exact wording, surface, locale, timestamp, run status, mention and citation fields, evidence, reviewer, gap type, owner, action, and next run. Move to linked tables when prompts, citations, or actions become many-to-one.

Copyable tracker

Create these fields in a spreadsheet, database, or shared workspace:

The accompanying Dokki template uses a compact subset of these fields so a team can start immediately. Add fields only when the workflow can maintain them.

Use explicit states

Do not use a blank cell for several meanings.

Run status

• Completed: the answer was produced under declared conditions.

• Failed: an attempted run returned an error or unusable result.

• Unavailable: the surface, account, model, or required feature was not accessible.

• Excluded: the run violated the protocol and should not enter the denominator.

• Not run: the scheduled observation has not happened.

Citation status

• Yes: at least one visible citation was exposed.

• No: the completed answer visibly exposed no citation.

• Not exposed: the surface did not provide a source interface that could be evaluated.

• Pending review: citations exist but have not been checked.

• Not applicable: the observation is outside the citation metric's eligible population.

Mention status

A failed or unavailable run is not a “No.” Only an eligible completed answer can become Brand mentioned = No.

Example record

The following example is deliberately unrun. It illustrates the schema without pretending to be visibility evidence.

Never seed a live dashboard with invented “sample results” that can be mistaken for an observation.

The scalable four-table model

A flat tracker is easy to start but repeats prompt text and cannot represent several citations or several accepted actions cleanly. When volume grows, split the system into four linked tables.

1. Prompt registry

One row per prompt version:

• prompt ID and version;

• cluster, persona, intent, and decision stage;

• exact prompt and controlled variants;

• locale and language;

• surfaces;

• cadence and owner;

• active dates and retirement rule.

Prompt records are definitions. Do not overwrite an old row when wording changes materially; create a new version.

2. Run log

One row per prompt-surface execution:

• run ID;

• prompt ID/version relation;

• timestamp and timezone;

• surface and visible product state;

• locale, account state, and conversation state;

• run status and failure reason;

• answer evidence;

• mention fields;

• reviewer and QA state.

The run log is append-only observation evidence. Corrections should retain the original value and reviewer trail.

3. Citation log

One row per visible citation:

• run ID relation;

• displayed URL and final URL;

• publisher and source type;

• owned, competitor, or third-party classification;

• answer claim associated with the citation;

• support verdict and reviewer;

• canonical/live verdict;

• review timestamp.

A run can have zero, one, or many citations. Separating this table prevents a flat row from hiding all but the first source.

4. Change and verification queue

One row per accepted response:

• gap type;

• supporting run and citation IDs;

• canonical content resource;

• proposed change;

• owner and due date;

• authority required;

• acceptance criteria;

• publication or technical verification;

• next prompt run;

• outcome and learning.

Observations remain immutable while decisions evolve.

Core formulas

Only eligible runs enter the denominator.

Execution coverage

Execution coverage = successful eligible runs ÷ planned eligible runs

This metric reveals whether the tracker observed the market question at all.

Mention rate

Mention rate = eligible completed runs with a brand mention ÷ eligible completed runs

Segment unaided and branded prompts. Do not blend them.

Owned citation rate

Owned citation rate = eligible completed runs citing an owned canonical URL ÷ eligible completed runs

Resolve redirects before classifying the URL.

Accurate-description rate

Accurate-description rate = reviewed mentioned runs judged accurate ÷ reviewed mentioned runs

Pending reviews stay outside the denominator.

Citation support rate

Citation support rate = reviewed citations that support the associated claim ÷ reviewed citations

A visible URL is not automatically a supporting citation.

Competitive mention share

Competitive mention share = declared mention events for the tracked brand ÷ declared mention events across the versioned competitor set

State whether one event means a run, a unique brand per run, or every mention.

For a fuller discussion of metric definitions and denominators, read AI Search Visibility Metrics after it is published.

Views that make the tracker useful

Collection health

Filter scheduled runs by Run status and Next run. Show failed, unavailable, late, and excluded observations separately.

Accuracy risk

Show mentioned runs with Description accuracy = Inaccurate or Partly accurate, grouped by the missing qualifier or stale claim.

Citation opportunities

Group uncited or weakly supported prompts by cluster and source type. Look for repeated evidence gaps rather than one-off missing links.

Owned-page coverage

Group citation rows by final canonical URL. This reveals which owned pages are repeatedly selected and which priority topics have no citeable destination.

Action queue

Show accepted changes by owner, due date, authority, acceptance criteria, and next verification. Do not treat a suggestion as committed work until an owner accepts it.

Executive trend

Show raw counts beside rates for a stable prompt panel. Include panel version, surfaces, market, window, and coverage on the same screen.

Weekly workflow

Monday: verify collection

Check scheduled runs, failures, unavailable surfaces, prompt versions, and changed product states. Repair measurement gaps before reading the trend.

Tuesday: review mentions and citations

Normalize brand entities and final URLs. Review ambiguous mentions, inaccurate descriptions, negative framing, and whether citations support the associated claims.

Wednesday: diagnose patterns

Group findings by prompt cluster and gap mechanism. One missing mention does not justify a new article. Repeated passage, evidence, comparison, authority, or distribution gaps are stronger signals.

Thursday: assign one action

Attach the evidence to one canonical resource, owner, acceptance condition, and authority boundary. Prefer the smallest intervention that can be verified.

Friday: verify release state

If an authorized change shipped, verify public HTML, metadata, canonical identity, images, internal links, and sitemap. Schedule the next comparable prompt run. Do not claim an AI-visibility outcome on release day.

QA rules

Before reporting a trend, confirm:

• the prompt and competitor-set versions are unchanged or the break is labeled;

• the same surfaces, markets, languages, and observation windows are compared;

• failed and unavailable runs are not counted as negative results;

• raw answer evidence is retained;

• every citation resolves to the final canonical URL;

• accuracy and citation support have reviewer names and dates;

• branded and unaided prompts are separated;

• provider-modeled metrics are not blended with controlled panel counts;

• search traffic, referral traffic, and business outcomes remain distinct;

• the sample size and raw counts are visible;

• no private or customer-sensitive content appears in stored evidence.

When a single table is no longer enough

Move to the four-table model when:

• one prompt runs on several surfaces or locales;

• one answer contains several citations;

• prompt versions change over time;

• several reviewers classify the same evidence;

• multiple actions arise from one pattern;

• access control differs across raw answers, citations, and executive reports;

• automation writes data concurrently;

• immutable observations and mutable decisions require separate histories.

At that point, add stable IDs, relations, validation rules, permissions, and compare-and-set updates. The goal is not database sophistication; it is preserving evidence while the operating decision changes.

When not to automate

Keep collection manual when the panel is still changing, labels are ambiguous, source evidence cannot be retained safely, or reviewers disagree about accuracy. Automation can scale a weak schema faster than a team can notice the error.

Automate only after:

1. prompt identity is stable;

2. failure and unavailability states are explicit;

3. evidence retention is policy-compliant;

4. reviewer rules are reproducible;

5. duplicate writes are idempotent;

6. an owner monitors collection health;

7. a human still reviews material claims and citations.

Frequently asked questions

What should an AI visibility tracker include?

At minimum: stable prompt ID/version, exact prompt, surface, locale, timestamp, run status, answer evidence, mention status, citation status and URL, accuracy/support review, gap type, owner, action, acceptance criteria, and next run.

Should every prompt have the same cadence?

No. High-value category and comparison prompts may run weekly during active work. Stable implementation prompts may run monthly. Record the cadence per prompt and compare compatible windows.

Can I record a tool error as zero visibility?

No. A tool error, unavailable surface, and unrun prompt are measurement states. They do not describe the answer and should not enter a visibility denominator.

Is a spreadsheet enough?

A spreadsheet is enough for an early, bounded panel. Use linked tables when prompts, runs, citations, reviewers, and actions become many-to-one or require different permissions.

Should the tracker calculate one AI visibility score?

Only if the component metrics, weights, denominator, panel version, and limitations remain visible. Operational teams usually make better decisions from separate metrics.

Does a citation mean the source influenced the answer?

A visible citation shows that the interface associated the source with the answer. It does not by itself prove a causal pathway. Review whether the source supports the claim.

How is this different from an AI visibility tool?

The template governs prompt identity, evidence, review, ownership, and verification. A tool may automate collection or model market-wide visibility. The workflow still needs an evidence contract.

Sources

• Ahrefs: AI Visibility Metrics

• Ahrefs Brand Radar methodology

• Google Search Central: AI features and your website

• Google Search Console Performance report

• How to monitor AI search visibility

• SEO Audit Template for Human + AI Teams