“Is this a bot?” is the most expensive question in online business. Answer it wrong in one direction and you pay for fake traffic; answer it wrong in the other and you block real customers. The good news: you don't need to guess. There are concrete signals — and, just as important, a right way to combine them.
The one rule that matters
No single signal proves a bot. The right question is never “is this suspicious?” but “can I actually prove this is automated?” Real people trip individual checks all the time — a privacy VPN, an old phone, a corporate network. Block on one weak signal and you'll block humans. The signals below are strong together, not alone.
The signals that actually work
- 1. IP reputation — is the address a proxy, VPN, TOR node or datacenter? Datacenter traffic on a consumer site is the clearest tell. Check any IP here.
- 2. Known-bad lists — community blocklists (FireHOL, CrowdSec) flag IPs caught attacking others recently.
- 3. Residential-proxy pools — clean-looking home IPs whose network shows proxy-pool behavior. Lists miss these; pattern analysis catches them.
- 4. User-agent honesty — obvious automation strings (headless browsers, scraping libraries) and impossible combinations. But beware: modern Chrome deliberately reduces its user-agent for privacy, so a shortened UA is not a bot signal on its own.
- 5. Request headers — real browsers send a consistent, ordered set of headers (Sec-Fetch, client hints). Missing or inconsistent headers are a red flag — on desktop especially.
- 6. Browser integrity — on a real visit you can test the browser itself: is it headless, is WebGL faked, is automation flagged? A non-browser can't pass.
- 7. TLS fingerprint — the way a client negotiates its secure connection (its JA3/JA4 fingerprint) often reveals a scripting library pretending to be a browser.
- 8. Behavior over time — does it engage, scroll, and dwell like a person — or fire one request and vanish? Bursts of identical requests are a giveaway.
- 9. Behavioral history — has this exact IP been caught acting like a bot before, across a live network? History travels with the address.
Notice the split: signals 1–4 you can get from the IP and request alone. Signals 5–9 need the live visit — the browser, the handshake, the behavior. That's why a bare IP lookup can flag the obvious cases, but only a live check catches the sophisticated ones.
The false positives that cost you customers
The most common way to get bot detection wrong is to punish real humans for looking unusual. Watch for these traps:
- Mobile browsers in pop windows can legitimately report a zero window size — that's not headless, it's the mobile browser.
- Reduced user-agents (Chrome's
.0.0.0versions,Android 10; K) are a privacy feature, not a bot. - VPN readers in censored regions are real audiences. A VPN flag alone should never hard-block them.
- Carrier / CGNAT IPs share one address across many real phones — don't treat volume from one carrier IP as an attack.
Start with the IP — free
See proxy, VPN, hosting, country and a 0–100 bot-risk score for any address in one second.
Open the IP CheckerDoing it automatically
Running these checks by hand doesn't scale — the point is to apply them to every visitor, instantly, without blocking real people. The PureGuard WordPress plugin does exactly that: it combines all nine signals live, blocks confirmed bots before your page loads, and is deliberately tuned to never hard-block a real visitor on a single weak signal.