6 ways to prevent bot attacks on your website
Six controls that stop bad bots on a website: traffic monitoring, honeypots, risk-based CAPTCHA, device-level blocking, a WAF and rate limits.
A bot is a program that performs a task on the web at machine speed: it fills in milliseconds the form that takes a person 30 seconds, and it does so ten thousand times. Some bots you want, such as Google's crawler. The rest scrape your prices, stuff your login, spam your forms and buy out your inventory, and they do it from traffic that looks like visitors.
The six controls below cut that traffic without blocking real customers. Start with the cheapest and measure after each one.
What a bot attack does to a website
Bad bots slow the server, inflate hosting bills, fill forms and comments with spam, scrape content and prices, test stolen credentials against the login, and pull data out of forms and APIs. Each of those costs money directly, and the server load degrades the site for the humans trying to use it.
How to prevent bot attacks: 6 steps
Start by finding out which bots are hitting you and where, then put the control at that point.
1. Monitor your traffic
During an attack your traffic goes up but your real visitors do not. Bad bots make up nearly 29% of traffic, so a chunk of what your analytics calls users is not. Watch for spikes that do not match a launch, a campaign or a news mention.
Then look at the sources: unusual or outdated user agents, repeated requests from one IP or range, a bounce rate near 100% from one segment, and server slowdowns with no matching rise in orders. Site Explorer and SEMRush show these metrics; your server logs show them sooner.
2. Use honeypots
A honeypot catches bots by offering them something a person never sees.
The common form is a hidden field on a real form: invisible to humans through CSS, but present in the HTML, so a bot that fills every field fills it too. Any submission with that field populated is a bot. Drop it, flag the IP and device, and block them elsewhere on the site.
Put one on every form that matters: signup, login, contact, checkout.
3. Use a CAPTCHA, selectively
A CAPTCHA (Completely Automated Public Turing test to tell Computers and Humans Apart) sets a challenge a person can pass and a script cannot. Distorted-text versions are hard for people with visual impairments. Image-based versions (find the cat in the photo) are easier on humans, and invisible versions score behaviour and ask nothing unless the score is bad. Use the last kind, and show a challenge only on risky sessions.
Alongside it, block outdated user agents. Bots often announce themselves as browsers nobody runs any more; real browsers update themselves, so a request claiming to be a years-old version is worth a challenge or a refusal. This will not stop a bot that spoofs a current browser, but it removes the lazy ones cheaply.
4. Stop relying on IP blocks for dynamic addresses
Attackers run through dynamic and residential addresses that change by the hour, assigned by ISPs to ordinary households. Block one and the next request comes from a different one; block the range and you lock out real customers on the same ISP.
A static address can be blocked and stay blocked. For everything else the control has to look past the IP: a firewall or detection layer that recognises an automated session by its device fingerprint and behaviour, whatever address it arrives from.
5. Web application firewall
A Web Application Firewall (WAF) filters requests before they reach the application. It blocks injection attacks (SQL injection, cross-site scripting) and the obvious bot patterns, such as repeated failed logins from one source, and it lets you write rules that allow or refuse traffic by path, header, geography and rate. It is perimeter defence; pair it with the session-level detection in steps 2 to 4 for the bots that get past the perimeter.
6. Rate limit
A rate limit caps how many requests one source can make in a window, so a bot cannot fire a thousand login attempts or ten thousand page loads in a minute.
Bot attacks spread across many IPs to stay under per-IP limits, so limit on more than the address: per device fingerprint, per account, per session and per endpoint, with tighter limits on login, signup and checkout than on the home page.
Where to start
Pull a week of server logs and sort requests by user agent and IP. The bots will be visible in an hour. Then add the honeypot field to your forms and a per-endpoint rate limit on login and signup; those two take an afternoon and cut the volume before you spend on anything else.
For the bots that pass those, Sensfrx bot fraud prevention scores each session from device, network and behaviour signals, and your rules decide whether to allow, review or block.
Measure after each step: bot share of traffic, form spam count, failed-login rate. If a number does not move, the control is in the wrong place.