AI Readiness Test
Enter a URL and see how much of that page an assistant can actually read, scored on the same checks our Site Audit runs. No account, no payment.
Nothing tested yet
Enter a page above. We fetch it once, then read the site's robots.txt, llms.txt and well-known files, and judge the page on all 14 of the checks an assistant reads it by.
What this reads, and what it cannot
In this order, from our own crawler
The page itself first, once, as HTML: its title, headings, opening paragraph, schema and links. Then the site around it, because half of what decides whether an assistant can use your page lives at the root rather than on it: robots.txt, llms.txt, /.well-known/mcp.json and an API catalog. Last, the two ways a page can offer a Markdown version of itself: a .md twin, and the same URL asked for with Accept: text/markdown.
It does not run a browser, so a page that draws its content with JavaScript is judged on what arrived in the HTML, which is also what most assistants get. It does not crawl, so nothing here knows what links to this page or whether its links resolve. Checks that had nothing to judge are listed as not measured rather than quietly counted as passed.
We fetch as NickLaunchesAudit/1.0, we honour any Crawl-delay your robots.txt asks for, and we never fetch a private or local address. It is the same engine behind Site Audit, which is why this tool is free: it costs us no vendor call.
Two of these checks are easy to misread. A robots.txt rule that blocks one AI crawler can leave another untouched, because training, search and user-requested fetches run under different bots; AEO Footnotes lists which line controls which crawler. And llms.txt is widely published, but no study so far shows it moves AI search visibility; their read of the spec and the evidence is worth a look before you treat a missing file as a failure.