limit WordPress login attempts
Why reduce login attempts right now (and not when we have time)
If your site receives dozens (or thousands) of failed login attempts, it’s usually not a bug or a sudden spike in interest: it’s often an automated brute-force attack that repeatedly tests common credentials. The problem isn’t only the risk of compromising the administrator account. By relentlessly hammering wp-login.php and xmlrpc.php, these bots consume server resources, can slow down the site, cause 5xx errors, or even trigger blocks from the host (CPU/IO). Result: loss of availability, degraded user experience, and sometimes a drop in SEO performance if the site becomes unstable.
The goal is therefore twofold: (1) make it much harder to take over an account, and (2) reduce the attack surface and the load generated by these attempts. To achieve this, the most effective strategy combines limiting the number of attempts, hardening accounts, and network rules (firewall, blocks, whitelists).
Implementing an attempt limit: the essential anti-brute-force layer
The simplest and most cost-effective measure is to limit the number of failures allowed over a given period, then impose a lockout time (temporary or progressive). Concretely, instead of letting a bot try 1000 passwords, you stop it after 3 to 10 attempts and put it in timeout for 15 minutes, 1 hour, or even 24 hours if the failures repeat.
This approach doesn’t prevent a very determined attacker from trying again over a long period, but it makes the attack slow, costly, and often pointless. It also protects your server resources by breaking the pace of malicious requests.
Choose a dedicated plugin (simple, effective, traceable)
On WordPress, the most common option is to install a plugin that manages: the failure counter, lockout, lockout duration, notifications, and sometimes an IP whitelist. A widely used reference is Limit Login Attempts Reloaded – login security …. It generally allows you to set an attempt threshold, apply progressive lockouts, and have visibility into blocked IPs.
Before enabling such a plugin on a production site (especially if you have a team, access via VPN, or logins from multiple locations), test the configuration to avoid locking yourself out. A bad policy can penalize legitimate users (mistyped password, QWERTY/AZERTY keyboard, browser auto-filling an old password, etc.).
Test the configuration without shooting yourself in the foot
The golden rule: test in a staging environment if possible, and always have a fallback plan (FTP/SSH access, or an alternative administrator account). If you need a rigorous method, use a validation process before going live, as described here: validate a plugin under real-world conditions. This helps you check real cases: input errors, mobile logins, changing IPs, and interactions with a cache or a firewall.
Discover our offers for WordPress website maintenance
Recommended settings: a balance between security and usability
There is no universal setting, but here is a pragmatic baseline that suits many sites:
• 5 attempts maximum within 5 to 15 minutes
• Lockout for 15 to 60 minutes after exceeding the limit
• Longer lockout (6 to 24h) after several cycles of exceeding the limit
• Logging of IPs and attempted usernames (if available)
• Email notifications only at high thresholds (to avoid spam)
If your site has a significant number of contributors (editors, authors), be a bit more flexible on the threshold, but compensate with strong authentication (see the 2FA section below). If your back office is used only by 1 to 3 people, you can be stricter.
Harden access: reduce entry points, not just count failures
Limiting attempts is essential, but it’s only one layer. To truly reduce risk, you also need to decrease the likelihood that a bot reaches an exploitable login page and can guess a plausible username/password.
Change dangerous habits: admin username, weak passwords, forgotten accounts
Many attacks succeed not because of sophisticated techniques, but because the basics are neglected. Check:
• No administrator account with an obvious username (admin, webmaster, test, demo).
• Long (at least 14–16 characters) and unique passwords.
• Deletion or demotion of accounts that no longer need access.
• Review roles (an editor doesn’t need to be an administrator).
At this stage, limiting attempts becomes truly effective: even if a bot is slowed down, it won’t stumble upon the right password by chance.
Enable two-factor authentication (2FA)
2FA adds an extra step (authenticator app, hardware key, email, etc.). Even if a password leaks, the attacker remains blocked. On a professional site, it’s a very cost-effective measure. Ideally, enforce it for administrators and editors, and leave it optional for less sensitive roles.
Protect the login URL and exposed interfaces (wp-login, XML-RPC, REST)
Bots often target /wp-login.php and /xmlrpc.php. Depending on your usage, you can reduce the attack surface.
Hide or move access to the form
Moving the login URL (or adding a validation step) can reduce noise, since many bots only try the default paths. This does not replace real security, but it reduces mass automated attempts. Note: this can impact some tools (apps, integrations) and must be documented for the team.
Disable XML-RPC if you don’t use it
XML-RPC is used for certain integrations (mobile apps, Jetpack, remote publishing). If you don’t need it, disabling it can remove an attack vector and reduce indirect login attempts. If you do need it, protect it via firewall (WAF) and rate-limiting rules.
Set up an application firewall (WAF) and network rules: the layer that takes the load off the server
A WAF (at the plugin, CDN, or host level) filters some requests before they consume too many WordPress/PHP resources. This is particularly useful when attacks are high-volume. A good WAF can:
• Block countries or IP ranges (if relevant to your business).
• Detect bot patterns and challenge them (JS challenge, captcha).
• Apply rate limits (rate limiting) on wp-login.php.
• Block suspicious user agents or abnormal requests.
To combine with limiting attempts: the WAF reduces harmful traffic, and the plugin handles what still gets through.
Monitor and interpret logs: act on facts, not impressions
To improve protection sustainably, you need to look at the signals: which IPs come back, which usernames are being tested, at what times, via which endpoints. If you find that 95% of attempts come from a handful of addresses, network blocking becomes very cost-effective. If, on the other hand, it’s very distributed, a WAF and rate-limiting rules are more appropriate.
A useful resource to understand common approaches and possible options is Limit login attempts on WordPress, which details different ways to manage these protections day to day.
Avoid side effects: cache, proxy, VPN, shared IPs
IP limiting can have undesirable effects:
• In a company, several people may share a public IP: a user who makes a mistake can block everyone.
• With a VPN, the IP can change often or be shared.
• Behind certain proxies/CDNs, the IP seen by WordPress is not the right one if the client header is not correctly forwarded.
To avoid these pitfalls: correctly configure trusted IPs (reverse proxy), use whitelists with caution, and favor 2FA to secure without penalizing the team. And above all, document the unblocking procedures (who can unblock, how, in how much time).
Discover our offers for WordPress website maintenance
Think maintenance: login security also depends on the rest of the site
Limiting attempts is an excellent start, but security quickly degrades if WordPress, themes, and plugins are not maintained. A vulnerability in a plugin can bypass login protections or create a new entry point (upload, injection, accounts created on the fly, etc.).
Beyond the risk of hacking, an unmaintained site can also suffer in terms of performance and visibility. To understand the overall impact, see the consequences of an unmaintained site on SEO.
Update without breaking: theme, plugins, compatibility
Security updates are essential, but they must be handled properly. A poorly designed or overly locked-down theme can make updates risky, and push you to postpone fixes. If you’re unsure about the long-term strategy, this comparison helps frame the issues: how to choose between a custom design and a premium solution.
Plan for incidents: when too many blocks end up blocking you
Hardening login should always plan for a worst-day scenario: you (or a client) are blocked, the site is under attack, and you need to regain control quickly. A few reflexes:
• Have an alternative admin access (secure secondary account) or server access (SFTP/SSH).
• Know how to disable a security plugin via the directory wp-content/plugins if necessary.
• Working (and tested) backups to roll back if a change has a domino effect.
And if, during an intervention, you run into a critical failure (white screen, errors), the problem can sometimes be deeper than a simple lockout. For example, a storage-related error can prevent any connection to the back office. Keep a clear procedure on hand like this database troubleshooting guide to restore access without improvising.
Anti-noise best practices to drastically reduce attacks
In addition, certain measures reduce the volume of attempts, even if not all of them are essential:
• Disable indexing of unnecessary login pages and avoid exposing clues about accounts.
• Rename the public displayed user (author) if it reveals the login identifier.
• Set up security headers and harden file permissions.
• Install an intrusion detection system (depending on your maturity level) and receive alerts about important events.
Which combination should you choose depending on your site type?
Showcase site (1–2 admins)
Strict rate limiting (few attempts), mandatory 2FA, WAF/anti-bot, regular updates. Whitelisting possible if you have fixed IPs.
Editorial site (multiple authors)
Moderate rate limiting, 2FA at least for admins/editors, log monitoring, internal unblocking procedures.
E-commerce / high-value site
Rate limiting + WAF + 2FA, advanced network rules, monitoring, endpoint hardening, and a strict maintenance policy (testing, preprod, rollback).
Make protection last: costs, risks, and organization
What most often fails is not the technology, it’s continuity: plugin not updated, forgotten settings, accounts kept just in case, ignored alerts. Login security must be integrated into a maintenance cycle with regular reviews (accounts, roles, logs, updates, backups).
To realistically arbitrate between time invested and possible impacts, this content helps frame the topic: assess the balance between budget and risks.
Conclusion: effective protection is a layered strategy
To truly reduce login attacks, don’t settle for a single setting. Combine an attempt limiter (with reasonable thresholds), strong authentication (2FA), account hardening (usernames and roles), and network protection (WAF/rate limiting) when the volume justifies it. Add to that regular maintenance, pre-deployment testing, and a backup plan, and you turn a fragile entry point into a well-controlled area.
If you prefer to delegate the setup, monitoring, and adjustments (alerts, updates, checks, incident response), you can see the maintenance solutions offered.
