Audit how AI describes your product

An AI audit starts with a question you can investigate. Pick one buying decision, save what an assistant actually says, and compare its claims with current product facts. You’ll finish with a documented issue and a repair someone can check.

This workbook is for B2B founders and small marketing teams who need to distinguish a misleading description from a missing mention, a website obstacle, or simply too little evidence. You can run it yourself with permitted public information and a spreadsheet. The search and SEO manual covers page improvement and recurring measurement in more depth.

Start with facts you can defend

Create a product-facts record before asking an assistant to assess your company. List the intended buyer, supported job, important requirements, integrations, and limits. Attach a current documentation link or name the person who can verify each fact. A homepage slogan won’t settle a question about a specific integration.

Keep public facts separate from internal information. Use only material you’re permitted to submit to the chosen service. A fact that can’t be verified stays unknown. An assistant agreeing with your assumption doesn’t verify it.

For a teaching example, consider an imaginary service-team handoff product. The example fact sheet says it imports a CSV of closed deals, and someone must assign the delivery owner. It does not claim a native CRM connection. These are fictional teaching facts, not a JAC product or client story.

If an answer says the product automatically syncs with every CRM, the fact sheet lets you identify a specific unsupported capability. If the answer doesn’t mention the product at all, that’s a different observation. Preserve both distinctions.

Choose questions that test a buying decision

Include a branded question to inspect description accuracy and an unbranded question to inspect discovery. For the teaching product, these might be “How does this handoff product work?” and “What can a small service team use to manage client handoffs?”

Treat those questions as hypotheses until sales notes, support questions, or search evidence show buyers using comparable language. Record the source and date. Remove personal details from shared notes.

Choose a manageable panel you can repeat. Write a panel version beside it. You don’t need a prescribed number of prompts or an unexplained weighted score. The useful constraint is that you can inspect every answer and explain why each question belongs.

Record the observation before interpreting it

Run questions only in services you’re permitted to use. Save the exact question, platform, surface, observation time, locale, visible settings, and response evidence. A consumer app and an API are separate samples. A new session, enabled search, or changed question can affect comparability.

Use one row per attempt. If a request fails, record the failure and leave the outcome fields blank. Don’t turn unavailable data into a zero mention. Preserve evidence in an approved location, with any private information removed from a shared copy.

Field	Record	Avoid
Mention	Whether the completed answer names the company	Treating a request error as absence
Owned citation	A link to a verified owned URL	Calling every external source an owned citation
Recommendation	Whether the answer suggests the product for the stated need	Assuming a name or link means endorsement
Description accuracy	Claims checked against the fact sheet	Judging facts from the assistant’s confidence
Source presence	What a cited page actually contains	Guessing from a domain name

Native platform reports provide another kind of evidence. Bing’s AI Performance documentation explains that its citation counts don’t establish placement or the role of a page in an individual answer. Keep those aggregates separate from the answers you’ve inspected.

Check the page and its access

Open the priority URL and inspect the answer buyers need. Confirm readable product facts, working links, intended canonical URL, and a sensible next step. Ask the website owner for indexing evidence when account access is available. A browser receiving a page proves that fetch, not universal crawler access or indexing.

For Google, the official generative-search guidance connects AI-feature eligibility to Search requirements. Extra AI markup won’t repair a missing or inaccessible answer. Investigate the actual URL rather than commissioning a page for every prompt variation.

Search access and training policy are separate decisions. OpenAI’s crawler documentation identifies distinct controls for search and training. Have the responsible owner check robots rules and hosting behavior against the services the company intends to permit. Don’t change security or training preferences merely to complete this worksheet.

Turn a finding into a bounded repair

Write a repair that connects the observation to a change you control. For the teaching example, the issue is an unsupported CRM-sync claim. A reasonable repair is to make the CSV import, owner assignment, and native-connection limits explicit on the integration page, then check that the page and documentation agree.

Record the evidence, fact owner, change owner, required access, included work, excluded work, and completion test. Separate implementing the repair from an outside assistant adopting the new information.

Repair record	Teaching example
Observed issue	Completed answer describes unsupported automatic CRM sync
Included change	Clarify import method and owner assignment on the existing page
Dependency	Website editing access and a verified product-facts record
Completion check	Published text matches documentation, links work, and the page is reachable
Outcome observation	Repeat the same question under recorded conditions
Unresolved state	Access denied, documentation incomplete, or later answer unavailable

A repair can pass its completion checks while the repeated answer remains wrong. Keep investigating the cited sources and indexing state. Don’t claim success from the change alone or failure from one later response.

Compare without moving the test

Repeat the same panel after a recorded change and enough time to make the observation useful. External platforms control their updates, so no universal waiting period guarantees a different answer.

If you change the questions, label a new panel version and explain why. If you compare alternatives, use the same questions, surfaces, and settings where possible. Mark missing comparisons rather than making a ranking from incomplete observations.

Show counts with denominators and list failed attempts separately. Don’t combine mentions, citations, accuracy, and visits into a single authority score. The panel describes the sampled checks, not total market visibility, market share, or caused revenue.

Finish with a handoff someone can use

Your completed workbook should contain a fact sheet, answer evidence, one prioritized repair, and a record of what’s unknown. A colleague should be able to trace the issue, repeat the check, and understand what permission or decision blocks the repair.

Before calling the repair complete, verify the approved facts, changed URL, intended access, links, phone experience, and saved change date. Record failed checks as unresolved. Don’t call a proposed change implemented.

Use the downloadable instructions to run a collection and review pass. Start with the public method here if you don’t need the files. When you have the facts and access, you can continue with the monthly search cycle yourself.

If you want the assessment, intelligence brief, and agreed fixes handled, AI Audit is a one-time engagement. The handoff stands on its own. AI Search & SEO is available directly when ongoing work is useful; an audit purchase isn’t required.

Platform sources checked October 8, 2026.