This morning I told my own website that I was ClaudeBot. It took one line of curl and a user agent string copied out of Anthropic's own documentation. Three requests to one article page. Then I opened my dashboard: Anthropic, ClaudeBot, training — 1,698 requests had become 1,701, last seen at 09:22. None of them was ClaudeBot. They came from a laptop in Japan, over ordinary home broadband, from an address that appears on no crawler list anywhere. The instrument was not broken. It was doing exactly what it is built to do, which is to write down what arrived and what it called itself. A user agent is a claim. Anyone can type it. The whole question is how much of what you are measuring is a claim you can check, and the honest answer is worse than I expected — including, as it turned out, in ways that were my own fault. The column nobody looks at There is a way to check, for some of them. A vendor can publish the IP addresses its crawlers run from. If a request claiming to be GPTBot arrives from an address on OpenAI's published list, it is GPTBot. If it arrives from my laptop, it is not. Some vendors publish such a list. Some publish nothing at all. So my dashboard has a column called Verified, and it is the least glamorous number on the page. Here is one site, davaonline.net, over the thirty days ending September 4, 2026: 13,491 crawler requests, of which 10,390 landed on pages with actual writing on them. Sorted by volume, with the share of each that could be confirmed: Crawler (requests) Verified meta-externalagent (5,728) no method published ClaudeBot (1,698) no method published Applebot (1,479) 98% Perplexity-User (984) 0% ChatGPT-User (887) 6% Bytespider (767) no method published GPTBot (598) 81% CCBot (440) no method published Amazonbot (342) no method published OAI-SearchBot (242) 60% meta-webindexer (110) no method published PerplexityBot (103) 0% Claude-User (69) no method published GoogleOther (25) 100% Claude-SearchBot (19) no method published 1 in 6 Requests that arrived with proof of who sent them. Roughly 2,200 confirmed out of 13,491. Everything else is a string I wrote down because it was handed to me. That single number hides three completely different failures, and separating them is the only useful thing I can do here. All 13,491 requests, by why verification did or did not happen No verification method published by the vendor 6,947 51% Published, but my bundled copy was out of date 2,226 16% Published, I had it, and the address did not match 4,318 32% Failure one: nothing to check against Meta, ByteDance and Amazon publish no IP ranges and no reverse-DNS scheme for the crawlers in that table. There is no list to compare an address to. Not a hard case, not an unlucky one — there is simply no mechanism, so verification is not slow or partial, it is impossible. That accounts for 6,947 of the 13,491 requests. More than half the traffic in this table comes from vendors who have decided that site owners do not need a way to tell whether it is really them. The largest single crawler on the site, meta-externalagent at 5,728 requests, is in this group. Amazon is a near miss worth naming: it does publish a page of addresses for Amazonbot, but as a web page whose contents only appear after JavaScript runs. A list a machine cannot read is a list that does not exist for this purpose. And a small trap for anyone else doing this: ByteDance's obvious candidate URL returns HTTP 200. The body is a 404 page. If you check for a published list by looking at status codes, you will conclude they publish one. Failure two: the list existed and I was out of date Look at the Anthropic rows and the CCBot row in that table. They say no method published. That was true when the plugin's bundled snapshot of vendor ranges was taken, on July 20. It is not true now. Anthropic began publishing a range list on August 18, replacing an explicit statement that it did not. Common Crawl published one on August 11. Both landed inside the thirty days measured above, and my instrument went on reporting the old world, because a design decision I am otherwise happy with — the plugin never talks to the network, so vendor ranges ship as a snapshot — means the snapshot goes stale silently. That is 2,226 requests, sixteen percent of the total, reported as unverifiable when they were merely unverified by me. I fixed it on September 4; the count of crawlers this instrument can verify went from eleven to fifteen. The fix also caught a Google crawler that had been listed as verifiable for months while its ranges were never actually bundled. I would rather not have found this while writing an article about verification. But it is the more useful half of the lesson: whether a crawler is verifiable is not a property of the crawler. It is a property of how fresh your copy of somebody else's list is, and it decays without telling you. Failure three: the list existed, I had it, and it did not match This is the one I cannot explain away. Perplexity publishes IP ranges. I had them. Over thirty days, 984 requests arrived calling themselves Perplexity-User and 103 calling themselves PerplexityBot. The share of them coming from an address on Perplexity's own published list was not low. 0 Requests claiming to be Perplexity that came from Perplexity's published addresses. Out of 1,087, over thirty days, checked against a list I had. OpenAI publishes too, and keeps it current — its ChatGPT-User list was refreshed on August 14. Six percent of the 887 requests claiming to be ChatGPT-User came from it. There are at least four explanations and I can rule out none of them: The requests are not from those vendors. Forging a user agent costs one line of curl, as established at the top of this article. Somebody scraping the web has an obvious incentive to wear a name that site owners have been told to allow. The published list is incomplete. Perplexity's user-fetch list contains four address ranges and was last updated in October 2025. Its crawler list contains eight, last touched in February 2025. A company serving live questions at scale from four ranges, unchanged for eleven months, is at least worth a raised eyebrow. Real fetches run outside the published infrastructure. User-initiated fetching often runs from different machines than bulk crawling, and nothing obliges a vendor to put those in the same file. My own verification did not run. Addresses are checked by an hourly background job that processes a bounded batch and discards anything older than a day. A request that was never checked and a request that was checked and failed both appear in that column as unverified. My dashboard does not currently tell them apart, which on reflection is a defect and not a detail. The last one deserves the discomfort it causes. I can report the share of traffic I confirmed. I cannot report the share I disproved. Those are different quantities, and an instrument that reports only the first should say so out loud rather than let a low percentage imply an accusation. What you can still conclude Less than you would like, but not nothing, and the shape of it is stable. The verified count is a floor on real crawler activity and never a ceiling. Every failure mode above pushes the same way: it turns real visits into unconfirmed ones, never the reverse. The unverified count is not an accusation. Most of it is vendors who published nothing, which is a policy choice on their side, not evidence about the request. The gap is worth watching per vendor rather than in aggregate. A vendor that publishes ranges and still matches nothing is telling you something. A vendor that publishes nothing is telling you only that it published nothing. None of this changes the finding from last week's piece: this site was read roughly ten thousand times and visited twice. Whether every reader was who it claimed to be does not make the reading less real. What this instrument cannot see One site, one month. A different site, in a different language, on different hosting, would draw a different table. This is an instrument reading, not a study. Cached pages are invisible. When a page cache answers, PHP never runs and nothing is recorded. Every count here is a lower bound. The percentages are rounded. The dashboard reports whole percentages, so the "roughly 2,200" above is derived from rounded figures and should be read as approximate. Verification confirms a vendor, not a crawler. Anthropic publishes one combined list for all three of its crawlers, so a confirmed hit means the request came from Anthropic, not which of its crawlers it was. The uncomfortable part is not that some crawlers cannot be verified. It is that the line between the ones that can and the ones that cannot moved twice last month, in my favour both times, and my instrument did not notice until I went looking for something to write about. If you are running any measurement of this kind, the question is not whether your numbers are right today. It is when you last checked whether the world they describe still exists. How to measure your own site The instrument is a WordPress plugin called AILYS Lens, and it is free. I build it, which you should factor into everything above — including the parts where I am the one who got it wrong. Every calculation runs on your own server, nothing is transmitted anywhere, and human visitors are never recorded. The Verified column described here is on the main dashboard, and vendors with no published method are marked as such rather than folded into a single number. A note: what changes on September 15 AILYS Lens is free permanently. That is a design commitment rather than a pricing stage — every feature runs locally on your server, so there is nothing for a paid tier to unlock. The diagnostic service alongside it, AILYS Doctor, is a different thing. Lens tells you what happened; Doctor tells you why, and what to change. It has been free during its data-collection period. On September 15, 2026 it becomes a paid subscription: $19 per month, or $10 per month for anyone who subscribes before the end of 2026. See a sample diagnosis · AILYS Doctor Illustration generated with AI and selected by the author.