Is the GPTBot in your server logs really OpenAI? A vulnerability scanner wore 6 AI-crawler user-agents for 22 requests in 4.5 seconds — and was every 'Google-Extended' fetch we ever logged

The burst, request by request

Method: the ledger is edge middleware that records every bot-shaped user agent before any JavaScript runs, with the request path, the edge's country code and a timestamp; rows are classified into vendor and kind by a user-agent token table. Every row above carries the edge country SG and falls inside 4,511 milliseconds. The 22 paths are the standard shopping list of a secrets scanner — environment files, git metadata, cloud credentials, `/etc/passwd` through path-traversal tricks (`/media../`, `/static../`, `/@fs/`) — and not one is a page this site has ever served. The ledger stored no IP address at the time, so the burst is named by country and timing rather than by address; that gap is part of what we fixed, below. The full row set is saved machine-readable beside this post.

What the vendors say a real request looks like

• Google: the 'Google-Extended' user agent does not exist. Google's common crawlers page, read today: "Google-Extended doesn't have a separate HTTP request user agent string. Crawling is done with existing Google user agent strings; the robots.txt user-agent token is used in a control capacity." Google-Extended is a name you put in robots.txt to control AI training use; it never appears in a request. The string the scanner wore — `Mozilla/5.0 (compatible; Google-Extended/1.0; +http://www.google.com/bot.html)` — is an invention, and every one of the four rows our ledger has ever booked under it came from this burst. Google's verification page gives the real test: "Run a reverse DNS lookup on the accessing IP address from your logs, using the host command. Verify that the domain name is either googlebot.com, google.com, or googleusercontent.com" — or match the address against the published `googlebot.json` (315 prefixes, regenerated 2026-08-21).
• OpenAI publishes an IP list per bot. The OpenAI crawler overview lists a 'Published IP addresses' JSON for each agent: `gptbot.json` (21 prefixes), `searchbot.json` (35) and `chatgpt-user.json` (204, regenerated 2026-08-14). Two of the scanner's three OpenAI strings match OpenAI's documented examples character for character (GPTBot/1.4 and ChatGPT-User/1.0); the third, `OAI-SearchBot/1.3`, is shorter than the documented string and one version behind it — a weak tell at best, since OpenAI notes the version number may change. The strong test is the address, and a Singapore scanner is not in those lists.
• Amazon publishes one too. The Amazonbot page gives an example string and a 'Published IP Addresses' page for each of Amazonbot, Amzn-SearchBot and Amzn-User. The scanner's Amazon strings are truncated versions of the documented ones (no `Chrome/… Safari/…` tail) and carry a version Amazon does not document for Amzn-SearchBot (1.0 vs 0.1). Again: suggestive, not proof. The address is the proof.

What 22 requests did to a week of counts

The damage is proportional to how rare the real thing is. ChatGPT-User and OAI-SearchBot fetch this site hundreds of times a week, so three fake rows barely move them. GPTBot — the training crawler, the one most robots.txt debates are about — fetched this site 7 times this week, so four fakes made it 11, a 57% overstatement. In the 24-hour window our analyst reads each morning (08-21 09:37Z to 08-22 09:37Z) the per-vendor figures moved from 245 rows to 223: google/crawl 4 to 0, openai/crawl 23 to 16, openai/user 39 to 36, amazon/crawl 39 to 31. Every one of the 'Google-Extended fetches' that window reported was the scanner.

Why this matters if you care about AI visibility

• Every 'GPTBot traffic' chart built from user-agent strings — ours and everyone's — carries this contamination. Crawler-traffic reports from analytics vendors and CDNs classify by user agent unless they say otherwise. The error is small for high-volume agents and large for the rare ones, which are exactly the agents people make decisions about. If a report says a training crawler fetched your site a handful of times, ask whether the rows were address-verified before you block anything or celebrate anything. We reported how fast each AI crawler fetches a new page three days ago from the same ledger; those rows were page fetches on real paths and none match the scanner shape, but the instrument that produced them was blind to this until yesterday.
• 'Google-Extended' in a request log is a tell, not a data point. Google says the string does not exist. A log row carrying it is a third party naming Google — usually a scanner or a scraper hoping a Google name gets it past a WAF rule. The same logic applies to any robots.txt-only token that shows up as a user agent.
• A user-agent string is a claim; the address is the evidence, and the evidence is free. Google, OpenAI and Amazon each publish the address ranges their crawlers use, in machine-readable form, refreshed on a schedule. Verifying costs a lookup. Our fix: the ledger now tags any request whose path matches a secrets/traversal shape as spoofed, excludes those rows from every count by default, and stores the request's /24 on spoofed rows only — so the next burst is named by address, not just by country. A backfill over 1,525 stored rows flagged exactly the 22 above and nothing else. The fetch-versus-index story in yesterday's post on Googlebot and new posts is unaffected: that count was of Googlebot page fetches on real paths, and no spoofed row carries a Googlebot string.

Limits

One small site and one burst — n=22 rows on a 5.7-day-old ledger of 1,524 bot-shaped rows, a 1.4% contamination rate that says nothing about yours. The ledger only records bot-shaped user agents, so a scanner wearing a browser string is invisible to it, and this burst is the one we caught, not the population. No IP was stored for these 22 rows, so 'Singapore' is the edge's country code and the attribution to a scanner rests on the paths and the 4.5-second cluster, which we consider conclusive for these paths but cannot corroborate by reverse DNS. The tells in the user-agent strings (versions, truncation) are noted because they were there, not because they are a test; the vendors' address lists are the test. Nothing here says any of the three vendors did anything — the point is that their names were borrowed, and that a user-agent-only instrument cannot tell. The IbouBot and PetalBot post from the same ledger stated the same UA-only limit two days ago; today is what the limit looks like when it bites. If you want to know whether the engines that really do crawl you are naming your business when customers ask, run a free check.