ClearSiteScore“Analyse my website and tell me what to fix.” It is a reasonable request, and the answer arrives in seconds.
It is fluent, structured and confident. It has headings, priorities and a tone of authority. What it does not have is a single measurement taken from your live website.
This is not an argument against AI. It is an argument about instruments. A language model is extraordinarily good at describing and explaining. A technical audit is a series of observations — and observations require something that observes.
A chatbot can review wording. It cannot measure delivery, speed, access or scale.
Text quality is genuinely reviewable from a page's content. Everything else that determines whether your site is found, understood and fast depends on how your server responds, what a real browser renders, how your site behaves for automated visitors and what dozens of pages look like together. None of those are readable from a paste.
Why the shortcut looks so convincing
The output of an AI “audit” resembles a real report closely enough to be trusted. It uses the right vocabulary, it groups findings by severity, and it never says “I could not determine this.” That last part is the problem.
A measurement-based report is full of qualifications: a value, the page it came from, the conditions under which it was observed, and an explicit note when something could not be measured. A generated report has no such gaps, because generating plausible text is easier than admitting uncertainty.
“The report that never says ‘unknown’ is the one that measured nothing.”
Reading a page and measuring a site are different activities
It helps to split the work into two categories. One is about language and structure and can be reviewed from content. The other is about behaviour and can only be established by acting on the live site and recording what happens.
| Question | What answering it actually requires |
|---|---|
| Is this description clear and specific? | Readable from the content — editorial judgement |
| Does the page answer the customer's question? | Largely readable from the content in context |
| Does the server allow this crawler through? | A live request made as that crawler |
| How long does the main content take to appear? | A timed render on defined hardware and network |
| Is the protective configuration in place? | Inspecting the server's own response metadata |
| Do catalogue pages carry consistent machine-readable data? | Sampling many pages and comparing them |
The first two rows are readable, and AI is a capable assistant there. The rest are where a chat answer stops being evidence and starts being an assumption.
What a chat answer cannot see
When a browser requests a page, the server sends more than the visible document. It also sends response metadata that governs encryption behaviour, what the page is allowed to load, how long intermediaries may cache it, and which browser capabilities the page may use.
That metadata is invisible in the page source and invisible in a screenshot. It is not something a model can infer from wording — it either exists in the response or it does not, and only a request can tell you which. Misconfiguration here is one of the most common findings on real websites, and one of the least visible to a reader.
A site can look perfectly healthy in a browser while its responses tell a different story. Nothing on the screen changes; the difference shows up in security posture, caching behaviour and how automated systems treat the site.
The Core Web Vitals illusion
Ask a chatbot how fast your page is and you will often get a number. This is the clearest example of a confident answer with nothing behind it: producing a loading time requires actually loading the page and watching it paint.
Google's own performance metrics are defined as observations of a real page load — largest content paint, layout movement, interaction responsiveness — and Google publishes both laboratory measurements made under controlled throttling and field data collected from real Chrome users. Google’s Core Web Vitals definitions
Two things follow. First, a number that was not produced by a timed load is an invention, however precise it looks. Second, laboratory and field results answer different questions, so a serious report states which one it used. Chrome UX Report documentation
Why our own research made this obvious
In our study of 200 Hungarian webshops, the median mobile largest-content paint was far outside the recommended threshold — a result no amount of reading could have predicted, because the pages looked fine. See the measured results
Crawler access is a live test, not a document review
Whether an AI search system can use your content depends on three separate things: whether your rules permit it, whether your infrastructure actually lets the request through, and whether the response contains the content at all.
A chatbot can comment on the first. It cannot perform the second. Requests arriving with an automated user agent are routinely met with a challenge page, a rate limit or an outright block by a CDN or firewall — configuration the site owner often never chose deliberately. Google documents its crawlers and expected behaviour; other providers document theirs. Verifying which of them your server actually serves means sending requests and recording the answers. Google crawler documentation
Our full walkthrough of that test is in the AI bot access guide.
One pasted URL versus a whole catalogue
A shop's real problem is rarely on one page. It is a pattern: a template that omits a field, a category where availability data is missing, a section where the main text arrives only after scripts run.
Patterns need scale. You establish them by discovering the site's own page inventory, selecting a representative set of real pages, requesting each one, and comparing the results as a distribution rather than an anecdote. A chat window sees whatever single page you thought to paste — which is, almost by definition, not the page with the problem.
- one page can be an exception; a share across many pages is a finding;
- a missing field on your best product says nothing about the other nine hundred;
- severity depends on how much of the catalogue is affected, not on whether the issue exists somewhere;
- content that appears only after scripts run has to be compared against the original response, page by page.
This is also why “my AI checked my site” and “my site was measured” are different statements even when the conclusions happen to overlap.
Probable text versus reproducible evidence
Language models generate the most plausible next words. That is what makes them fluent, and it is also why they invent. Asked for problems, they supply problems, because a list of problems is the expected shape of the answer. With no measured value to contradict it, the guess stands.
Two consequences show up constantly in practice. Correctly configured pages get “fixed” — developer time spent on something that was already right. And genuine issues stay invisible, because they only exist in data the model never had.
| Generated finding | Measured finding |
|---|---|
| States an issue confidently | States a value and where it came from |
| Cannot be reproduced | Can be re-run and compared |
| Changes wording when you ask again | Returns the same result under the same conditions |
| Rarely admits uncertainty | Marks unmeasurable items explicitly |
| Suggests fixes for passing checks | Only raises what failed a measurement |
That last row is the one we treat as non-negotiable in our own reports: nothing is written down without a measurement behind it, and anything that could not be measured reliably is labelled as such — not as a failure, and not as a pass.
Where AI genuinely helps
The honest position is not “AI is useless here.” It is “AI is the wrong tool for the observation step and the right tool for almost everything afterwards.”
| Task | Good use of AI? |
|---|---|
| Rewriting a weak product description | Yes — this is exactly its strength |
| Explaining a technical finding in plain language | Yes |
| Turning measured results into a developer brief | Yes |
| Drafting answers to common customer questions | Yes |
| Deciding whether your pages are slow | No — this needs a timed measurement |
| Confirming crawlers can reach your site | No — this needs live requests |
| Judging catalogue-wide data quality | No — this needs sampling at scale |
Used in that order — measure first, then let AI help you act — the two are complementary. Used in the other order, you are optimising a description of your website rather than your website.
How to check an audit you were given
Whatever produced your report, these questions separate observation from narration. They work on an AI answer, an agency deck and on us.
- does each finding name the specific page it came from?
- is there a value, response or snippet attached, not just a claim?
- does it say when the measurement was taken?
- for speed claims: does it state the device and conditions?
- for crawler claims: was an actual request made, or only a rule read?
- for catalogue claims: how many pages were checked, out of how many?
- does anything in the report say “could not be measured”?
- can the same check be re-run after you fix it?
If most answers are no, you are holding an opinion. That can still be a useful starting point — but do not schedule development work against it before something confirms the problem exists.
CHECK YOUR OWN SITE
Start with a free, measured scan
ClearSiteScore runs live requests and instrumented measurements against your public website and shows the evidence behind every finding. No access is needed and nothing on your site is modified. A scan establishes what is measurable; it cannot promise rankings or citations.
Run a free website scanFrequently asked questions
They can read text you give them and comment on it. They cannot measure loading performance on a throttled device, test how your server answers individual crawlers, or sample dozens of product pages. The output reads like an audit without the measurements an audit depends on.
Technical references
Go deeper
AI Search Optimization Tools in 2026: What They Check (And How to Audit Your Site for Free)
AI VisibilityHow to Check Which AI Bots Can Access Your Website
AI CommerceWhy Your AI Shopping Assistant Recommends the Wrong Products
Technical references checked on 28 September 2026. This article explains the difference between reading a website and measuring one; it does not describe the internal capabilities of any specific AI provider.