Back
Bad bot vs real user: how to tell the difference
Learn which signals help separate automated traffic from real visitors - without relying on IPs or bot names alone
Bad bot vs real user: how to tell the difference
A bad bot does not have to look robotic. It can send ordinary HTTP requests, use a common browser, rotate network sources and imitate the same pages a customer would visit. A real customer can also look unusual: shared office networks, fast repeat visits and privacy tools can all break simplistic rules.
That is why modern bot detection is not a single “human or bot” test. The practical job is to combine several signals, verify automation you explicitly trust, and decide whether the traffic pattern matches normal customer use or coordinated automated abuse.
TL;DR
Do not trust one IP, one user-agent or one CAPTCHA result. Compare behaviour, browser, network, request sequence and endpoint. Verify known crawlers such as Googlebot independently. Treat CAPTCHA as optional defence in depth, not the definition of a human. The goal is to keep real users and useful automation moving while stopping traffic that behaves like abuse.
By [Author] · Reviewed by [Security Lead], ADPAL · Updated 20 August 2026
OWASP’s Automated Threats project focuses specifically on unwanted automation that misuses valid web functionality. That is the useful frame here: a request can be technically valid and still belong to an automated abuse campaign. Source: OWASP Automated Threats.
Why “prove you are human” is the wrong starting point
For years, websites often handled bot risk by asking the visitor to prove humanity with a CAPTCHA. That can still be useful in selected high-risk situations, but it shifts the work onto every person who sees the challenge.
W3C’s accessibility guidance documents a long-standing problem: CAPTCHA tasks can exclude or disadvantage people with disabilities, especially when a challenge depends on one sensory modality. OWASP also treats CAPTCHA as defence in depth, because implementations can be automated around or outsourced to human-solving services. Source: W3C CAPTCHA accessibility note · Source: OWASP Authentication Cheat Sheet.
Better model
Let the site evaluate the traffic first. Add extra friction only when risk justifies it. A customer should not have to solve a puzzle merely because your site receives bot traffic.
Why one signal cannot reliably separate a bad bot from a real user
Every shortcut has a failure mode. The rule may work for yesterday’s attack and then block a customer or miss tomorrow’s bot.
The stronger approach is correlation: several weak clues become useful when they point in the same direction.
| Single clue | Where it helps | Why it fails alone |
|---|---|---|
| 01IP address | One source generates obvious abuse. | Shared networks create false positives; distributed bots rotate sources. |
| 02User-agent | A known tool identifies itself honestly. | The sender controls the header and can copy a trusted name. |
| 03Request rate | One client sends an impossible volume. | Low-and-slow automation stays below static thresholds. |
| 04CAPTCHA result | Raises the cost of simple automation. | A challenge can be solved, outsourced or create friction for real users. |
| 05One browser clue | An obviously automated client exposes itself. | Modern automation can use real browser stacks or imitate common browser metadata. |
The five signal groups that matter most
No row in this table is a verdict. The point is to compare the traffic pattern across several dimensions and ask whether the combination is consistent with normal use.
| Signal group | Real-user pattern often looks like | Bad-bot pattern can look like |
|---|---|---|
| 01Behaviour | Requests tend to support plausible customer activity and business outcomes. | Repeated actions can optimise for extraction, testing or abuse rather than a customer goal. |
| 02Browser | Browser information is coherent with the request pattern. | Automation may expose inconsistencies or repeat an unusual browser pattern across many requests. |
| 03Network | Network context fits the expected audience and traffic history. | Abuse may rotate proxies, datacentres or residential networks to distribute the campaign. |
| 04Request sequence | Requests follow a plausible path through the site or workflow. | Automation can enumerate URLs, repeat high-value actions or jump directly between target endpoints. |
| 05Endpoint | Traffic is spread across the functions a real customer needs. | Bots often concentrate on login, search, price, signup, form or API endpoints that create value at scale. |
Correlation beats certainty from one clue
A residential network is not proof of a customer. A datacentre is not proof of a bot. A fast request is not proof of automation. Confidence rises when behaviour, browser, network, request sequence and endpoint all tell the same story.
Three examples: the same request can mean different things
01
Product search. Fifty search requests may be normal for a comparison-heavy shopper. The same volume spread across systematic catalogue queries with no customer activity may look like scraping.
02
Login. Three failed attempts can be an ordinary customer mistyping a password. Similar low-volume attempts distributed across thousands of accounts can form a credential-stuffing campaign.
03
Signup. A burst of registrations can be a successful campaign. If verification, activation and purchases stay flat while the same flow repeats automatically, fake account creation becomes more likely.
The business outcome helps
Technical signals tell you how traffic behaves. Business data tells you whether that behaviour creates the result a legitimate customer normally creates. Use both when investigating ambiguous traffic.
Good bots should be verified, not guessed
The “bot vs human” question is incomplete because some automation is valuable. Search crawlers, monitoring systems and approved partners may be exactly the traffic you want.
For named crawlers, identity should be verified independently where the operator provides a method. Google explicitly warns that its user-agent strings can be spoofed. It recommends reverse and forward DNS verification or checking requests against published crawler IP ranges. Source: Google crawler verification.
- Allow verified search crawlers. Do not block SEO traffic merely because it is automated.
- Document approved partners. Give legitimate automation a known path instead of forcing it to look like anonymous traffic.
- Keep AI crawler policy separate. Training crawlers, search crawlers and user-triggered fetchers can have different business value. See How to block AI crawlers.
- Do not trust the name alone. “Googlebot” in a header is a claim until verified.
Simple rule
A useful bot should earn trust through verifiable identity or an explicit business relationship. An unknown bot should not inherit trusted access because it chose a familiar name.
What about bots that imitate real users?
More capable automation can use full browsers, vary timing, rotate networks and deliberately avoid obvious request bursts. That makes simple rules less reliable, not bot detection impossible.
The practical response is to increase the amount of context used for the decision. A bot can change one header easily. It is harder to keep behaviour, browser, network, request sequence and endpoint use consistently aligned while operating at scale.
- Look across requests, not at one request in isolation. Repetition and sequence can reveal the automation goal.
- Compare endpoint use with customer value. A bot may spend nearly all its effort on the one function that is profitable to abuse.
- Expect network rotation. Treat source changes as part of the pattern, not as automatic proof that the traffic is unrelated.
- Retune controls as abuse changes. A fixed rule set is easier for an attacker to learn than a layered detection model.
Do not promise perfect classification
No detection system should claim that every request can be labelled with absolute certainty. Good security reduces uncertainty enough to make a safe allow, limit, challenge or block decision – while measuring false positives.
Where CAPTCHA still fits
CAPTCHA is not dead, and it is not a complete solution. It is a step-up control that can make some automated actions more expensive when other signals already make the request suspicious.
OWASP recommends treating CAPTCHA as defence in depth rather than preventative control, because challenges can be solved automatically or outsourced. W3C also documents accessibility concerns with challenge-based approaches.
- Use it selectively. Risky login, signup or form traffic is a better trigger than every visitor.
- Measure abandonment. Security friction has a conversion cost.
- Provide an accessible path. A control that a real customer cannot complete is a customer-facing availability failure.
- Keep other controls. Rate limits, authentication security and bot detection should not disappear because CAPTCHA is present.
Best use
Think of CAPTCHA as an extra question for uncertain traffic – not as the definition of a human.
Does behavioural bot detection mean tracking people?
Not necessarily. Bot detection and cross-site advertising profiles are different architectural choices.
For ADPAL, the relevant privacy position is: Cookieless, no cross-site tracking profiles, EU (Frankfurt) data residency. Per-request events are logged because they power security decisions and the dashboard. The system does not need to build a cross-site profile of a visitor to evaluate automated abuse around the protected site.
Ask vendors the precise question
Do not settle for “privacy-friendly”. Ask whether the product uses cookies, builds cross-site tracking profiles, performs device fingerprinting, and where request data is stored. See Cookieless Bot Protection.
A practical 30-minute bad bot vs real user audit
01
Pick one high-value endpoint. Login, signup, search, price, checkout or contact form is enough.
02
Export a short traffic window. Use reverse-proxy or server logs if available.
03
Separate verified automation first. Known search crawlers and approved partners should not contaminate the investigation.
04
Compare request sequence and endpoint concentration. Ask what goal the traffic appears to optimise for.
05
Check network spread. One campaign may be distributed across many sources.
06
Compare with business outcomes. Orders, leads, activations or other expected actions help explain ambiguous traffic.
07
Test the rule against real users. Before enforcing, check whether the same rule would catch shared offices, mobile networks or other legitimate traffic.
08
Measure again after enforcement. The result should be less abuse without a drop in real customer success.
Fastest first step
If you cannot see the split today, use a site check to establish a baseline before adding more IP rules, browser rules or challenges.
How ADPAL distinguishes automated abuse from legitimate traffic
ADPAL evaluates protected traffic using Advanced detection that correlates behaviour, browser, network, request sequence and endpoint. The decision does not rely on one static IP rule, one user-agent string or a mandatory puzzle for every visitor.
Verified good bots can be allowed. Real users continue through the protected flow. Suspicious automation can be limited or blocked before it reaches the application.
Cookieless, no cross-site tracking profiles, EU (Frankfurt) data residency.
Deployment
Point your DNS at the managed reverse proxy – live in hours, then a short monitoring period before enforcing. CMS-integrated deployment is available through hosting partners.
Frequently asked questions
How can you tell a bad bot from a real user?
Use several signals together rather than one rule. Behaviour, browser, network, request sequence and endpoint use can reveal whether traffic matches normal customer activity or coordinated automation. The strongest decisions come from correlation, not one suspicious IP or header.
Can a bot pretend to be Googlebot?
Yes. Google explicitly warns that crawler user-agent strings can be spoofed. Verify Google crawler requests using the methods Google publishes, such as reverse/forward DNS checks or its published crawler IP ranges.
Can advanced bots imitate human behaviour?
They can imitate many surface patterns and can use real browser software, varied timing and rotating networks. That is why modern detection correlates multiple signals and looks for coordinated behaviour across requests instead of trusting one clue.
Is CAPTCHA still useful for bot detection?
Yes, as a selective defence-in-depth control. OWASP notes that CAPTCHA can slow automated attacks but can also be solved or outsourced, so it should not be the only protection. Use it when risk justifies extra friction rather than on every visitor by default.
Does bot detection require tracking users across websites?
No. Cross-site tracking is not a requirement for bot protection. ADPAL is cookieless, does not build cross-site tracking profiles, and uses EU (Frankfurt) data residency. Per-request events are logged for protection and dashboard reporting.
Why is IP blocking not enough?
A real office or carrier network can put many legitimate users behind one public IP, while a bot campaign can rotate through many sources. IP remains useful context, but it is too weak to be the whole identity or decision.
What is the difference between a good bot and a bad bot?
A good bot performs an automated job you choose to permit, such as verified search crawling or an approved integration. A bad bot automates activity that conflicts with your policy or harms the business, such as credential testing, scraping, fake signup or form abuse.
Make bot detection the site’s job, not the customer’s
A real customer should not have to look “normal enough” for one simplistic rule. And a bot should not become trusted merely by changing its IP, browser name or request speed.
The useful middle ground is correlation: verify the automation you want, evaluate unknown traffic across several signals, and reserve extra friction for the cases that actually need it.
Next step
Measure the automated traffic reaching one high-value endpoint today. That gives you something concrete to separate, tune and protect before adding more rules across the whole site.