How do I check an AI agent's claims about a website?
Verifying an assistant's findings yourself, in a browser or one terminal command, without taking anything on trust.
Every honest claim about a website configuration corresponds to something you can observe directly — a response header, a DNS record, a certificate field, a line in robots.txt. Ask the agent which observation supports its claim, then check that observation yourself. Most checks take one command or one devtools panel.
Start by asking for the artefact
Before verifying anything, make the claim checkable. "Which header told you that?" converts an opinion into a testable statement, and an agent that cannot name one has told you what you needed to know without any further work.
From there, each class of claim has an obvious check.
Headers: one command, or the network panel
curl -sI https://yoursite.comThat prints every response header. Search it for the one in question. In a browser: open devtools, the Network tab, reload, click the first document request, and read Response Headers. Both take under a minute and settle any claim about CSP, HSTS, framing, caching or cookie flags.
-sIL rather than -sI if your site redirects. Otherwise you are reading the headers of the redirect, not of the page — a mistake that makes correctly configured sites look unconfigured.TLS: the certificate is readable from the browser
Click the padlock, then the certificate details. You get the issuer, the validity dates and the subject alternative names. From a terminal:
echo | openssl s_client -connect yoursite.com:443 -servername yoursite.com 2>/dev/null \
| openssl x509 -noout -issuer -subject -datesAny claim about expiry, issuer or which hostnames are covered is settled by that output.
DNS: query it directly
dig +short MX yoursite.com
dig +short TXT yoursite.com # SPF lives here
dig +short TXT _dmarc.yoursite.com # DMARC policy
dig +short CAA yoursite.comThese four commands settle essentially every email-authentication claim. If an agent says your DMARC policy is p=none, the third command either shows that or it does not.
Crawler access: read the file, then resolve the rules
Open yoursite.com/robots.txt in a browser. Reading it is easy; resolving it is where mistakes happen, because the most specific matching user-agent group wins and a catch-all Disallow: / applies only to crawlers with no group of their own. If an agent claims a specific bot is blocked, ask which group and which line — a correct answer names both.
Content in the HTML: fetch it without a browser
curl -sL https://yoursite.com | grep -i "a distinctive sentence from your page"If nothing comes back, the content is added by JavaScript and most AI crawlers will never see it. This single command resolves a large share of "why can no assistant read my site" questions.
When the claim cannot be checked at all
Some claims have no artefact behind them by construction — "your site appears well maintained", "load times are probably fine", "your SEO is reasonably good". These are not verifiable because they are not observations. That is not a reason to argue with the agent; it is a reason to discount the statement and ask a question that has an answer.
A faster route
Running every command above for every claim is thorough and slow. An audit does all of it at once and returns the observed value alongside each verdict, which means you are checking the agent against a measurement rather than against your own recollection of what the command output meant.
What our audit reports about this
Every item below is measured directly, not inferred. Run it against your own site and the result names the exact rule or header responsible.
- Every response header with its exact observed value, so a claim can be compared rather than argued about.
- Certificate issuer, validity window, covered hostnames and negotiated protocol, read from the handshake itself.
- MX, SPF, DMARC and CAA records as returned by the resolver, with the policy parsed out.
- Per-crawler robots.txt resolution naming the group and rule that decided each verdict.
For agents and scripts, the same measurement is at
/api/v1/summary?url=yoursite.com —
see the API documentation.
Related questions
What if my check disagrees with the agent?
Check what you measured before assuming the agent is wrong — the usual causes are reading redirect headers instead of the final page, testing www against the apex, or a CDN serving different responses by region. If those are ruled out and it still disagrees, the agent was reconstructing rather than observing.
Why do I get different headers than the agent did?
Most often a CDN or WAF behaving differently for a browser than for an automated client, which is itself worth knowing. Comparing a curl request with a browser request on the same URL usually makes the difference visible immediately.
Is checking every claim necessary?
No — spot-check the ones you intend to act on, especially anything expensive. An agent that names accurate artefacts on three claims is usually reliable on the rest; one that cannot name any is not worth checking further.
Can I automate the verification?
Yes, and that is essentially what an audit is: every one of these observations, gathered in one pass, with the raw value returned next to the verdict so both you and the agent are reading the same evidence.
Read next
Can I trust what ChatGPT says about my website?
A practical guide to which parts of an AI answer about your site are reliable, which are guesses, and how to tell them apart in seconds.
ReadHow do I read a TLS certificate?
What each field in a certificate means, which ones actually matter, and how to inspect any site's certificate in one command.
ReadWhat do my DNS records actually say?
Reading your own DNS from first principles — which records exist, what each one decides, and the four commands that show you all of them.
ReadHow do I audit a website from the command line?
Getting a complete, machine-readable audit with one curl command — and pulling out just the parts you need with jq.
Read