Most WordPress security plugins handle bad bot traffic the same way: detect it, then slam the door with a 403 Forbidden.
That feels like the right move, but it has two problems.
It tells the bot operator they’ve been caught. A 403 is an unambiguous signal — “this fingerprint is blocked.” A scraper running at any scale reacts to that signal: rotate the User-Agent, rotate the IP, try again. The block becomes a game of whack-a-mole instead of a fix.
It still costs you. Even a 403 response means WordPress spun up, ran through enough of its bootstrap to generate that response, and returned it. At low volume that’s noise. At six-figure-request volume — which is the traffic pattern that started this whole investigation — that’s real server time spent on requests you never wanted in the first place.
The alternative worth trying: don’t signal anything. Serve a normal 200 OK with a plain, harmless-looking page instead of an error, and do it before WordPress finishes loading — no theme render, no database query, nothing for the bot to learn from and adapt to.
That’s the core idea behind Lubber: recognize the traffic that shouldn’t be there, and give it nothing to react to.
More on the specific detection signals that turned out to be reliable — and the ones that looked promising but weren’t — in future posts.