Back to Blog
AI Search15 min read6 September 2026

How to Run an AI Readiness Audit on Your Site

An AI readiness audit checks whether AI can reach, read, and understand your site. What it inspects, how to read the report, and how to run one yourself.

By AI Schema Gen Team

Most people picture an AI readiness audit as a score. You paste a URL, a number between 0 and 100 comes back, and that number is the point.

It isn't. The number is the headline, and it's the least useful thing the audit produces. The useful output is the list underneath it: specific findings, each tied to a real page and a real reason. "Your homepage declares your organization twice, with two different identifiers." "The address on your contact page is inside an image." "This canonical tag points at a staging URL." Those are the things you act on. The score is just their sum.

There's a second thing worth being clear about before you run one. "Audit your site for AI search" gets used to mean two opposite activities. One points a crawler at your own website and checks what it can and can't work out. The other asks ChatGPT what it already says about your business and tracks whether that changes. The first is deterministic, entirely inside your control, and fixable this week. The second is a monitoring exercise for something no tool controls. This post is about the first one: what a readiness audit inspects, what the report means, and how to run a credible version of it yourself.

An AI readiness audit checks your site, not your reputation

An AI readiness audit measures the state of your own website, independent of what any AI system decides to do with it. That's the whole distinction between readiness and visibility: readiness is a property of your site that you can check line by line, visibility is a decision made inside a system you can't see. Google's own guidance is blunt about the second half: its AI features use the same index and ranking systems as regular Search, and need no special markup. So any audit promising to measure your "citation odds" is measuring something nobody can measure. A readiness audit stays on the side of the line where every finding is either true or false about your pages.

It's also not the same as a traditional SEO site audit, though they overlap. A standard crawler (the kind built into Ahrefs, Semrush, or Screaming Frog) checks status codes, redirect chains, duplicate titles, broken links, and page speed. All useful, none of it AI-specific. A readiness audit adds three checks those tools don't run:

  • Does your entity graph actually connect? Not "is there schema on the page," but "do the references between your schema blocks point at things that exist." A pile of valid but disconnected JSON-LD passes a normal validator and fails this.
  • Do a crawler and a browser see the same page? Many AI crawlers read the HTML your server sends without running your JavaScript. If your content only appears after the page loads, they see an empty shell. A browser hides this from you completely.
  • Can a machine describe your business from your site alone? This is a comprehension test, and no SEO tool does it. It gets its own section below.

Those three are the reason a readiness audit exists as a separate thing rather than a tab in an SEO tool.

What the audit actually inspects

The audit works through four checks, in the order a machine encounters your site. Each one is a pillar of the score, and each has a deep-dive guide if you want the full reasoning. Here the point is what evidence each check produces.

Can a crawler reach the page at all? (Discover, worth 15 points.) The audit looks for a sitemap and how it's declared, reads your robots.txt for rules that block retrieval crawlers, checks the HTTP status codes your pages return, and, most importantly, fetches each page without running JavaScript to see how much of your real content is actually in the raw HTML. The evidence it hands back is a raw-versus-rendered comparison: here's what a browser sees, here's what a plain crawler sees, here's the gap. On a modern JavaScript-heavy site that gap is often the single biggest finding. The Discover pillar guide covers each check and how to run it by hand.

Can it parse the page once it arrives? (Read, worth 15 points.) Once a crawler has the HTML, can it make sense of the structure? The audit checks for one H1 per page, a heading order that nests sensibly, a canonical tag that points at the page itself rather than a staging URL or a different page, a stray noindex left over from a build, image alt text, and freshness dates. The evidence is a per-page list of structural faults, with counts, so you can see whether a problem is on three pages or three hundred. The Read pillar guide has the details.

Can it tell who runs the business? (Understand, worth 45 points, more than the other three combined.) This is the heaviest check by a wide margin, and it's the one generic tools skip. The audit pulls every JSON-LD block across the site and tries to resolve the references between them. It flags a reference pointing at nothing, the same company declared twice with two different identifiers, an entity that nothing else links to, and a relationship that should exist for your kind of business but doesn't: a Product with no linked Brand, an Article naming a publisher that's never actually defined, an Organization with no founder. It also checks that your trust pages (about, contact, privacy, terms) exist and are reachable, because those are the plain-HTML version of "who are you." The evidence is a graph report in plain language: "Service exists but names no provider." "Three references point at nodes nothing declares." Understand is weighted so heavily because crawlability and clean HTML are a few days of work for a developer, and a genuinely connected entity graph is not. The Understand pillar guide goes through the four ways a graph breaks.

Can it answer real questions about you? (Answer, worth 25 points.) This is the comprehension test, and it needs its own section.

The closed-book test

The Answer check asks an AI model six fixed questions about your business:

  • What does this company do?
  • Where is it located?
  • What areas or industries does it serve?
  • What specific services or products does it offer?
  • Who runs it?
  • How can someone contact it?

The constraint that makes this useful: the model can only use what the crawler found on your site. No training data, no web search, no Google Business Profile, no directory listings. Just your pages.

That's the opposite of the test most people run, which is opening ChatGPT and asking about their business by name. That version lets the model answer from anywhere, so a correct answer tells you the internet remembers your business, not that your site says anything useful. A closed-book test tells you what your site says on its own, which is the only part you can fix. The Answer pillar guide explains why that distinction matters so much.

Each answer then gets one more check: did the fact trace back to something your site actually declared in structured data, or did the model reconstruct it from prose and happen to be right? A correct guess and a grounded fact behave completely differently the next time your copy changes. The finding this produces is the most quotable thing the audit generates, a sentence with two halves:

Asked what your company does, an AI answered: "a WordPress plugin developer." Your site says: an AI visibility platform.

Nothing is broken there. No validator failed. A machine read the site carefully and got the business wrong, and the only way to catch that is to ask.

Reading the report you get back

Once the audit finishes, resist the urge to read the score and stop.

The score hides more than it shows. Two sites can both score 80 and need completely different work. Take a composite example, built from patterns that recur rather than one real site. Site A lost almost all of its twenty missing points in the Discover and Read pillars: a stale sitemap, some missing canonical tags, a few pages that skip heading levels. That's a config afternoon. Site B lost the same twenty points almost entirely in Understand: its organization is declared twice, its team page connects to nothing, half its references dangle. Same score, but Site B is weeks of entity work away from where Site A already is. The pillar breakdown tells you which situation you're in. The single number doesn't.

The findings are the actual product. A useful audit gives you each finding tied to a pillar, a list or count of affected pages, and a rough estimate of how many points you'd recover by fixing it. That turns a wall of problems into a ranked plan. Sort by recoverable points, respect the pillar order (a Discover fix has to come before the Read work on the same page matters), and the plan usually gets short fast.

Some findings are machine-fixable and some are yours. Missing markup on pages that have none, entities that never connect, the same thing declared twice, dates that drifted stale: those are mechanical, and a tool can do them across a whole site in one pass. Which facts are actually true, which social profiles you genuinely control, what your business is really authoritative on, whether a founding date is a real record or a rough guess: a tool can structure those impeccably and still can't tell you whether they're accurate. Declaring something you can't back up is worse than leaving the gap.

The rule that surprises people: a reference pointing at nothing scores worse than the property simply being absent. A half-true claim is harder for a machine to recover from than an honest hole. So a few of your findings will read as "you added this, now remove it," and removing a dangling reference is a real fix, not a shortcut.

Free scan versus full audit

There are two depths, and the difference is scale, not features.

The anonymous check runs with no signup: all four pillars, up to 100 pages, in under a minute. The one thing it holds back is the Answer pillar, which runs a two-question preview rather than the full six, and isn't scored. Everything else you get.

A signed-in audit runs all six Answer questions and scores that pillar. On a paid plan the crawl extends to 1,000 pages, and you also get a per-page work queue: a plain list of which specific pages a machine couldn't parse. That list is deliberately not scored. Scoring it would tempt you to optimize the number instead of fixing the pages, and a bare list of URLs that failed is more useful and harder to game.

The reason for the split is cost, not a paywall on the good part. A full crawl with a rendering pass on every page and six model calls per site is real money to run. The depth is metered. The method is the same at both tiers.

Running a first-pass audit yourself

You can get most of the way by hand in an afternoon, and it's worth doing once even if you end up using a tool, because it teaches you what the findings mean.

  • View Page Source, not the inspector. Right-click, "View Page Source." That's the raw HTML your server sent, before any JavaScript ran. If your headings, body text, and schema aren't in there, a crawler that doesn't run JavaScript isn't seeing them.
  • Fetch the page as a crawler. Use a command-line tool or a browser extension that requests the page with a crawler's user-agent and doesn't execute scripts. Compare what comes back against your normal page. A big difference means a security tool or CDN rule is serving crawlers something different, usually by accident.
  • Run the markup through the validators. Google's Rich Results Test and the Schema.org Validator will both parse your JSON-LD and show you what's malformed. Neither one checks whether your references connect, but they catch the basic errors first.
  • Do the closed-book test manually. Copy your page source, paste it into an AI assistant, and instruct it to answer the six questions using only that text and to say "not stated" when the page doesn't say. The "not stated" answers are your list.

The four pillar guides above each walk their checks step by step. Where doing it by hand stops working is the entity graph: resolving every @id reference across a whole site, and checking every page's comprehension rather than just the homepage, are the parts that need automation once you're past a handful of pages.

How often to run one

A readiness audit is not a one-time job, because readiness drifts. A redesign rebuilds templates and the canonical tags don't always come with them. A CMS migration moves the content and leaves the structured data behind. A plugin update changes what the site emits. A new section launches without schema because whoever built it followed the old convention. None of those announce themselves.

Re-audit after any redesign, migration, replatform, plugin change, or large content launch, and run a baseline check a few times a year even without a trigger. Turning that into an ongoing habit rather than a periodic scramble is the subject of the AI readiness loop, which puts the audit in its place as one stage of five.

Common Mistakes

Reading the score and stopping. The number is a sum. Two sites with the same score can be an afternoon and a month of work apart. The pillar breakdown and the findings list are where the real information is.

Auditing in a browser. Almost every readiness failure is invisible from a normal browsing session, because a browser runs JavaScript, follows redirects, and fills in gaps a crawler doesn't. If your check didn't fetch your pages the way a crawler does, it didn't audit the thing that matters.

Treating the findings as a flat to-do list. They're not equal. One Understand finding can be worth more than five Discover ones, and a downstream fix is pointless while the upstream problem is still there. Sort by recoverable points, work in pillar order.

Only auditing the homepage. Your homepage is the most carefully written page on your site and the least representative. The pages customers actually land on from a search are usually thinner, and that's what a crawler is judging you on.

Confusing a readiness audit with a citation check. Whether ChatGPT currently mentions you is a different question, decided outside your site, and worth watching separately. A readiness audit tells you whether your site is giving those systems accurate material to work from. It doesn't tell you what they'll do with it.

Auditing once. A clean audit in January says nothing about April, after the redesign. The events that break readiness are routine, so the checking has to be routine too.

Frequently Asked Questions


AI Schema Gen runs this audit as a free tool: paste a URL and see all four pillars scored, with the specific findings behind the number tied to real pages. Check your site at aischemagen.com.

Is your website ready for AI?

Check now. Free readiness score in under a minute, no signup, no card.