Five Common Bot Detection Mistakes That Trigger False Positives

September 28, 2026
Bot Detection

Bot detection fails in two directions, but only one of them makes noise. A missed scraper shows up as an odd bandwidth bill or an incident review. A blocked customer shows up as nothing at all. They hit the wall, refresh once, and leave without telling anyone. That silence is why false positives survive so long in production: the dashboard looks calm while the system quietly turns away the traffic you most wanted.

Mistake 1: Blocking on the first signal that looks wrong

Aggressive blocking usually starts as a reasonable instinct. Something looks off — a strange user agent, a burst of requests, an address that resolves to a hosting provider — so you return a 403 and move on. The trouble is that "looks off" is not the same as "is a bot," and a hard block is the least reversible response available to you.

Take a shared office connection. A few hundred employees behind one IP can produce request patterns that resemble a single client on a fast line. Ban that address and you have blocked an entire company for the rest of the day. The same thing happens on university networks, public Wi-Fi, and in any household where several devices load pages at once.

A graduated response costs a little more engineering and saves a lot of grief:

Allow and log the first suspicious event instead of acting on it.
Serve a challenge or a slower path rather than an error page.
Throttle or queue requests before you consider dropping them.
Reserve hard blocks for clients with sustained, clearly automated behavior.

Every block is a decision about a person you cannot see. Keep it reversible for as long as you reasonably can.

Mistake 2: Trusting a single signal

No single indicator holds up on its own, and the ones teams lean on hardest are the easiest to break. User agents are self-reported and trivially copied; browsers now expose less detail than they used to, and privacy tools freeze or randomize what remains. IP reputation flags VPN users, corporate proxies, and mobile carriers. Fingerprints collide whenever thousands of people run the same device model with the same browser build.

What works better is a weighted combination. Request timing and interval regularity, session-level navigation paths, header order and TLS characteristics, whether cookies and browser APIs behave consistently with the client's claimed identity, and how the client reacts to a challenge. Each is noisy. Together they form a picture you can defend in a review.

Two habits help here: tune thresholds per endpoint, since a login page and a marketing page tolerate very different behavior, and write down why each rule exists. A rule nobody can explain is a rule nobody will dare remove.

Mistake 3: Ignoring mobile traffic and shared networks

Mobile is where false positives hide. Carrier-grade NAT puts thousands of subscribers behind a single address, so "one IP, many sessions" describes an ordinary Tuesday on a cellular network. A user who switches from Wi-Fi to cellular mid-session changes address entirely; if you bind a session to an IP, that switch looks like session hijacking.

What mobile clients do differently

In-app browsers on social and messaging platforms sometimes strip the referer, skip parts of JavaScript, or load pages in ways no desktop browser would. Users open several tabs and read one. Backgrounded tabs fire timers, then wake up and burst requests. Patchy connections cause retries and duplicate submissions, which read like a flood if you are only counting per-second rates.

The practical fix is segmentation. Give mobile its own thresholds, keep sessions resilient to address changes by validating a session token rather than assuming a fixed IP, and stop treating shared addresses as an automatic strike. None of that weakens detection much. It just stops punishing people for their network.

Mistake 4: Forgetting the legitimate bots

Plenty of fast, mechanical, headless-looking clients have no interest in scraping you. Search crawlers index your pages. Uptime monitors check that you are up. Payment, shipping, and CRM webhooks post to your endpoints on a schedule. Email security scanners fetch every link in a message, chat apps generate link previews, and accessibility tools and RSS readers pull content on the user's behalf. Your own synthetic tests do the same, from a data center, at machine speed.

Most of these arrive from hosting ranges and behave exactly like the traffic you are trying to stop. Handle them deliberately:

Verify identity through published address ranges or reverse DNS, not user agent strings, which anyone can copy.
Document each allowlist entry with an owner and a review date.
Re-check the list every few months; integrations end and rules rarely do.

A rule added for a vendor pilot two years ago is still letting traffic through today. Treat allowlists as living configuration, not as a one-time setup step.

Mistake 5: Running detection without a feedback loop

This is the quiet cause of most long-lived false positives. Blocked users rarely complain; they leave. Your support queue stays empty, the block rate looks healthy, and the same rules keep firing month after month because nothing ever contradicts them.

You have to manufacture the feedback:

Give blocked users a way to report a problem, right on the challenge or block page.
Sample blocked sessions weekly and label them by hand. Fifty reviewed decisions teach you more than another signal.
Connect detection data to downstream outcomes, such as a session that returned on another device and completed a purchase, or a support ticket that mentions being blocked.
Track false positive rate by segment — mobile, region, browser, logged-in versus anonymous — instead of one global number.

Then give that number an owner. Someone should be able to say, this week, which rules fired most often and which blocks we regret. Without that, tuning is guesswork with a dashboard attached.