Design the Bot Check So Real People Get Through

Security & Access · abuse prevention, security, errors

Updated 2026-08-04

Count the cost of the check on the people it does not target. Abuse controls are judged on what they block, and the number that matters is how many genuine users they stopped.
Show the check only where the risk is. Sign-up, password reset, and posting are worth protecting, and browsing a public page rarely is.
Escalate rather than gate. A silent signal for most visitors, a CAPTCHA for the suspicious ones, and a hard block only for the clearly abusive keeps the common path clean.
Know who your check punishes disproportionately:

People on shared or corporate connections, who look like many users on one address.
People using privacy tools or older browsers.
Screen reader users, for whom most visual challenges are unusable.
Users in regions where your traffic patterns look unusual.

Give an accessible alternative and make it findable. A challenge with no audio or non-visual route is a locked door for a group of users.
Never lose the user's work behind the challenge. A post that has to be rewritten after passing a check is a failed interaction whatever the check decided.
Say what happened when someone is blocked, and give them a route out. We could not verify this request with a way to contact support is recoverable, and a blank refusal is not.
Limit by account and by action, not only by network address. Address-based limits are trivially spread across many machines and hit shared connections hardest.

Every abuse control is a tax on legitimate users, and the design question is how small you can make that tax rather than how large you can make the wall.