This is a manual AEO audit that takes twenty minutes, no tools and no login: one terminal, the curl command, and two browser tabs. What it delivers is a shortlist of what is blocking your site from appearing in AI answers — not a score. There is no honest one-number score to give you in twenty minutes, and anyone who gives you one is guessing. What you can get, reliably, is a list in three buckets: things that are actively blocking reach, things that are missing as machine-readable signals, and things that are missing as third-party corroboration. Each step below says what to run, what the result tells you, and — just as importantly — what it cannot tell you.

Step 1 — robots.txt: which AI crawlers have permission (3 minutes)

curl -s https://yoursite.com/robots.txt

Scan for the AI crawler names — GPTBot, OAI-SearchBot, ClaudeBot, Claude-SearchBot, PerplexityBot, Google-Extended — and for any User-agent: * / Disallow: / wildcard rule.

What it tells you: whether you have explicitly allowed or blocked the crawlers that ground AI answers (the grounding crawlers are the ones that matter for citation visibility — the role split is in how AI engines crawl your site), and whether a wildcard rule is silently blocking every agent you never named. A wildcard disallow with no crawler-specific rules is the single most common “we never opted out of AI, but nothing shows up” finding.

What it cannot tell you: whether the block is actually in effect end-to-end — a WAF above the file can block a bot the file allows, and neither leaves a report. It also cannot tell you whether the crawlers are reaching you at all; for that you need your server logs, grepped for the user-agent strings in the LLM crawlers reference.

Step 2 — fetch your top 3 pages as a plain HTTP client (3 minutes)

Pick your homepage, your product page, and your pricing (or main comparison) page, then:

for p in "" product/ pricing/; do
  curl -sL -A "Mozilla/5.0 (compatible; aeo-audit)" "https://yoursite.com/$p" | wc -c
done

What it tells you: what an agent gets back with a plain fetch. A few hundred bytes where you expect a full page means a JavaScript shell — the content only exists after a browser runs JS, and none of the vendor crawler documentation we verify describes JS rendering for grounding crawlers. Small numbers can also mean auth walls, 403s for non-browser user agents, or geo blocks. Any of those is a hard reach failure, in bucket one.

What it cannot tell you: whether the fetcher would follow your redirect chains, retry, or tolerate your headers — byte size is a signal, not a simulation. And it cannot tell you whether what you return is good content for answers; reach is not extractability.

Step 3 — llms.txt presence (1 minute)

curl -s -o /dev/null -w "%{http_code}\n" https://yoursite.com/llms.txt

What it tells you: whether you have the proposed machine-readable index for LLM agents at all. A 200 is a start — the spec’s format (H1, file lists, links to markdown alternates) is the actual requirement, and our what is llms.txt post explains what the file does and doesn’t do. A 404 is not a fault; the file is a courtesy index, not a ranking lever.

What it cannot tell you: whether the file is valid or useful. That needs the full v2 spec audit — twenty minutes in its own right, and the spec’s own test is to give an agent only your llms.txt as a starting point and see if it finds what it needs.

Step 4 — JSON-LD on those same pages (3 minutes)

curl -sL "https://yoursite.com/" | grep -c 'application/ld+json'

Run it for each of the three pages; then eyeball one block for Organization or Product types with consistent name, description and URL fields.

What it tells you: whether the machine-readable metadata layer exists on the pages answers are most likely to draw from, and at a glance whether the entity facts (name, category, pricing) agree with each other. Absence or conflicting facts across your own pages goes in bucket two.

What it cannot tell you: whether the JSON-LD is valid (that needs a validator, and a browser tab does it), or whether your on-site facts match what the rest of the web says about you. Entity resolution is decided across the web, not on one page — that is step 6.

Step 5 — ask one money question in two AI surfaces (4 minutes)

Write down the single question your buyers ask — “[your product] vs [top competitor]”, “best [category] for [use case]”, “[your product] pricing”. Ask it in two surfaces (ChatGPT and Perplexity are the natural pair for B2B SaaS), in their default modes, and record every cited URL verbatim.

What it tells you: your current state on that one question — cited, mentioned without a link, or absent — and your real competitor set on it, which is the set of domains the answer actually cited. That list is worth keeping: it is the population your corroboration work has to enter.

What it cannot tell you: anything beyond one question, one mode, one day. Instant and Thinking modes retrieve differently (the 2026 ChatGPT citations study, arXiv:2610.15382, found Thinking frequently runs multiple retrieval rounds), only about 18% of ChatGPT conversations trigger a web search at all (Profound’s ~700,000-conversation study), and the selection logic is unpublished. One probe is one data point, not a system — that is why this step produces a snapshot, not a score.

Step 6 — find the third-party pages that describe you (3 minutes)

In a classic search engine, run: [your product] review, [your product] vs [competitor], [your product] alternatives. Skim the top handful of independent results — review platforms, comparison pages, community threads — and check each against your actual positioning: right category? right current pricing? a product that still exists?

What it tells you: which independent pages exist that an AI answer could triangulate from, and whether they describe you accurately. A review that pins you to the wrong category, or a comparison page quoting your pricing from two years ago, is a claim waiting to bind to your entity with the wrong facts — bucket three, and the most common one.

What it cannot tell you: whether any of those pages will actually get cited. Existence is not citation, and the citation population on your money question is the one you recorded in step 5 — compare the two lists and the gap between them is your corroboration backlog.

Step 7 — dates and freshness on everything you just found (2 minutes)

Look at the published or “last updated” date on each third-party page from step 6, and on your own comparison and pricing pages.

What it tells you: the currency of the sources your claims would draw on. AI answers skew toward current sources for anything price- or feature-shaped, and a page last touched in 2024 is competing against a page updated this quarter with exactly the same claims.

What it cannot tell you: how much any specific engine actually weighs dates — no vendor documents an explicit freshness score for AI answers, so freshness is a strong proxy, not a documented input. Record the dates; do not over-read them.

After 20 minutes

You now have a shortlist in three buckets — blocking, missing signals, missing corroboration — and a real competitor set from one live question. That is the deliverable. What it is not: a score, a diagnosis of your selection-stage position, or a fix list.

For the fix list: the 12-check B2B SaaS checklist for getting cited in ChatGPT is the standing, structured version of everything that typically goes in buckets two and three — structured data, comparison pages, a real pricing page, third-party corroboration — and it is where this audit points next. For the series context behind each bucket, the AEO/GEO basics hub page has the twelve parts in reading order.