If you want to set up WordPress limit login attempts, the first thing to know is that WordPress does not do this by default. A standard WordPress site lets someone keep trying passwords until another security layer stops them.
Use a reliable security plugin, good firewall, or dedicated login-limit plugin for most WordPress sites.Use no-plugin methods only if you can maintain server rules or custom code, because bad lockout logic can block real users.
Limiting login attempts is useful because it slows brute force attacks and credential stuffing. It makes repeated password guesses expensive and gives you logs that show when someone is trying to break into the site.
But it is not a complete security plan. It protects one entry point. You still need strong passwords, two-factor authentication where possible, updates, backups, malware scanning, a firewall, and login security measures such as bot protection, CAPTCHA, login monitoring, and IP blocking. The right goal is not to make the login page impossible to use. The goal is to slow attackers without making normal admin work painful.
Does WordPress limit login attempts by default?
No. WordPress core does not include a built-in failed-login lockout setting.
On a fresh WordPress test site, there was no login-limiting plugin active at baseline. After installing Limit Login Attempts Reloaded 3.3.4, the behavior changed. A wrong password for the admin user returned the normal WordPress message, ERROR: Incorrect username or password., and the limiter added 3 attempts remaining.
A second wrong password returned the same WordPress error and then showed 2 attempts remaining. The plugin dashboard later showed 2 failed login attempts (past 24 hrs).
That test shows the practical difference. WordPress still handles the login form, but the limiter starts counting failures and warning the user before a lockout.
What login limits actually do
A login limiter watches failed login attempts and stores a count. It usually tracks the count by IP address, username, or both. When the count reaches the limit, it blocks or delays more attempts for a set time. For example, a site might allow 4 failed attempts and then block new attempts for 20 minutes. A stricter site might allow 2 or 3 attempts and then increase the lockout time if the same person keeps trying.
This helps against two common attack patterns:
- Brute force attacks, where bots try many password combinations against the same login.
- Credential stuffing, where bots try leaked username and password pairs from other breaches.
It can also reduce server load. Login requests are not free, and a large stream of bad attempts can make a small site slower.
The limit should not reveal too much. A good tool should keep WordPress’s generic error message and avoid confirming whether the username is real. In our test, the failed login still said ERROR: Incorrect username or password., which is the safer kind of message. The attempt counter appeared separately.
The best method for most sites
Most site owners should use a maintained security plugin, firewall plugin, or dedicated login-limit plugin. This is the safest route because login limiting has more edge cases than it appears to have. A good plugin should let you set:
- number of failed attempts before lockout
- lockout duration
- longer lockouts after repeated failures
- logging
- email notifications
- safelist and denylist rules
- real visitor IP detection for CDN or proxy setups
- coverage for XML-RPC, WooCommerce login, and custom login forms when relevant
You do not need every feature on every site. A small brochure site with one admin account needs less than a membership site or WooCommerce store with many customer logins. But you do need the login limiter to understand the actual places where people can authenticate.
Recommended settings
For most WordPress sites, start with 3 to 5 failed attempts and a first lockout of 15 to 30 minutes.
That range gives real users room for normal mistakes while stopping bots from trying hundreds of guesses in one session.
Use stricter settings for higher-risk sites. A WooCommerce store, membership site, LMS, or site with many privileged users may need 2 to 3 attempts, progressive lockouts, and two-factor authentication for administrators.
Do not make the first lockout too aggressive unless you know your users can recover. A 24-hour lockout after one typo sounds secure, but it can create support problems. It can also become a denial-of-service problem if an attacker intentionally triggers lockouts for real usernames. A practical starting setup looks like this:
| Setting | Good starting point | Why it works |
|---|---|---|
| Failed attempts | 3 to 5 | Allows normal mistakes but stops repeated guessing |
| First lockout | 15 to 30 minutes | Long enough to slow bots, short enough for recovery |
| Extended lockout | after repeated lockouts | Useful for persistent attacks |
| Notifications | summary or important events only | Avoids constant email noise |
| Logs | enabled | Lets you confirm the control is working |
Review these settings after a few days. If logs show constant bot traffic but no real-user lockouts, you can make the rules stricter. If customers, editors, or clients keep getting blocked, loosen the rule or improve recovery.
How to set up login limits with a plugin
The exact screens vary by plugin, but the safe setup process is the same.
- First, install one maintained login limiter or security plugin. Do not stack several plugins that all control failed logins. Duplicate controls can create confusing lockouts and recovery problems.
- Next, set the allowed retries and lockout duration. Start with the 3 to 5 attempt range unless the site has a reason to be stricter.
- Then check which login routes are protected. The normal WordPress login page is only one route. Depending on the site, you may also need protection for XML-RPC, WooCommerce customer login, custom login forms, registration forms, or a membership plugin login.
- After that, review the IP settings. This matters if the site is behind Cloudflare, Sucuri, NGINX, a load balancer, or any reverse proxy. If the plugin sees every request as coming from the proxy instead of the real visitor, one lockout can affect many people.
- Finally, test before you trust it. Use a staging site if possible. If you test on a live site, keep a second admin session open and avoid testing from the only network you can use. Submit one or two wrong passwords and confirm that the login page shows a remaining-attempts message or a clear lockout warning. Then confirm the failed attempts appear in the logs.
In our test, the limiter showed 3 attempts remaining after the first wrong password and 2 attempts remaining after the second. The dashboard later showed 2 failed login attempts (past 24 hrs). That is the type of evidence you want before assuming the protection is active.
How to limit WordPress login attempts without a plugin
You can limit WordPress login attempts without a plugin, but it is not the best route for most site owners. The no-plugin options are:
- custom PHP code, preferably in a small site-specific plugin
- server rules in Apache or NGINX
- web application firewall rules at the host, CDN, or security layer
- tools such as Fail2Ban for server administrators
Custom PHP usually hooks into WordPress login behavior. WordPress has a wp_login_failed action that fires after a failed login, and an authenticate filter that can control authentication results. A developer can use those hooks to count failures and block more attempts for a period.
But production-grade code has to do more than increment a number. It needs to identify the visitor correctly, handle proxies, reset counters after successful login, avoid leaking whether a username exists, protect alternate login routes, return safe errors, and give administrators a recovery path. If it stores counters in WordPress transients, it also has to account for the fact that transient expiration is a maximum time, not a guaranteed minimum.
This is why copying a short snippet into functions.php is risky. Theme files can be overwritten during updates. A syntax error can break the site. The snippet may protect only /wp-login.php while leaving XML-RPC or a custom login form exposed.
Server rules can work for narrow cases. On Apache, .htaccess can restrict access to wp-login.php by IP address. That can help on a private admin site with known static IPs. The same approach can also be used to restrict access to the WordPress admin area (wp-admin), adding another layer of protection for administrator accounts. However, both techniques are a poor fit for ecommerce, membership, forums, agencies, remote teams, and any site where legitimate users log in from many locations. They also do not apply the same way on NGINX.
The no-plugin answer is yes, it is possible. The practical answer is that most sites should not make login lockout a custom-code project unless someone is responsible for maintaining it.
What about XML-RPC?
XML-RPC is a separate WordPress endpoint that can accept remote authentication requests. Some brute force traffic targets XML-RPC instead of the normal login page. If your login limiter protects only the visible login form, XML-RPC may still be an open path.
Do not disable XML-RPC casually. Disabling it can break the WordPress mobile app, pingbacks, trackbacks, and some integrations. If you do not use any XML-RPC-dependent feature, disabling it may reduce the attack surface. If you do use those workflows, choose a plugin or firewall that can protect XML-RPC without breaking the legitimate use case.
This is one of the reasons plugin and firewall coverage matters. The login page is only the route you can see.
CAPTCHA, 2FA, and hiding the login URL are not the same thing
CAPTCHA, 2FA, and WordPress login URL changes can all reduce login risk, but they do different jobs.
CAPTCHA adds a challenge before or during login. It can reduce automated attempts, but it adds friction for real users and is not the same as rate limiting.
Two-factor authentication protects accounts even when a password is known. It does not remove the need to rate-limit obvious password guessing, but it reduces the chance that a guessed or reused password becomes a full compromise.
Changing the login URL can reduce low-effort bot noise. It should not be your main defense. Attackers can still find login forms through other routes, plugins, XML-RPC, exposed links, or normal site behavior. Use these controls together when the site needs them. Do not treat any one of them as a replacement for all the others.
Avoid locking out real users
The main downside of login limits is false lockout. This can happen when a real user forgets a password, when a team shares one IP address, or when a CDN or reverse proxy is misconfigured and the plugin sees one proxy IP for everyone.
Before you enable strict rules, decide how recovery will work. Common recovery options include:
- Wait for the lockout to expire
- Use another network or trusted admin IP, if appropriate
- Reset the password through the normal password reset flow
- Disable the plugin folder through FTP, SFTP, or the hosting file manager
- Remove custom code from the site-specific plugin or theme file
- Ask the host to clear a server-level block
Do not test a full lockout unless you know how to regain access to WordPress admin. On the test site, we stopped after two failed attempts because the article needed proof of countdown behavior and log recording, not a full lockout that could interfere with later work.
Safelist only stable, correctly detected admin IPs. Broad safelists create blind spots.
Where MalCare fits
If you only need configurable failed-login lockouts, a dedicated login-limiter can be enough. If you want login protection as part of broader WordPress security, a security suite is a better fit.
MalCare’s firewall is built for WordPress and can block malicious attacks before they reach the site. Its login protection includes CAPTCHA-based limit-login protection after multiple attempts. That matters if you do not want to maintain custom code or combine several small plugins.
The important distinction is this: limiting login attempts is one useful control. MalCare is relevant when the real need is ongoing WordPress security around that control, not just a counter on the login screen.
Quick decision guide
- Use a security suite or firewall if you want login protection plus broader protection from malicious traffic, malware, vulnerabilities, and recurring attacks.
- Use a dedicated login-limit plugin if you only need configurable lockouts, logs, notifications, and coverage for the login routes your site uses.
- Use server rules if the site has a small number of administrators with stable IP addresses and you control the server environment.
- Use custom code only when a developer can build and maintain it, test it on staging, and document how to recover from lockouts.
- Do not use multiple login-limit tools at the same time unless you have a specific reason and you know which one is responsible for each route.
Final checklist
Before you consider the setup done, check these points:
- WordPress login attempts are limited on the normal login page.
- The limit is reasonable for your site type.
- XML-RPC and alternate login forms are either protected or intentionally handled another way.
- CDN, proxy, or load balancer IP detection is correct.
- Failed attempts appear in logs.
- Notifications are useful and not noisy.
- Administrators know the recovery path.
- Strong passwords and 2FA plugins are in place for important accounts.
- Backups, updates, malware scanning, and firewall protection are handled.
The best setup is boring in daily use. Bots are slowed down. Real users can still recover. Administrators can see what happened. And one forgotten password does not turn into a site access problem.
FAQs
The key is to block the IP address at the correct security “layer.” Where you add the block determines what kind of traffic is actually stopped.
A common mistake is blocking an IP in one place and assuming it covers the entire site. For example, the built-in comment block does not stop login attacks or site scraping.
No, the built-in “Disallowed Comment Keys” only stops matching comments from being published. It does not prevent that same IP address from visiting your pages or trying to log in.
Serious threats like login attacks or scraping should be blocked at the firewall or CDN layer. This stops malicious traffic before it can consume your server’s resources.
Manual IP blocking stops being effective when new malicious IPs appear faster than you can add them. At that point, you need an automated firewall that handles blocking for you.
