How to prepare for an AI Visibility Audit: The Six-Step Process

Prepare an AI visibility audit by documenting the brand, priority buyers, question contexts, approved test questions, and rules for collecting and reviewing evidence. Preparation defines what will be tested and how results will be compared; execution and analysis then turn that plan into recorded answers, supported findings, and implementation priorities.

Key Takeaways

• Verify the brand’s names, products, domains, and known competitors before writing questions.
• Choose priority buyer situations rather than trying to represent every possible customer in one run.
• Separate unbranded, category-led, competitor-led, and brand-led scenarios because they test different kinds of discovery and recognition.
• Approve question versions, follow-up rules, stop conditions, provider surfaces, and repetition plans before testing.
• Plan the evidence records, outcome definitions, review responsibilities, and retest criteria before collecting results.

---

Introduction

An AI visibility audit needs a documented research plan so the team can explain what each answer represents and recover the evidence behind its conclusions. An informal check can reveal a question worth investigating, but it does not establish a recurring pattern or explain why an assistant produced an answer.

The six stages below connect preparation to execution and analysis. Complete the planning outputs before the first run, then use the linked guides for the detailed work.

The table describes preparation outputs. Testing and analysis still require execution, review, and judgment; a completed plan does not guarantee a particular visibility result.

---

Step 1: Brand Identification

Brand identification records which entities the audit will recognize as the target brand, related products, and competitors. Start with the homepage, about page, core product or service pages, documentation, and positioning pages that best describe the current offering.

What to prepare:

• The primary brand name, aliases, abbreviations, former names, and relevant product names.
• The problems the offering addresses, intended audiences, supported capabilities, and important limitations.
• Owned domains and related properties, with the relationship between each company, product, and website stated.
• Known competitors and alternative approaches, including their names and domains.
• A candidate audience list to narrow during persona design.

An LLM can help draft this register from approved source pages. Have a person verify it against the source material, resolve conflated products or companies, and mark unknowns before using it to classify results.

Why it matters: A name match is useful only when it refers to the correct entity. Clear brand mapping helps reviewers recognize product-name references without attributing another company’s answer to the target.

Read the detailed guide to mapping your brand before an audit.

---

Step 2: Persona Design

Persona design defines the buyer situations the audit should represent: who is asking, what they need to decide, and which constraints shape the question. Use customer research, sales discussions, support questions, or other available evidence to inform the scenarios.

What to prepare:

• A prioritized set of distinct roles and company contexts.
• The problem, goal, decision responsibility, and constraints for each scenario.
• Natural phrases the buyer would use, including category or vendor terms they would already know.
• The evidence behind the persona and any assumptions that still need validation.

Three to five personas can be a manageable starting set for a focused audit, but there is no universal required count. Choose coverage for the decisions the work must support, and label designed scenarios where direct buyer evidence is limited.

Why it matters: Questions from an operational buyer and a procurement buyer can test different needs even when both concern the same product. A documented context makes those differences available to the reviewer.

Read the detailed guide to designing test personas.

---

Step 3: Intent Mapping

Intent mapping connects each buyer situation to the questions that matter at different decision stages. A useful map can include diagnostic, educational, comparison, transactional, tactical, and brand-aware intents where they fit the scenario.

Record question context separately from intent:

• Unbranded: the buyer describes a problem without naming a vendor or solution category.
• Category-led: the buyer names the category but no vendor.
• Competitor-led: the buyer introduces a competitor.
• Brand-led: the buyer introduces the target brand.

For each relevant combination, write what the buyer is trying to accomplish and what a useful answer would contain. Leave irrelevant combinations out rather than filling a grid solely for completeness.

Why it matters: Context changes what the assistant receives as input. Keeping these groups separate helps distinguish independent discovery from treatment after the buyer provides category or brand information; it does not assume which group will have the largest gap.

Read the detailed guide to defining what is worth testing.

---

Step 4: Question Development

Question development turns the approved scenario into the actual opening and execution rules used in the test. Preserve the buyer’s problem, vocabulary, and level of prior knowledge without adding a favorable premise or a vendor that the scenario was meant to exclude.

What to prepare:

• A core question and approved phrasing variants for each scenario.
• Stable identifiers, wording versions, and effective dates.
• A conversation goal and a description of a useful answer.
• Follow-up rules, a stop condition, and a turn cap where applicable.
• A brand-introduction policy stating whether and when the tester may name the target.
• A frozen benchmark for comparison and a separately identifiable exploratory set.

Choose the variant count and planned repetitions for the research decision. A few variants can reveal wording sensitivity, but no count alone establishes a reliable pattern. Questions that add a category, vendor, or new constraint may represent a different scenario rather than a wording variant.

Why it matters: The reviewer needs to know which situation was actually tested. Versioning prevents an apparently comparable rerun from silently measuring a different question.

Read the detailed guide to writing buyer-style test questions.

---

Step 5: Test

Before executing AI visibility tests, define the provider products and interfaces in scope and how each answer will be recorded. Choose single-turn or multi-turn testing according to the buyer scenario; full conversations are useful when the decision involves follow-up questions.

What to prepare:

• The provider, product surface, locale, session rules, and observable settings to record.
• The question-variant allocation and repetition plan for each surface.
• One conversation record with complete questions, answers, timestamps, and stable identifiers.
• Separate fields for visible citations and retrieved or search-result sources where exposed.
• A rule for recording failed tests, absent generated answers, and unavailable source evidence.

Keep API and consumer-interface results identifiable. Record model information only when exposed, and mark unavailable conditions instead of inferring them from the answer. Preserve when the tester introduces the brand during a follow-up.

Why it matters: Brand absence in a captured answer differs from a failed test or a surface that produced no answer. Evidence and coverage records keep those outcomes from being combined incorrectly.

Use the detailed test-conversation protocol and downloadable log when executing the plan.

---

Step 6: Analyze

Analysis reviews the complete evidence under written definitions, then groups observations into findings relevant to the buyer decision. Plan those definitions and responsibilities before the run so labels are not invented to fit the results.

What to prepare:

• Definitions for qualified visibility, independent versus prompted treatment, recommendation, framing, displacement, and citation outcomes.
• Eligible-record denominators and a way to report excluded or unevaluated records.
• Breakdowns by buyer context and provider surface, with other relevant groups kept available.
• Reviewer responsibilities, a shared calibration sample, and a process for disagreements.
• A handoff format linking observations, hypotheses, checks, priorities, owners, and retest criteria.

An absent brand, an uncited owned page, or a competitor recommendation identifies an observation to investigate. It does not establish a content, authority, or technical cause. Check the current pages, sources, and relevant access evidence before choosing the action.

Why it matters: A supported finding can lead to an existing-page revision, technical investigation, third-party profile correction, or a decision to collect more evidence. A new page is only one possible outcome.

Continue to turning test data into actionable findings, then use the practical content build-list guide to assign supported content work.

---

Frequently Asked Questions

What should be ready before the first test?

Prepare a verified brand register, priority buyer scenarios, approved question versions, execution rules, provider-surface and repetition plans, and an evidence log. Agree on outcome definitions and review responsibilities before collecting answers.

Do we need every persona and provider in the first run?

No. Scope the run to the decisions and buyer experiences that matter most. State what is covered, what is omitted, and how limited coverage affects the conclusions; expand deliberately rather than implying a small sample represents every buyer or surface.

Can we use an LLM to prepare the audit?

An LLM can draft brand profiles, scenario candidates, and question variants from approved material. A reviewer should verify factual claims, check buyer fit, remove unintended cues, and approve the versions that will be tested.

How do we keep a later audit comparable?

Preserve the benchmark questions, context labels, execution rules, and outcome definitions with their versions. Record provider conditions, actual repetitions, and evaluation coverage for each cycle, and report material changes before interpreting differences.

---

What Comes Next

Preparation ends with an approved plan and records that another reviewer can understand. Execute the tests, review the saved evidence, and connect supported findings to specific implementation decisions rather than treating planning completion as an audit result.

For how discovery, relevance, authority, and framing connect across the process, see the AI visibility audit overview.

If you would rather see your brand’s starting point before working through the process yourself, fill out the form below.