For Brands: AI Visibility Diagnosis in 5 Steps

Begin with a decision your team needs to make

An AI visibility audit should produce a defensible next action. “The brand was absent from one answer” is an observation, but it does not identify a cause or justify a website rebuild. A useful diagnostic connects the observed answer to a specific question, source, product fact, and possible change.

Choose a product, market, and buyer problem before collecting samples. A developer evaluating an API and a procurement team evaluating a managed service may use the same brand name while needing different information. Combining them into one score can hide the very gap you are trying to investigate.

This guide follows the diagnostic from question selection to a reviewable handoff. It is not a recipe for a guaranteed mention. For the broader distinction between search performance and generated answers, start with GEO vs SEO.

Step 1. Record a baseline for real buyer questions

Build the question set from decisions customers actually face. Use sales questions, support conversations, search queries, and product comparisons as inputs, removing personal or confidential information. Keep a note of why each question belongs in the set.

For a fictional customer-support platform, a small planning example could include:

• Discovery: “Which support platforms suit a multilingual team with shared email queues?”
• Capability: “Which help desks let supervisors audit changes to routing rules?”
• Comparison: “What should a small support team compare when choosing between shared-inbox and ticketing software?”
• Brand accuracy: “Does Example Support include audit logs on its entry plan?”

These questions serve different purposes. The first three can reveal whether the brand appears without being supplied in the prompt. The last checks what an answer says about a named product. Keep that branded check separate from discovery measurement; prompting with the brand name makes its appearance much less informative.

There is no universal question count that makes a diagnostic representative. Begin with the buying situations you can explain and review. Repeated sampling can expose answer variability, but repeating a narrow question many times does not make it representative of an entire market. For a fuller collection method, use the brand-mention measurement guide.

For each observation, retain the exact question, complete answer, provider or product, available model identifier, sampling mode, collection time, and returned citations. Save failures separately. A failed request cannot tell you whether the model would have mentioned the brand.

CiteAura labels API model-knowledge responses, API web-grounded retrieval, and manually recorded product-surface answers separately. Its matrix mention rate excludes unsuccessful samples and questions containing the configured brand name. Inspect the raw answers as well as the percentage: a recommendation with the wrong plan limit is not an unqualified success.

Step 2. Check whether the relevant page is accessible

Inspect the page that should answer the question, not just the homepage. Confirm its public URL, response status, readable content, and any authentication, robots, indexing, or firewall restrictions. A healthy homepage does not establish that the pricing or integration page is accessible.

On a site you manage, a basic HTTP check can start with the following commands. The domain is an example; substitute the exact public page:

curl --location --silent --show-error \
  --output /tmp/product-page.html \
  --write-out 'HTTP %{http_code}\nFinal URL %{url_effective}\n' \
  https://example.com/product

curl --location --silent --show-error \
  https://example.com/robots.txt

Open the downloaded HTML and look for the actual answer the buyer needs. If the browser displays it but the response body does not, investigate how the page renders and what the relevant retrieval system can access. This is a dependency to examine, not proof that every AI crawler rejects JavaScript.

A successful cURL request proves that this client received a response. It does not prove a named search crawler has visited or indexed the page. Conversely, an automated client receiving a challenge does not mean the page is unavailable to every visitor. Use site logs and the provider’s published crawler guidance to narrow the diagnosis.

For ChatGPT search, OpenAI documents OAI-SearchBot separately from GPTBot. Do not treat permission for training crawls as permission for search crawling. For Google AI features, Google requires supporting pages to be indexed and eligible for a Search snippet; its ordinary technical and content guidance still applies.

The output of this step should be a specific access finding, such as “the public integration URL redirects to a sign-in page,” with the URL and observed response attached. “Improve crawlability” is too broad to hand to an engineer.

Step 3. Reconcile the answer with current product facts

Compare questionable claims with an authoritative product source. Pricing pages, versioned documentation, release notes, and official policy pages can establish what the company currently offers. A model answer is an observation to inspect, not the authority that decides whether a feature exists.

Suppose an answer says audit logs are included in an entry plan, but current pricing reserves them for Enterprise. First check the citations. An old launch article may still state the earlier packaging, or the answer may cite a page that does not support the claim at all. Those situations call for different follow-up.

Make a compact discrepancy record: the exact claim, the observed source URL if any, the current official source, the date checked, and the person responsible for confirming the product fact. If the evidence is incomplete, record it as unresolved. Do not label a statement false solely because your first search failed to verify it.

Correct contradictions on pages you control. Give important facts a clear home and link supporting pages to it. CiteAura’s Brand Fact Library can maintain inputs for generated content and delivery assets, but changing a workspace fact does not change a provider’s answer or publish a correction to your website.

Review structured data alongside the visible text. Google’s structured-data policies prohibit misleading markup and information that does not reflect the page. A useful fact library can help maintain consistency; schema and an optional llms.txt file cannot turn an unsupported claim into a verified one.

Step 4. Write a ticket with an observable acceptance condition

A good ticket names the change and the evidence needed to close it. “Increase AI visibility” is a program objective. “Publish the audit-log plan requirement on the integration page” is work a team can implement and verify.

The following is an illustrative manual brief, not an automatically generated CiteAura result:

Finding

The integration page omits the plan requirement for audit logs.

Evidence

Current page capture, current pricing source, and the saved answer that described the feature incorrectly.

Requested change

Add the supported plan requirement beside the feature description and link to the relevant pricing section.

Acceptance

The canonical public page displays the approved statement; the pricing link resolves; relevant structured data does not contradict it.

Follow-up measurement

Repeat the same brand-accuracy question in the same collection mode and inspect the new answer.

Keep the website acceptance condition distinct from the follow-up measurement. An engineer can finish the page correction even if the next model answer remains wrong. That result warrants further investigation; it does not mean the deployment never happened.

Prioritize a material access failure or incorrect commercial claim before polishing low-impact wording. Estimate effort with the team that owns the affected system. A small text correction and a rendering change have different costs, and a generic “two-hour GEO fix” estimate conceals that difference.

In CiteAura, Action Tickets and Assets & Templates support this handoff. Review generated material against approved facts before deployment. When GitHub publishing is configured, approved assets can be sent through a branch and pull request for review; CiteAura does not automatically merge that request.

Step 5. Verify the website, then review a comparable sample

After deployment, check the public page against the ticket. In CiteAura, Closed-Loop Verify re-crawls and audits the site, then evaluates ticket acceptance checks using the latest audit and existing metrics. Some results require manual review. Running verification does not collect fresh AI answers.

Start a separate sampling run when you need a new answer cohort. Keep the question set, model configuration, market, and sampling mode comparable, and record anything that changed. Compare the actual answers before interpreting the aggregate. A percentage increase across a changed question set does not establish an improvement on the original task.

The GEO verification guide shows how to separate deployment evidence from answer changes. For the final review, report what was changed, what passed, what remains unresolved, and whether the new sample is comparable. If no new answer has been collected, say that visibility has not yet been remeasured.

You can build a CiteAura diagnostic pack before all implementation work is complete. Review its readiness and remaining limitations before sharing it; a diagnostic package is not a statement that every included asset is ready to deploy. The delivery documentation explains those distinctions.

A useful audit ends with a decision the team can act on: fix an identified access problem, correct a documented inconsistency, answer a missing buyer question, or gather more evidence. If you need that starting point, begin with an AI visibility audit and keep the scope attached to the evidence.