A small tourism website went down in the middle of an ordinary week. No new plugin, no update, nobody editing anything. The host just started returning errors to everyone.
The logs showed one page being requested over and over: a listing page with filters, where every combination of options gets its own web address. Something was working through those combinations faster than any person could click.
So we blocked that page for anything that wasn't behaving like a person, and the site came right back up.
The next day it moved
Same flood, same speed, different page: another filtered listing one link away from the first. We blocked that one too, and it moved again.
That went on for about a week at roughly fifteen times the site's normal traffic. The volume wasn't the hard part. The source was: thousands of different addresses from all over, and almost none of them showed up twice. There was no single bad visitor to ban, because every request came from a new one.
That's what a botnet looks like from the receiving end. It's a pool of other people's hacked routers, cameras, and cheap servers, rented out by the hour, and the point of spreading a crawl across thousands of machines is that no single address ever looks like an attack. Each one asks for a page or two and leaves.
Blocking pages was the wrong target
Every block we put up named a place. This page, then that page. Switching pages costs an attacker nothing.
What stayed the same was how the traffic behaved. Requests every fraction of a second, marching through filter combinations in order, never loading an image or stylesheet, never holding a session, never pausing to read. A real person browsing a tourism site clicks, waits, reads, and loads a dozen other files along the way.
Once the rule described that behavior, it stopped mattering which page they picked next.
The analytics looked great
This part bothered me more than the outage.
For that week, the site's analytics looked fantastic. Traffic way up, thousands of new visitors, lots of pages per visit. Anyone glancing at the dashboard would have thought the marketing had finally landed.
Analytics mostly counts things that behave like browsers, and enough of that flood did. The number on the chart was real and meant nothing. A spike with no calls, bookings, or emails behind it is something to investigate before you report it.
It also wasn't personal. Nobody picked this town. Something was scraping listings at scale, and this site happened to have a lot of them in a convenient shape. Being small doesn't keep you off the list.
If your site has filters, search, or a calendar
Anything where one page can be requested a million slightly different ways is exposed to this. Three things are worth an hour of someone's time:
- Block on behavior, not on pages or addresses. A per-address rate limit won't catch a crawl that uses each address once or twice. What catches it is the pattern: no images or stylesheets loaded, no cookies or session, sequential walks through URL parameters, and timing no person could manage. Bot filtering at the CDN level works from signals like these.
- Ask your host what they already have. Many hosting plans and most major CDNs include bot filtering that's turned off or set to its gentlest level. It's often a single toggle.
- Sanity-check a traffic spike before you celebrate it. Did anything happen because of it, like a call, a form, or a sale? If the graph went up and the phone didn't ring, look at where the traffic came from before you share the good news.
The site's fine now, and it gets less traffic than it did during the attack, which is how it should be.