Good Bots vs Bad Bots: A Practical Taxonomy for SaaS

Your bot rule caught something last week. Was it the signup script, or Googlebot?

Most bot rules can't tell you, because they only ask one question: is this a person? Plenty of what fails that test is traffic you want. Search crawlers, the uptime check you pay for, the preview bot that builds a card when someone shares your link, a customer's AI assistant reading your pricing page. And plenty of what passes isn't welcome at all: a headless browser in its Sunday best, back for its twelfth free trial.

A bot isn't good or bad for being a bot. It's good or bad for what it does.

So sort bots by what they do. Good bots do a job you want done. Bad bots abuse the product. Neutral bots are the automation you invited yourself, and a blanket block breaks them first. Humanity tells you something is automated. Behavior, with Authenticity and Uniqueness, tells you whether to care. Dregs scores all four on every account, but the taxonomy below works with any judgment layer. Classify the act, not the outfit.

Types of Bots: Good, Bad, and Neutral

Here is the short version, with a sensible default policy for each bucket.

Don't let the user agent do the sorting. It's a name the client gives itself, and copying one costs nothing. Where an operator publishes a way to verify its crawler (IP lists, reverse DNS, signed requests), use it. Everywhere else, sort by what the client does once it's in.

Good Bots You Should Allow

Good bots aren't a loophole in your bot defense. They do jobs you already pay for, or jobs your customers now hand to an assistant. Blocking them to slow down a signup script is a bad trade: the script adapts by lunchtime, and you're left without the traffic you wanted.

Some traffic that looks automated isn't a bot at all. Screen readers, keyboard-only navigation, password managers, and autofill all move real people through a form in ways a naive bot rule reads as scripted: no mouse movement, every field filled in milliseconds. That's a person. A rule that can't tell the difference is an accessibility failure and a false positive at once.

Training crawls are a separate decision from user-initiated fetches. Search indexing, an assistant acting for a person, and a model-training scrape are different acts, and edge bot products increasingly expose categories for that split. Whatever you decide about training, account scoring still has to catch the client that borrowed an assistant's name and then farmed the free tier. The crawler names by job, and a policy for each, are in how to manage AI crawlers.

Bad Bots and the Abuse They Produce

Nobody running a signup bot intends to become a customer. The script invents names, rotates inboxes, and submits the form with the unhurried confidence of somebody who has done this a thousand times and intends to do it a thousand times more. Its owner, a creature of boundless patience and borrowed IP addresses, is stocking your user table with junk for later campaigns.

Left alone, the accounts pollute analytics, burn trial capacity, and sit until a buyer or a follow-on script needs them. The crude ones announce themselves in the user agent. The ones that do real damage render JavaScript, rotate residential proxies, and imitate a person well enough to get through the door. CAPTCHA solver farms and off-the-shelf headless frameworks have made that costume cheap. For how the pattern looks on the registration form itself, see signup bot detection.

Related trades use the same machinery for different jobs. Credential stuffing points the automation at login instead of signup, testing leaked passwords until one fits. Scrapers hoard content, pricing, or inventory. A bot farm is the coordinated version: a pool of accounts run as one resource, each looking ordinary, the population looking like a crowd of one. Volume nuisances of this kind are a blot on the metrics, and they are worth stopping. They are not a reason to lock the door on everything that isn't typing.

The costume matters less than you'd think. A client that calls itself a search crawler and then opens twenty trial accounts is a signup bot with a good tailor.

Neutral Bots: Automation You Invited

The third bucket is the one a global block always wrecks. Partner integrations, customer scripts against your API, QA bots in staging and production, and agents you have actually asked to use the product all look automated because they are. Low Humanity is expected. Policy should come from identity and behavior, not from a "block bots" toggle.

Name them. Allowlist the clients you know. Mark known-good automation as disregarded so it stops affecting analysis for everyone else. A QA bot that shares a device or an IP with real accounts will otherwise leak into Uniqueness and look like a farm you invented yourself.

How to Differentiate Good Bots from Bad Bots

Detection is cheap. Judgment is the work. "Is it a bot?" is a request-level question. "Should I care?" is an account-level question, and it needs history, identity, and behavior, not only a bot score on a single hit.

Map the decision to the four score dimensions rather than to a single bot/not-bot flag:

Notice which score does the least work. Humanity is the only one of the four that measures bot-ness, and it's the one you should act on least by itself. Behavior decides whether automation is a problem. Authenticity and Uniqueness catch the fabricated identities and duplicate accounts that bad bots leave behind.

Custom rules and lists turn the taxonomy into policy: a list of automation you've approved, a badge for accounts that look like bad bots, and an escalation only when several signals agree. Every score opens into its observations, so you can see exactly why before you act. That keeps false positives out of the support queue and means less manual review.

Don't put the whole defense on a puzzle at the door. CAPTCHAs tax people and good bots alike, and solver farms clear them cheaply (CAPTCHA alternatives covers what to use instead). Continuous Humanity scoring is the Dregs version of that alternative; risk-based challenges still belong only where a false allow is expensive. For how complementary tools sit in front of this judgment layer, see best bot detection tools for SaaS.

Allow, Disregard, or Stop

Once you can tell the types of bots apart, the response should match how expensive a mistake would be.

• Allow and verify. Search, monitoring, link previews, and assistants acting for a person. Prefer vendor verification over a user-agent substring.
• Disregard known-good automation. QA, partners, and invited agents should stop affecting everyone else's scores and links.
• Stop abusive automation before it becomes a user. Refuse to provision, throttle, or watch with a badge. Webhooks let the application react almost instantly, rather than after a review queue fills up.
• Graduate the response. Privacy-conscious people, unusual browsers, and shared office networks all look odd. A hard block on a single low Humanity score is a reliable way to manufacture false positives.

Signup bots often present as fake signups. When the same automation points at login, that is credential stuffing. Coordinated pools of accounts are a bot farm. None of those patterns is solved by blocking Googlebot.

Frequently Asked Questions

Further Reading