AI citation audit template: a manual source review worksheet

An AI citation audit template records which sources an AI answer links to, whether those sources support its claims, and what a reviewer should fix next.

This worksheet is for a small SEO or content team reviewing answers manually. It provides two blank CSV files, a consistent labeling system, and a worked example. It requires no API key or automated generation service; using a search product remains subject to that product's access and usage limits.

What does an AI citation audit check?

A citation audit connects an observed answer to the actual pages behind its links. It asks three separate questions: did the answer mention the brand, did it cite an owned page, and did the cited page support the claim beside that citation? A positive answer to one does not establish the others.

OpenAI's ChatGPT search documentation distinguishes citations from the wider Sources list, which can also contain other relevant links. It also advises opening sources to check their support and currency. Our worksheet therefore separates a citation attached to a claim from a link merely listed alongside the answer.

For the broader measurement context, start with AI search visibility. This article focuses on the review record, rather than setting a universal visibility benchmark or promising more citations.

Download the two-part worksheet

Import these blank files into two tabs in your spreadsheet application:

• Answer log CSV: one row for each attempted answer capture.
• Citation log CSV: one row for each claim–source pair you inspect.

Join the tabs with observation_id, a unique identifier such as review-001. An answer can have several citation rows, or none. Keep the answer row in both cases. Otherwise a source-heavy response receives more weight than an answer with one citation, and answers without citations disappear from your denominator.

The files contain headers only. The examples below are fictional illustrations of how to fill them, not results from a Tracemetry experiment.

Answer log: preserve the conditions

Record what you can observe. A displayed product name is not proof of its internal model version. A requested market is not proof that the product used that location. Use the notes field to preserve that distinction.

Citation log: inspect the claim and destination

Use not_found when the retrieved page does not contain support for the claim. Use not_reviewed when a block, login requirement, or unavailable page prevents assessment. An inaccessible source is not evidence that the claim is false. Record a repeated source once per distinct claim you review; count unique answer IDs when summarizing answers.

Run a review without changing the question halfway through

1. Choose a decision and a small fixed question set. For example, review questions about one product's integrations before revising its integration page. Include questions customers actually ask. Keep exploratory questions in a separate cohort.
2. Write down the conditions. Select the product, surface, language, intended market, and session procedure. Record whether you used a new conversation or a follow-up. Keep comparable captures together; record any change rather than silently mixing it into the series.
3. Capture the unedited answer. Save the timestamp, exact prompt, visible citations, and enough context for another reviewer to understand the result. Use evidence storage your team is authorized to share, and avoid including private account details in public reports.
4. Open each relevant citation. Compare the adjacent claim with the destination's actual text. Save the shown URL as well as the final destination. A redirect to a homepage can be a materially different source from the intended documentation page.
5. Assign labels before proposing edits. First record the evidence; then choose an action. If you ask a follow-up that requests a particular source, log a new observation instead of replacing the initial answer.
6. Recheck using the saved procedure. Keep both observations. A changed answer is a new sample; it does not erase the earlier result or establish why the answer changed.

This procedure improves comparability without making outputs deterministic. OpenAI documents that location and saved memory can affect its search behavior. Google also says AI Mode and AI Overviews can use different methods and show different links. Treat each surface and context as its own observation series. See Google's explanation of AI search features.

Worked example: a mention, a citation, and an unsupported claim

Imagine a fictional product, ExampleDesk, and the question: “Does ExampleDesk support offline exports?” Three captures produce the following review records:

In this illustration there are two complete answers, one citing the owned domain: 1 ÷ 2 = 50% for that narrowly defined sample. It is not 1 ÷ 3, because the failed capture is not an observed answer without an owned citation. Report the failed attempt separately.

Nor does the second answer become correct simply because it contains a plausible link. The reviewer must check whether the source supports the specific offline claim. For a wider correction process, see monitoring AI answer accuracy.

Calculate rates from answers, and report uncertainty

Define the eligible cohort before computing a percentage: the same question set, surface, relevant conditions, period, and completeness rule. From complete answer rows with known citation status:

Owned citation rate = distinct answers with an owned-domain claim citation
                      / distinct assessable answers
                      x 100

Count a claim citation, not a related link. An answer citing three owned pages still contributes one to the numerator. An owned-domain citation to a different page counts for domain coverage, while a target-page match requires checking the destination separately.

Publish the raw numerator and denominator beside the percentage. List partial, failed, and unknown observations separately, plus repeated attempts. Repeated answers to one question should not silently outweigh every other question; report per-question results or use the same repetition rule across the cohort.

These are descriptive sample counts. A small, selected prompt set does not establish population-wide visibility or a causal lift from an edit. When a previously observed citation disappears, preserve the records and investigate using the citation-decay guide.

Turn observations into a short correction queue

Prioritize an incorrect claim that could mislead a reader over a harmless change in source order. For each issue, choose one owner and one inspectable next action:

• An owned source is outdated: update the underlying fact and its evidence, preserving a useful existing URL.
• The answer cites an ambiguous passage: make the qualification, limitation, or definition explicit on the source page.
• The relevant Google source is not eligible: investigate indexing and snippet eligibility before rewriting the article. Google's technical guidance for AI features sets those eligibility requirements and does not promise inclusion.
• A third-party source contradicts current documentation: record both passages, verify the authoritative fact, and route a proposed correction to the appropriate person.
• Only one capture changed: collect more comparable observations before attributing the difference to your content.

Keep Search Console evidence alongside this queue, rather than merging its impressions into your prompt counts. Google's Generative AI performance report documentation describes impressions for supported Google features; these are a different unit from manually captured answers. Our report interpretation guide explains that distinction.

The useful deliverable is a traceable record: this answer made this claim, this destination did or did not support it, and this person will review the proposed correction. Start with the two CSV tabs and complete one review before expanding the question set.