Key findings
- 3 of 6blocked at the gate: two fake search engine bots and one AI crawler.
- 2 of 6sent to an invisible check instead of the page: both claimed to be Chrome.
- 1 of 6got through: a plain script that asked for one page and said what it was.
Our demo site, demo.qlyne.com, sits behind the same proxy our customers run on their own servers. On 18 October 2026 we pointed a small script at its front page with six different disguises, one request each. This is a sanity check, not a benchmark: six requests, one page, one run. What it shows is how each layer of the gate answers a visitor it was built for.
The six visitors
| Profile | What it pretends to be | Verdict |
|---|---|---|
| Plain script | A command-line client that says so in its user agent | passed |
| Fake Googlebot | Googlebot by name, sent from an address outside Google's network | blocked |
| Fake Bingbot | Bingbot by name, sent from an address outside Microsoft's network | blocked |
| AI bot | An AI crawler (GPTBot) that names itself | blocked |
| Automated browser | Chrome by name, without the headers a real Chrome sends | checked |
| Chrome lookalike | A recent Chrome with consistent headers, from a script that cannot run JavaScript | checked |
Why the fake search bots were blocked
A user agent is a claim anyone can type. Google and Microsoft publish the networks their crawlers come from, so the gate checks the address of every request that claims to be one of them. Ours said Googlebot and Bingbot and came from somewhere else, and that mismatch is enough to block. A real Googlebot, coming from Google's network, goes through.
Why the AI crawler was blocked
The demo blocks AI training crawlers by category, a setting in the dashboard. GPTBot names itself honestly, so the rule matched on the name and nothing more was needed. The hard case is a crawler that pretends to be a browser, and that is what the next two profiles are about.
Why two were checked instead of blocked
Both said they were Chrome. The first left out headers that every current Chrome sends with a page request, which is a strong hint of automation. The second sent all of them, consistently. In both cases the gate was not sure enough to block, so it answered with a check: a small proof of work that a real browser solves in the background without the visitor noticing. A script that cannot run JavaScript stops there.
The Chrome lookalike is the profile to watch. It is the closest a simple script gets to a person, and we would rather ask it a question than turn it away, because a wrong block costs a real customer.
Why the plain script got through
It asked for one page, said what it was and did nothing else. That is what an uptime monitor or a feed reader looks like, and blocking it would break tools people rely on. When a script like this asks for too much, too fast, the rate limit is what stops it.
What this does not show
Six requests do not measure accuracy. They show that each layer answers the way it was designed: the network check for search bots, the category rule for AI crawlers, the browser checks for lookalikes and the rate limit behind them. Real traffic is messier. That is why every new site starts in Observing and shows you what would have been stopped before anything is blocked.
How we measured
One GET request to the front page per profile, from one address of ours, a second and a half apart. Nothing touched login pages, traps or anything that changes state. The verdict is what came back: the normal page, the check page or a block. The same run feeds the scoreboard on our front page.