Positioning ยท AI Readability
AI Readability vs AI Visibility: What You Can Actually Measure
This page exists to draw one line clearly. What an AI product says about you is an outcome you cannot query reliably. Whether your site is technically readable to a crawler is a precondition you can check today, item by item. Pingory sells a check for the second thing and nothing for the first; the rest of this page explains why.
Two different questions
"Will ChatGPT recommend me" is an outcome; "can a crawler read my site" is a precondition, and only the second is testable.
Vendors routinely blur them. One is a question about a model's behaviour in a session you do not control; the other is a question about bytes on the wire. Mixing them produces dashboards that look precise and mean nothing.
Visibility is an outcome you cannot query
AI visibility depends on model version, region, language, prompt and time, so no single number can represent it.
Ask the same question twice in the same hour and you can get different answers. Change one word in the prompt and the answer changes shape. A model answers in the language of the question, with a knowledge cutoff that differs per product, and with retrieval that depends on what its index fetched last week. Any tool that reports "your AI visibility is 73" is collapsing those variables into a number that will not reproduce.
Running a fixed prompt set many times and logging the outputs is a legitimate sampling exercise. It still measures the model's behaviour, not your site, and it cannot tell you why an answer changed, because the model, the index and the prompt are all moving.
What Pingory does not sell: rank tracking for AI answers, citation counts, share of voice, or a forecast of traffic from chat products. Those numbers are not stable enough to alert on, and an alert that fires on noise is worse than no alert.
Readability is a precondition you can check
Readability is whether the files and markup a crawler receives are present, valid and permissive.
That question has a stable answer. A fetcher receives a status code, a content type, a robots.txt, a sitemap, a block of HTML and a set of headers. Each can be inspected, and the result does not change between two runs a minute apart. It is the same category of check as uptime: deterministic, repeatable, worth alerting on when it changes.
The honest framing is that readability is necessary but not sufficient. A perfectly readable site can still be ignored. What a check can do is remove the boring failures โ a stray noindex, a canonical pointing at a staging host, an SPA shell with no text โ so that if you are absent from an answer, it is not because of a deploy mistake.
The 12 checks
Eight core checks carry 88 points and can fail the status; four enhancements carry 12 points and only move the score.
| Check | Group | Weight | What it verifies |
|---|---|---|---|
| robots.txt | Core | 8 | Reachable as text, parses as RFC 9309 groups, not an HTML fallback |
| AI crawler matrix | Core | 22 | Eight tokens evaluated on the homepage and a deeper path |
| llms.txt | Core | 6 | Exists, non-empty, at least one heading and one Markdown link |
| JSON-LD | Core | 12 | Every block parses, has a context and at least one type |
| First-screen text | Core | 12 | Text present in the HTML before JavaScript runs |
| sitemap.xml | Core | 6 | Valid urlset or sitemapindex with at least one entry |
| noindex | Core | 18 | Meta robots and X-Robots-Tag parsed token by token |
| canonical | Core | 4 | Canonical resolves to this page on the same host and scheme |
| Meta title and description | Enhancement | 5 | Both present and within sane length ranges |
| Open Graph | Enhancement | 3 | og:title, og:description and og:image present |
| H1 | Enhancement | 2 | Exactly one non-empty H1 |
| Image alt text | Enhancement | 2 | Non-decorative images carry an alt attribute |
Two checks deserve a note. The crawler matrix weighs 22 because access overrides everything else: if a token is disallowed, the rest of the page does not matter. noindex weighs 18 because it is the most common accident โ a staging header promoted to production removes a page from indexes while every other check still passes.
JS-rendered sites
If your first-screen HTML is an empty shell, a crawler that does not execute JavaScript sees no text at all.
The check fetches the page the way a plain HTTP client does and measures how much text is in the response before any script runs. A client-rendered app typically returns a few hundred bytes of <div id="root"></div> plus script tags, so the measured text is near zero even though a browser shows a complete page.
Whether that matters depends on the consumer. Search engines render JavaScript, with a queue and a budget. Many AI fetchers do not run scripts at all, so a page can be indexed by Google and still be invisible to a retrieval bot.
Three ways to test your own site, cheapest first:
curl -s https://example.com | grep -c "<p"โ count paragraphs in the raw response.- View source in the browser and search for a sentence you know is on the page. If it is absent, it is not in the HTML.
- Run the free check, which reports the measured character count and flags a JavaScript-only shell.
A static or server-rendered page fixes this by construction. For an app that must stay client-rendered, the usual remedy is to render the content that matters โ headings, body copy, prices, docs โ on the server and hydrate the interactive parts afterwards. Adding a <noscript> summary helps a human reader and does little for a parser.
What this does not measure
A readability score cannot tell you whether a model cited you, ranked you, or will ever mention you.
- Citations and rankings. No file on your server records what an answer engine said about you yesterday.
- Whether a real crawler can reach you. The check fetches from a single address. If your WAF blocks it but allows a vendor, the result is unknown, not a verdict on your site.
- Training inclusion. A permissive robots.txt does not guarantee a page was used, and a block does not remove copies already collected.
- Content quality. A page can score 100 and still be the least useful result for a question.
- Model behaviour over time. Vendor policies change without notice; the check reports what was served, not what will be honoured.
If you need the second item answered properly, the only reliable method is log analysis with source-IP verification โ see the AI crawlers list for why a user agent alone proves nothing.
Where this fits in monitoring
Readability is a snapshot when you run it once, and a regression signal only when it runs on a schedule.
The failures that hurt are the quiet ones: a deploy replaces robots.txt, a plugin starts answering /llms.txt with HTML, a firewall rule catches a retrieval crawler. None produce a 500, so uptime monitoring never sees them. That is why the check is also a monitor type.
| Plan | Price | Monitors | Interval | AI Readability monitoring |
|---|---|---|---|---|
| Free | $0 | 50 | 5 minutes | No; the free checker is a single check |
| Starter | $4 | 100 | 1 minute | No |
| Pro | $6 | Unlimited | 60 seconds hosted | Yes, alerts on change |
Starter covers the nine standard check types: HTTP, keyword, ping, TCP port, SSL, domain expiry, API assertions, DNS and heartbeat. The AI type is Pro only. Self-hosted deployments can run at 30-second intervals, and can run additional probe instances from other locations if you need them.
Check any site free
Run all 12 checks against any public domain in about ten seconds, with no account.