Good Bots and Bad Bots: How to Classify Automated Traffic

A good bot is authorized automation that behaves within the site's rules and creates an intended benefit. A bad bot uses automation to create harm, evade policy, or consume resources without permission. Unknown bots have not yet provided enough evidence for either conclusion. Classify automated traffic by verified identity, behavior, requested action, permission, and impact rather than by the fact that it is automated.

Examples of legitimate automation

• Verified search-engine crawlers indexing public content according to crawl policy.
• Uptime and synthetic monitoring services checking agreed endpoints.
• Partner integrations calling documented APIs with valid authentication.
• Accessibility, archiving, feed, and security services that the site has chosen to support.
• Internal scheduled jobs operating through a private or authenticated trust boundary.

Legitimate does not mean unlimited. A verified crawler can still reach only the routes that policy allows, and an authenticated partner can still be rate-limited. Permission is scoped to an identity, purpose, resource, and operating limit.

Examples of malicious automation

Bad bots are defined by what they do and the result they seek. OWASP's automated-threat taxonomy includes credential stuffing, carding, scraping, scalping, denial of inventory, spam, token cracking, analytics skewing, and automated vulnerability scanning. The requests may look valid at the HTTP layer while abusing normal application functions.

• Testing stolen credentials across many customer accounts.
• Collecting content or data beyond the site's authorization and usage rules.
• Holding inventory or consuming limited resources without completing a purchase.
• Submitting repetitive clicks, views, votes, or forms to distort a metric.
• Enumerating identifiers, tokens, coupons, accounts, or application structure.
• Impersonating a trusted crawler or browser to bypass policy.

Unknown automation deserves its own state

A binary good-or-bad label forces decisions before the evidence is strong enough. Unknown automation may be a new legitimate integration, a privacy-preserving user agent, a research crawler, a misconfigured monitor, or an attacker testing defenses. Treat uncertainty explicitly so low-risk routes can be observed while high-risk actions receive stricter controls.

Five questions for classifying a bot

1. Identity: can the claimed operator be verified through published addresses, mutual authentication, credentials, or a documented process?
2. Permission: has the site authorized this operator, route, purpose, and data use?
3. Behavior: does request volume, timing, navigation, and failure activity match the authorized purpose?
4. Resource: is the bot accessing public content, an authenticated API, a login flow, checkout, or an administrative action?
5. Impact: does the activity create account risk, data loss, cost, availability problems, inventory pressure, or distorted measurement?

Signals are evidence, not verdicts

User agents, IP ranges, ASN, country, hostname, browser family, device type, headers, parameters, reputation, and request frequency can all contribute evidence. Each also has limitations. A user agent can be spoofed, an IP can be shared, a residential address can host abuse, and a cloud address can belong to a legitimate service. Strong decisions combine signals and preserve the reason for later review.

Map classification to policy

• Verified and authorized: allow within the approved scope and monitor for drift.
• Verified but out of scope: deny or constrain the request despite the known identity.
• Unknown and low risk: allow with logging or apply a conservative rate limit.
• Unknown and high risk: require stronger proof, step-up authentication, or a challenge.
• Malicious or policy-violating: deny, throttle, isolate, or return the configured response.
• Previously abusive but now quiet: re-evaluate temporary mitigation instead of creating an unexplained permanent block.

How Stopbot represents classification and policy

Stopbot separates isBot from blockAccess because bot classification and permission answer different questions. A verified or permitted bot can be automated without being blocked. A request that is not classified as a bot can still violate another configured rule. Use detectActivity to understand the reason and apply the final policy field only after confirming a successful API response.

{
  "isBot": 1,
  "blockAccess": 0,
  "detectActivity": "Allow by active policy"
}

The example illustrates the model rather than a guaranteed literal reason string: automation can be identified while the active policy still allows it. Integrations should document which values come directly from the API and avoid inventing meanings for fields they do not recognize.