---
name: measure-ai-citations-for-brand
description: "See what AI tools say when people look for a business like yours."
category: Strategy & Measurement
stage: —
definitive_article: https://blitzmetrics.com/how-to-track-if-ai-cites-you/
status: needs-work
---

# Measure AI citations for a brand

See what AI tools say when people look for a business like yours. This guide helps your team keep a fair record and find claims to fix. Start with the brand, the buyer’s problem and the same set of questions.

**The path:** Fixed questions → Observed answers → Separate scores → Source fixes

**Start when:** A brand needs a first baseline or a comparable repeat check of AI answers.

## Inputs

- The resolved business identity, category, service area and real buyer questions.
- Selected AI tools the operator can actually access, with exact prompts and a comparison grid.
- [The AI-citation measurement method](https://blitzmetrics.com/how-to-track-if-ai-cites-you/) and any prior raw answers.

## Steps

1. Write prompts for the exact brand, its category and the problem a buyer wants solved. Record them before the check. Keep branded prompts separate from discovery prompts that do not name the brand.
2. Define the repeat conditions: selected tool, visible model/version when known, mode, date, location/account context and whether browsing is used. Do not invent a model version hidden by the interface.
3. Run the bounded prompt set through available supported access. Retain the exact raw answers and any visible citation URLs; a tool failure is not a negative brand result.
4. Score three separate outcomes: a mention names the brand, a citation links a source, and a recommendation suggests the business for the buyer’s need. Inspect the cited page and whether it supports the actual statement.
5. Repeat key prompts under comparable conditions and retain all observations. Distinguish stable patterns from variation; a small prompt sample is not market share or a universal rank.
6. Compare the observations with authoritative brand facts and the previous grid. Prioritize source corrections that address a verified error or evidence gap, such as a wrong service area or unclear offer page.
7. Save the grid, method and limitations. Hand exact source improvements to the appropriate owner; do not claim that a citation can be guaranteed by a content change.

## Definition of done (QA checklist)

Quality assurance (QA) means checking the result against its agreed requirements; see the [Article Guidelines](https://localservicespotlight.com/article-guidelines/).

- [ ] All prompts, tool conditions, answers and failures are retained.
- [ ] Mentions, citations and recommendations are scored separately and source claims checked.
- [ ] The comparison states its sample limits and gives specific evidence-backed next work.

## Example(s)

**Fictional teaching example. This is not a client result or proof of a completed run.**

In a fictional test, one tool names a shop but links no source. Another links the shop’s hours page without recommending it. The grid records a mention in the first answer and a citation in the second. A later answer differs, so the report shows variation instead of one claimed ranking.

## Handoff and Content Factory context

[Write the agreed weekly report](https://local-service-spotlight.github.io/task-library/?task=submit-weekly-maa-report-every-friday#task-submit-weekly-maa-report-every-friday) receives the trend; the source-page owner receives exact fact or evidence corrections through the [SEO Tree, the map of related pages](https://blitzmetrics.com/seo-tree/).

This work supports the [Content Factory: Produce, Process, Post and Promote](https://blitzmetrics.com/content-factory/) across its relevant stages. It uses the actual inputs and next owner above; a strategy or measurement guide does not manufacture transcripts, clips or other unrelated stage outputs.

## Start with an agent

Give the AI worker this recipe, the real Inputs, the desired result and the actions already authorized. Ask for the saved output, source evidence, passed and failed checks, and the next owner. A skill is a set of instructions. Loading it does not prove access, install a scheduled job or complete the work. Use the [current installation guide](https://localservicespotlight.com/install/) only if reusable setup is needed; a ZIP contains instructions and is not an access grant.

Use the actual supported app and verified source access. A model name is not a promise of browser control, memory or unattended work. For recurring work, inspect the real job’s trigger, owner, timezone and observed firing; this recipe creates no schedule. Before any media playback, mute the player and set volume to zero. A silent review does not prove sound was heard.

## Record the real execution

Open the run record when work begins. Keep one execution ID, the exact starting recipe revision, input sources and actual state. Write a [meta article, the record of one real execution](https://blitzmetrics.com/meta-article-prompt/) with results, checks, failures and next owner. Link it to this task in the [Task Library](https://local-service-spotlight.github.io/task-library/). Writing is required; public release follows existing authority.

Reuse the same execution ID for internal reviews, meta writing, revisions and retries. A blocked run stays open with its dependency and owner, without an invented finish time. Keep historical public examples as dated evidence; article counts alone are not verified execution frequency. Use supported findings to propose and verify a recipe improvement.


<!-- factory-layer:start -->

## Factory chain (do not treat this as isolated)

- **Phase:** —
- **Importance:** 3/5 `●●●○○` — frequency 3, revenue 3, gating 2 (supporting)
- **Suggested previous station:** —
- **Suggested next station:** —
These stations are generated neighbors, not verified prerequisites or handoffs. Follow the task’s actual Inputs and Handoff sections.
- **Handoff:** Save this task’s actual output, source, date and checks where the receiving owner can read them. Follow the Inputs and Handoff sections for its next step.

## Model routing (same factory, any engine)

- **This task's lane:** `any` — Any capable chat model (Claude, ChatGPT, Grok, Gemini). SOP following, drafts, checklists.
- **Single-engine path:** Use the capable AI app you already have. Check its required tools and access before starting. Pass the actual result and proof to the next task.
- **Optional multi-engine:** A tested local model may draft; a stronger model may review facts and voice. Use supported tools for approved actions. Pick models from observed quality and cost; a model name does not prove it can run this task.
- **Never** store the working state in one vendor's memory. Files in the Content Library are the bridge.

<!-- factory-layer:end -->
## Definitive article & links

- [Maintained source guide](https://blitzmetrics.com/how-to-track-if-ai-cites-you/)
- [This task in the Task Library](https://local-service-spotlight.github.io/task-library/?task=measure-ai-citations-for-brand#task-measure-ai-citations-for-brand)
- [Article Guidelines](https://localservicespotlight.com/article-guidelines/)
- [Definitive article and task recipe standard](https://blitzmetrics.com/definitive-article-guide/)
- [How recipes and run records work together](https://localservicespotlight.com/meta-articles/)

## Review and evidence still needed

The inherited contributor status is `needs-work`. It is preserved, not promoted by this rewrite. That label alone does not verify document readiness, account access, an actual execution or a client outcome.

A relevant real execution, source evidence, independent reviewer and accepted handoff remain to be recorded. The fictional example teaches the method and does not fill a real-run evidence gap. The opening and full method need a named semantic reviewer; the task-specific path is source guidance, with visible desktop/mobile presentation still to check.