We fetched our own article under eleven agent names and published the bytes
HTTP 200, 63KB uncompressed and 1,789 words inside the article, identical to every name we sent, measured 16 October 2026. The result any publisher should be able to produce on demand, and how to produce yours.
Published by AI Knows Us · Updated 19 October 2026
On 16 October 2026 we requested one of our own articles eleven times under eleven different agent strings and got the same document back every time: HTTP 200, 63KB uncompressed, and 1,789 words inside the article element. The strings included GPTBot, OAI-SearchBot, ChatGPT-User, PerplexityBot, ClaudeBot, Googlebot, Google-Extended, a desktop browser string, a command line client and a request carrying no agent name at all. No arm got a shorter page, a different page or a refusal. That is a boring result and it is the one a publisher should be able to produce on demand, with the numbers printed rather than described.
Most writing about whether assistants can read your site is written in the conditional. This is a number you can check against our url this afternoon, which is the only form of this claim worth making. If our page changes, your reading will differ from ours and the difference is the useful part.
Why a word count and a byte size, rather than a yes
A status code is the weakest evidence available here. A 200 can carry a complete article, a navigation shell with no text in it, a cookie wall or a login screen, and all four look the same in a terminal unless you measure the body. So the test records three things per arm instead of one.
- The status of every hop, not only the last one. A redirect chain that ends in a 200 can still be serving a different page from the one you asked for.
- The response size, because a success code sitting on a near empty body is a delivery you would otherwise count as a win.
- The word count inside the article element, not the whole document. A page can gain thousands of bytes of framework payload without gaining a single readable word, and the article boundary is where the two separate.
Our figures are 63KB and 1,789 words on the same document, which is a ratio worth knowing for your own pages. If your byte size is large and your word count is small, the gap is script and markup, and that gap is exactly what a client running no scripts cannot turn into text.
The arms worth including, and the three cheap ones people leave out
| Arm | What it answers |
|---|---|
| Each named AI agent | Whether anything in your stack is deciding on the name |
| A desktop browser string | Your control. If this fails too, the problem is not about names |
| No agent string at all | Catches rules that key on an absent or unexpected header |
| A plain command line client | Shows what arrives with no browser behaviour of any kind |
| Googlebot | Separates your search crawl from your assistant crawl, which are different stacks |
The last three are the ones that get skipped and they are the ones that find things. A rule that refuses a nameless request while serving a browser tells you the decision is being made on the string. A rule that refuses both tells you something is counting requests instead of reading them.
Parity is per fact, not per site, and we have the failure to prove it
Here is the part that stops this being a victory lap. The same run found a real problem on a different page of ours. Our pricing page returned 88KB to GPTBot of which 55KB was script payload, and the visible first response carried rupee figures and no dollar, pound or euro figure at all, because the currency conversion ran in the browser. An assistant asked what our product costs in the United States read our page and found rupees.
So a page can pass a parity test perfectly and still be useless for the question a buyer is actually asking. The article was identical to all eleven names; the price was absent from the document for every one of them. Parity asks whether everybody gets the same thing. The next question, which fact is in there, is a different test, and the measurement behind it is in our page on what a crawler receives in the first response. We fixed the pricing page the same afternoon, which is the half of the story worth more than the finding.
The site level reading, and its honest boundary
Alongside the single page test we fetched every url in our own sitemap and every one returned 200, 1,721 of them on the day the check ran. That is a different claim from the parity result and it is a weaker one: it says nothing failed, not that every page carried the words it should. The two readings answer two questions and neither substitutes for the other.
Three boundaries belong on any version of this you publish. It covers the pages you fetched, on the day you fetched them. It covers HTTP level requests under agent strings, not whatever each operator does internally afterwards. And it says nothing at all about whether an assistant quotes you: our own citation figure is 3 of 597 readings of ChatGPT and Gemini on 15 October 2026, and 6 of 1,260 readings of the same two engines on 16 October. Delivery was never our problem and the citation count is still that low.
Questions about testing whether your pages reach AI crawlers unchanged
How many agent names is enough?
Start with the operators whose answers your buyers read, then add a browser control, a nameless request and a plain command line client. The three cheap arms cost nothing and they are where the surprises live.
Should I compare the bytes or the words?
Both, in that order. Compare the byte size across arms first, because a difference there is immediate and unambiguous. Then compare the word count inside the article boundary, because that is the number that survives a framework upgrade changing your markup.
My page returns 200 to everything. Is that the test passed?
It is the delivery question answered and the content question still open. Pick the three facts you most want quoted about your business, search the raw response for each exact string, and record which arms contain it. That is the reading that changes decisions.
Why include a request with no agent string?
Because it is the one arm nobody configures for, and it separates a rule about names from a rule about volume. On one host in the same programme a nameless request was the only one served, and on another it was refused alongside the named agents.
Does an identical response to every agent mean I will get cited?
It means nothing is in the way. Being quoted depends on whether your page answers the question better than the source currently being used, and in our 16 October 2026 run 82.0% of citations went to vendor or agency own sites and 12.3% to official platform documentation. Access clears the path and the page still has to earn the citation.
Publish the number, not the reassurance
The difference between a page that says your content is readable and a page that says 63KB and 1,789 words identical across eleven arms on a named date is that the second one can be checked and the first one cannot. That is the whole argument of this company, applied to its own site, and the two Google Search Console exports and the dated blind scan that back everything else we claim are published with their windows on our proof page. We make our money running these readings for other companies and repairing what they expose, which is why the method and both of our own results, the clean one and the embarrassing one, are printed here. If you are deciding who inside your organisation should own a check like this, the division of labour is set out in our workflow standard and its six stations.