Most WordPress brute-force traffic does not look dramatic anymore. It looks cheap, patient, and annoying.
You will see a few requests from one IP, then a few more from another, then another batch an hour later from a completely different country. No single source looks impressive. The total pressure still adds up. On busy sites, that is enough to waste PHP workers, destabilize login flows, and create support noise long before anyone says the site is "down."
If you want to protect WordPress login from brute-force attacks, the first thing to accept is that this is no longer just a password problem.
It is a traffic-handling problem.
Why plugin-only login protection stops helping so quickly
I still see people treat brute-force protection as a plugin checkbox. Limit login attempts. Add a CAPTCHA. Maybe change the login URL. Then assume the problem is solved.
That approach helps at the margin. It does not change where the traffic gets handled.
If hostile requests still reach WordPress, your origin is still doing the defensive work. PHP still wakes up. Sessions still get touched. Login code still gets exercised. Logs still fill with noise. The site may remain available, but it is carrying pressure it should never have seen.
One observation from real traffic: most brute-force pressure we see now is not one loud IP slamming wp-login.php all night. It is 30 to 200 cheap hosts taking turns. Each one stays just quiet enough to slip past simplistic lockout logic. That is exactly where plugin-only protection starts losing value.
Why the login page is not the only login surface
When teams talk about brute-force attacks, they usually think only about wp-login.php.
That is incomplete.
The same pressure often spreads across:
wp-login.php/xmlrpc.php- account/login routes on WooCommerce stores
- API-driven login flows on custom setups
That matters because you can "harden the login page" and still leave the rest of the authentication surface noisy.
If the goal is real protection, think in terms of authentication traffic, not a single file path.
What brute-force pressure actually costs
The obvious cost is failed login attempts. The less obvious costs are usually worse:
- PHP workers get tied up on requests that should have died at the edge
- object cache churn increases
- database reads climb for no customer benefit
- login flows feel unstable for real users
- security telemetry gets noisier and harder to trust
For WooCommerce sites, the collateral damage gets more expensive. I have seen stores where the first visible symptom was not "the site is under attack." It was "customers say checkout felt slow for fifteen minutes." The attack was aimed at login paths. The pain showed up somewhere else.
That is what makes brute-force traffic operationally irritating. It degrades systems sideways.
Why blocking everything is not a smart answer either
People often jump from "plugin-only is not enough" to "block aggressively."
That is not a mature posture either.
A login surface is one of the easiest places to create false positives if you overreact. Real users forget passwords. Teams travel. Agencies log in from multiple locations. Store staff use VPNs. Admins test from mobile networks.
So the practical goal is not to blindly block every spike. The goal is to separate clearly hostile automation from legitimate but imperfect human behavior.
That usually means using a mix of:
- rate limiting
- bot detection
- challenge decisions
- path-aware firewall handling
This is one reason the FirePhage Bot Protection page focuses on login abuse and repeated hostile automation instead of pretending every bad request should be hard-blocked immediately.
The case for putting login protection in front of WordPress
If you have to pick one principle that matters most here, it is this:
Protect login traffic before WordPress touches it.
Once hostile traffic reaches origin, your site has already lost part of the fight. You may still block the attempt. You are still spending resources on it.
This is where edge handling changes the economics of the attack. The request can be challenged, rate-limited, or blocked before it becomes PHP work. That changes:
- origin load
- log noise
- operator visibility
- the amount of time you spend guessing whether the site is actually unhealthy
It also lets you respond at the traffic-pattern level instead of playing whack-a-mole with individual IPs.
Why rate limiting still matters even when it is not enough
Here is the honest limitation: rate limiting alone will not stop a distributed brute-force campaign.
It slows it down.
That is still worth doing.
A lot of security advice gets worse because people only recommend controls that sound complete. Real protection stacks are usually partial by design. One control narrows the problem. Another control catches what the first one missed.
For login abuse, rate limiting is useful because it:
- raises the cost of repetition
- reduces burst pressure
- makes one source less effective
- buys time for broader bot handling to work
What it does not do is magically solve distributed pressure from many sources. If 80 hosts take turns, a narrow rate-limit rule will not carry the whole job by itself.
Use it anyway. Just do not lie to yourself about what it is doing.
What site owners should review first
If I were checking a WordPress site that keeps attracting login abuse, I would review these questions first:
Do we actually know which paths are taking the pressure?
If the answer is "we just know login attempts are happening," visibility is too vague.
You want to know whether the pressure is landing on:
wp-login.php- XML-RPC
- WooCommerce account paths
- custom auth routes
Are we challenging or blocking before origin?
If the requests still show up as regular origin work, then the control point is too late.
Are we treating it as bot pressure or just failed logins?
That distinction matters. Failed logins are the symptom. Hostile automation is the pattern.
Is the site carrying too much local defensive logic?
Sometimes the plugin stack becomes a pile of overlapping fixes: one login-lockout plugin, one CAPTCHA plugin, one security suite, plus host-level rules. The result is not stronger control. It is confusion.
I would rather have fewer controls, placed earlier.
WooCommerce makes this more urgent
On brochure sites, brute-force traffic is mostly an origin and operations problem.
On stores, it becomes a customer-experience problem much faster.
Why? Because stores already have sensitive moving parts:
- logins
- sessions
- carts
- account pages
- checkout flows
When bot pressure hits authentication routes, the store does not have much spare patience. The effect can spill into slower account access, unstable sessions, and wasted capacity during periods that should be dedicated to actual buyers.
This is another reason I do not like the "just install a login plugin" answer. That answer ignores what kind of site is being protected.
The better question to ask
Do not ask, "How do I stop failed logins?"
Ask, "How do I stop hostile authentication traffic from becoming WordPress work?"
That question leads to better decisions.
It pushes you toward:
- edge-side filtering
- rate limits with realistic expectations
- bot-aware challenge decisions
- visibility that shows pressure early
- fewer local bandaids doing too much
That is a much healthier operating model than waiting until the login screen becomes the visible part of a broader origin problem.
Protect the authentication surface before WordPress touches it, or you will keep paying for requests you never wanted.