Your /wp-admin Is a Target: Locking Down the Login Page

Check your server logs tonight and you'll find them: requests to wp-login.php from IP addresses around the world, arriving at all hours, on a store nobody is attacking specifically. Every public WordPress login page gets this treatment — automated, indiscriminate, and relentless. The fix isn't one setting; it's a few thin layers that together make the door not worth pushing on.

Understand what's knocking

These bots rarely guess randomly. They replay username and password pairs leaked from breaches of other services, betting that someone on your team reused a password. That's why a single strong, unique password plus two-factor authentication defeats the majority of this traffic before any other defense is even needed.

Rate limit the guesses

A limit-login-attempts plugin locks out an address after a few failures — say five attempts, then a 20-minute timeout that stretches with each repeat offense. Botnets rotate addresses to cope, but rate limiting still collapses the practical guess rate from thousands per hour to a comparative trickle, and gives you a log of who's trying.

Allowlist who can even see the page

If your team logs in from fixed locations, a server rule can restrict wp-login.php and the wp-admin directory to specific IP addresses — everyone else gets a flat denial before WordPress even loads. The catch is travel and home connections with changing addresses; a small VPN with a static address solves that for teams who want the strictest option.

Add friction only bots feel

A CAPTCHA or proof-of-work challenge on the login form costs a human two seconds and costs a bot its economics — automated credential replay depends on high volume at zero cost per attempt. Modern challenges are far less annoying than the fire-hydrant photo grids of years past, and login pages are the one place the friction clearly pays for itself.

Move the door, and watch it

Renaming the login path to a custom slug is security by obscurity — worthless alone, genuinely useful as noise reduction, since bots aimed at the default URL hit a 404. What remains in your logs after that is the interesting part: keep failed-login logging on and alert on spikes, because a sudden surge of failures against a real username is often the earliest visible sign that someone is working on your site in particular.

Layers like these fail quietly — a plugin update resets a setting, a rule gets dropped during a migration. Trust Guard's ongoing scans and monitoring verify your defenses are still standing and alert you when something changes, so the login page you locked down stays locked down.