Every WordPress site on the internet receives automated login attempts. Most of that traffic is noise, but the account it is aiming at can install code, so the noise deserves a response.
In order of usefulness
Two-factor authentication on every administrator. This ends credential-stuffing as a threat to your site. Nothing else on this list comes close.
Unique, long, managed passwords. A password manager makes reuse impossible, which is the actual failure mode.
Fewer administrators. Most people who have the role do not need it.
Rate limiting on login attempts. Either at the host or CDN level, or with a plugin — and remember that the plugin itself is code that writes attacker-supplied strings to your database, which is exactly how the Loginizer vulnerability happened.
IP restriction on wp-login.php. Excellent where your team is small and static; unworkable otherwise.
Things that help less than people think
Renaming the login URL. Obscurity, not security. It reduces log noise; it does not stop a targeted attempt.
Hiding the WordPress version. Attack tools do not check first, they just try.
Blocking countries. Trivially bypassed, and it will eventually block you.
Session hygiene
Log out when you finish administering. Do not stay signed in in the browser you use for everything else — that is the delivery mechanism for both CSRF and admin-targeted XSS. A separate browser profile for admin work costs nothing.
Hardening reduces the damage. Patching removes the hole. Scan your site free to see what still needs patching.
