Teardown: Which AI Visibility Audit Checks Actually Help Bots Cite You?

A marketing lead forwarded me a 43-page “AI visibility technical audit” with 40-odd red, amber and green line items and a $2,500 invoice behind it. I chose it for this teardown because it is the artefact many teams now have on their desks: a familiar SEO crawl report with AI pasted into the headers. I have built versions of this report myself. I know how they get assembled.

My claim is flat: five checks do the heavy lifting when an answer bot needs to fetch and quote your page. Bot access in robots.txt and at the CDN or WAF; server-rendered answer text; fetch speed and reliability; canonical clarity; and a crawlable internal path to the answer page. The rest either helps at the margin or pads the score. I will follow the report in the order a reader encounters it, give each section a verdict, and explain the mechanism before the fix.

The contents page: 40 checks presented as equals

Open the PDF and you get the usual run of headings: robots.txt AI user-agents, llms.txt presence, Organization and Article schema, FAQ schema validity, Core Web Vitals, sitemap freshness, meta titles and descriptions. One practitioner checklist in circulation presents the same 30 to 40 items as pass/fail checks, each with a coloured dot beside it.

Those dots are the first thing I distrust. A severity colour tells you how far a page deviates from a specification. It does not tell you how close that page is to being cited. A missing meta description and a blocked OAI-SearchBot can both appear as amber warnings, as if fixing either would have the same effect. It will not.

I used to tell clients a Quality Score drop was about ad relevance because the interface flagged it red. I was wrong as often as I was right: the flag described a symptom, not necessarily its cause. This audit makes that mistake across an entire site. Read the dots, then put them aside and test the route a bot actually takes.

Section 1: Bot access belongs on page one, not page 30

The report buries “robots.txt: check AI user-agents” near the back. It should lead. Two layers of bot access do different jobs: training bots such as GPTBot, ClaudeBot and Google-Extended feed future models, while live-search bots such as OAI-SearchBot and Claude-SearchBot, along with user-fetchers such as ChatGPT-User and Claude-User, can fetch pages for an answer being assembled now. A block on a live-search bot closes that fetch route. A block on a training bot affects a different, longer-term use. Verdict: decides citation. They should not receive one shared pass/fail mark.

Then comes the gate the PDF does not test. Your robots.txt can say Allow: / while Cloudflare’s “Block AI bots” toggle, Bot Fight Mode or a Vercel firewall rule drops the request at the edge. If robots allows access but the logs show 403s or 429s for those user-agents, the edge is the gate to investigate.

Our edge logs show why robots belongs at the front of the report: over 30 days, Claude-User fetched robots.txt 1,216 times while assembling live answers. I wrote up what those logs showed because a count of claimed AI hits and evidence of answer-time fetches are not the same thing. Check the file, then check whether the request made it past the edge.

Section 2: Rendering decides whether there is an answer to quote

The audit lists “JavaScript rendering” as one amber crawlability line, beside broken images. That understates the problem. Across the Vercel network, none of the major AI crawlers examined from OpenAI, Anthropic, Meta, ByteDance or Perplexity rendered JavaScript. Some downloaded JS files without executing them. If your pricing table or how-it-works answer appears only after React or Vue builds the page in the browser, a crawler reading initial HTML gets the shell, not the answer. Verdict: decides citation. A bot cannot quote text it never receives.

Test the page with curl or View Source, not Inspect Element. Inspect Element shows the browser’s finished page, including what JavaScript added; the raw response is the check that matters here. If the sentence you want quoted is absent from that HTML, server-render the answer block first, even if the rest of the page stays client-rendered. That change has moved more accounts I have worked on from zero citations to some than the schema tweaks I have shipped. Start with the text a bot must see.

Section 3: Schema helps, but it cannot rescue an unreadable page

The next cluster usually gives schema several red lines: missing Organization, missing Article, invalid FAQ, missing breadcrumb, unvalidated JSON-LD. Read together, they imply that valid markup feeds an answer model directly. The mechanism is less impressive. LLMs can read schema as text without treating its validity as a ticket to cite the page. In a February 2026 test, a practitioner put a fake address only in invalid, made-up JSON-LD, and both ChatGPT and Perplexity returned it in answers. Ahrefs tracked 1,885 pages that added schema against controls from August 2025 to March 2026 and found no major citation lift in AI Overviews, AI Mode or ChatGPT. Verdict: helps at the margin.

Keep clean Organization and Article schema. It costs little and keeps your entity consistent for regular search. What the deck calls “structured data synergy,” I call spelling your name the same way everywhere. But do not buy a schema remediation sprint expecting citations to follow. If the bot is blocked at the edge or the answer exists only in client-rendered text, valid schema does not fix either problem. Prove access and rendering first.

Section 4: The fetch matters more than the Lighthouse colour

Here the audit has four more red lines: LCP 3.8s, INP 280ms, CLS 0.21 and a performance score of 62. The implied story is that a page-experience grade passes straight to the answer engine. A live fetch has a more immediate problem: the request times out, returns a 500 or takes too long to deliver the HTML. Google uses page-experience signals for ranking and recommends good page experience for AI Overviews and AI Mode, but reports no isolated LCP/INP/CLS-to-citation effect.

I learned to distrust scores without outcomes back when a 61/100 account score could sit beside a perfectly sensible CPA. Taking a Lighthouse score from 62 to 94 feels productive, but it misses the immediate failure if time-to-first-byte still spikes to 2.5 seconds under load. Fix slow server responses, 5xx errors and oversized HTML on answer pages. Verdict: fetch reliability decides citation; the colour-coded Vitals score is padding for this decision. Watch the response on your ten money pages before polishing a site-wide lab score.

Section 5: An “AI readiness” score is not a fetch test

The audit flags a missing llms.txt as critical, adds warnings for absent “AI meta tags” and announces an AI readiness score of 42 out of 100. But llms.txt is a proposal, not a protocol bots have to follow. Answer-time bots can fetch the page and robots.txt without consulting it. SE Ranking crawled around 300,000 domains, found llms.txt on 10.13% of them and found no link between the file and citations. Removing the file from its model improved accuracy. Verdict: padding, for now.

The meta tags have the same problem in smaller print. A tag asking to be cited does not open a blocked route, place the answer in raw HTML or improve the answer itself. The readiness score then averages roughly 40 unlike items, so a site blocked at the edge can still look healthy after fixing titles and schema. Skip this section until access, rendering and the answer-page checks below pass. Paying for llms.txt before proving bots can read the pages is paint before plumbing.

Section 6: Canonicals and links give the bot a clear page to fetch

Near the back, below the speed charts, sit canonicals and internal linking. I would move them to page two. A live answer fetches a URL to read and quote. If your pricing page has trailing-slash, parameter and AMP variants, and the canonical points elsewhere or nowhere, that fetch can land on a duplicate instead of the page you intended. If your best answer page has no crawlable internal link, discovery depends on the sitemap alone. Verdict: canonical clarity and a crawlable internal path decide whether the intended answer page is available.

Keep one canonical URL per answer. Link to it from a hub page a crawler already visits, and use a plain <a href>, not a JavaScript router push. This is not glamorous “AI optimisation.” It is giving a fetcher one address and a route to reach it.

The missing line item: were those bot visits real?

After the scored sections, I look for a question the report never asks: did the counted bot hits come from the bots named in the logs? User-agents are easy to spoof, and scrapers impersonate GPTBot to get past allowlists. OpenAI and Perplexity publish IP ranges that can be used to verify requests; source-IP or reverse-DNS checks matter before you trust the counts.

I have seen audits call “2,400 AI crawler visits” proof of visibility when verification showed mostly spoofed training scrapes and zero live user-fetches. Training hits made up roughly 80% of the volume in our data. ChatGPT-User and Claude-User rows are the more useful citation-candidate signal, not proof that a citation appeared. A 403 on one of those verified requests tells you something actionable: the page was requested and refused. Filter to verified user-fetchers before declaring the audit a success.

The fix-order checklist to use beside the PDF

Keep this beside the report and work in fetch order. The notes are short because each item needs a check, not another coloured score.

First 48 hours

1. Allow live-search bots in robots.txt: Check OAI-SearchBot, Claude-SearchBot and PerplexityBot access to answer pages.
2. Check the edge, not just the file: Review Cloudflare bot settings and WAF rules; confirm successful responses in logs.
3. Verify user-fetcher requests: Check ChatGPT-User, Claude-User and Perplexity-User identities before treating counts as evidence; investigate 403s and 429s.
4. Server-render the answer text: Fetch the URL and find the quotable sentence in raw HTML.
5. Fix fetch reliability on ten money pages: Check TTFB, 5xx errors and HTML payload size; do not substitute a lab score.

First 30 days

1. Set one consistent, self-referencing canonical URL per answer.
2. Add a plain <a href> link from a crawled hub to each answer page.
3. Deduplicate parameter, AMP and trailing-slash variants.
4. Clean up Organization and Article schema so names are consistent.

Leave until those checks pass: llms.txt, AI meta tags, the AI readiness score, meta-description rewrites and full Lighthouse remediation.

Then revisit the edge check, the item most often skipped. A permissive robots.txt does not help when a firewall refuses the fetch; the cost is an answer request you never served.

Overall verdict: keep the fetch tests, recycle the score

Keep five checks from the artefact: robots.txt and edge access, raw-HTML answer text, TTFB and 5xx behaviour on money pages, canonical clarity, and the internal-link path. Recycle the other 38 pages until those pass. This is a competent SEO crawl with AI labels glued on, but it measures deviation from specifications where I needed a fetch test. For the longer version of that door test, read whether answer bots can get in and read the page. Then look at which tool capabilities help a business get featured in Google AI Overviews rather than merely monitor visibility. A tool that scores 40 items weekly but never fixes fetch order is a dashboard, not execution.

That is why I stopped handing clients PDFs and started handing them logs. At groas, the triage runs continuously: verify the user-fetcher hit, prove the answer text is in the HTML, confirm the fetch finished fast, and log what changed and why. The edge check is still the one I would keep taped above the desk. It can turn away the answer bot while the audit up front tells you your titles look great.