wp-login.php is the most attacked URL on the internet. Brute force bots hammer it 24/7 and most WordPress hosts do nothing about it. Here's why it matters and how to actually fix it.
The moment you launch a WordPress site, bots start probing it. Not eventually - within minutes. The primary target is always the same: /wp-login.php.
These aren't targeted attacks on your site specifically. They're automated credential-stuffing campaigns running against every reachable WordPress install on the internet, around the clock. They try combinations of common usernames (admin, administrator, your domain name) against lists of leaked passwords. They try thousands of combinations per hour.
Most of the time, they fail. But "most of the time" is cold comfort when:
The common advice - use a strong password, add two-factor authentication, install a security plugin - is all reasonable but misses the point. The problem isn't that attackers might guess your password. The problem is that they can try.
Two-factor authentication adds a step after the password check, but the login form is still fully accessible. Security plugins like Wordfence add rate-limiting and IP blocking, but they run inside PHP - they only kick in after WordPress has already loaded and consumed resources.
The right solution sits in front of PHP entirely, at the web server level, before WordPress even starts loading.
There are a few ways to properly lock down wp-login.php, ranging from simple to comprehensive:
At the web server level, you can limit how many login requests a single IP address can make per minute. A legitimate user might hit the login page a handful of times. A brute force bot hits it thousands of times. Rate limiting kills that traffic before it ever reaches PHP, at essentially zero CPU cost.
A well-configured Nginx rule limiting login attempts to 10 requests per minute with a burst allowance of 20 eliminates essentially all automated attacks while being completely invisible to legitimate users.
If you have a static IP (or are comfortable with a VPN), blocking wp-login.php to everyone except your own IP address is the most thorough option. No bot anywhere in the world can reach the login page. The tradeoff is inconvenience if your IP changes or you need to log in from somewhere new.
This is the approach we use at DownUnder WP. Rather than exposing wp-login.php to the public internet at all, access to wp-admin requires a valid session from your hosting control panel. The WordPress login page simply doesn't exist as a public URL - the Nginx configuration blocks direct access entirely.
When you click "WP Admin" in your dashboard, your control panel issues a short-lived signed token and redirects your browser directly to wp-admin. The authentication already happened at the portal level. No login form, no brute force surface, no attack vector.
For site owners who need editors, clients, or WooCommerce customers to log in directly, this protection can be disabled per-site - but the rate limiting stays on regardless.
This isn't just a security issue. Every login request that hits a poorly protected WordPress site triggers a full PHP-FPM worker: loading WordPress, connecting to the database, processing the request. On a busy day, bot traffic against wp-login.php can consume more server resources than your actual visitors.
Hosting on a server with proper login protection isn't just about keeping attackers out - it's about making sure your legitimate traffic actually gets served.
Ask your hosting provider whether wp-login.php rate limiting is applied at the Nginx or Apache level (not the PHP/WordPress level). If they can't answer that clearly, or if the answer is "we recommend installing Wordfence," that's a sign the protection is inadequate.
You can also check yourself: open a private browsing window and rapidly refresh your WordPress login page 20 or 30 times in quick succession. If you don't get rate-limited, neither do the bots.
At DownUnder WP, wp-admin SSO is on by default for every site, and Nginx rate limiting is baked into every container's configuration regardless of SSO setting. It's one of those things that should just be handled at the infrastructure level so you never have to think about it.
Australian WordPress hosting from $5/month
Your own containerised environment on Australian NVMe servers. Simple, fast, and genuinely cheap.