u/Capital_Attention702

This comes up constantly, so I'll write it once.

You rename your login slug, and minutes later you're still seeing failed login attempts. The instinct is "the secret leaked, something's compromised." Almost always, it hasn't.

Two things are usually going on.

1. WordPress has more than one login. /xmlrpc.php exposes a method, wp.getUsersBlogs, that takes a username and password and validates them with no login form involved. system.multicall even lets a bot batch hundreds of guesses into a single request. Renaming /wp-login.php does nothing to that endpoint, so the attempts keep coming and it looks like your new URL got discovered. It didn't. The bot was never using it.
2. If the attempts come from constantly changing IPs, rate limiting and per-IP lockout can't do much. They count failures per address, and a rotating-IP botnet sends each try from a fresh IP, so the counter never trips. You can drop the threshold to 2 and nothing changes.

What actually quiets it down:

• Change the login path at the rewrite layer (nginx/apache config), not just with a slug plugin, so a request to /wp-login.php returns 404 before PHP loads. No process starts, so the rotating IPs stop mattering.
• Disable XML-RPC if nothing you run needs it (Jetpack and some old mobile apps are the exceptions), or at least block the auth methods.

None of this replaces a security plugin for 2FA and monitoring, those still earn their place. It just moves the brute-force defense to a layer the bots can't walk around by swapping an IP or an endpoint.

For those of you who renamed the login and still saw attempts: did you ever check your access log for /xmlrpc.php hits? Curious how often that's the real source versus something else.