Almost none of those attempts are aimed at you. They are automated programs working through lists of usernames and passwords, hitting every WordPress site they can find at the same two web addresses. A site with three visitors a day and a site with three thousand get the same treatment.
Who is actually knocking
WordPress.org says it plainly on a page in its Advanced Administration Handbook called Brute Force Attacks. A brute force attack is “an attacker repeatedly tries username/password combinations until one works.” That page was first published March 28, 2023 and last updated February 25, 2026.
Nobody is sitting at a keyboard typing those guesses. The same page describes the attempts as “automated and often distributed (botnets)”. A botnet is a network of hacked computers and servers. That is why blocking one address does so little. The next guess arrives from a different machine.
Your site is on the list for one dull reason. WordPress puts its login form at /wp-login.php on nearly every install, and leaves a second door at /xmlrpc.php. A program never has to work out where to knock. WordPress.org calls xmlrpc.php “a frequent brute-force target,” and says to disable it if you do not use it.
Why the number gets so big
Failed means failed. A log full of failed attempts is a record of a lock holding, not a record of a break-in.
Volume is easy to misread. The guessing is automated and the log writes a line for every attempt, so one machine working through a list fills a screen fast. Three hundred lines is not three hundred people.
There is a real limit in the evidence here, and it is worth knowing before somebody quotes a scary figure at you. Patchstack publishes a yearly count of WordPress security problems. Its report State of WordPress Security in 2026 is marked “Data updated 25.02.2026”, which is February 25, 2026, and it covers 2025. It counted 11,334 new vulnerabilities across the WordPress world that year, 91 percent of them in plugins and 9 percent in themes, with 6 in WordPress core. It does not count login attempts at all. No one publishes a trustworthy figure for what is normal on a plumbing company website. If a security plugin or a sales email tells you your number is alarming, ask what it is being compared against.
The cost of the noise usually lands on your server. WordPress.org warns that even unsuccessful attacks “can overwhelm your site with requests.” It also points out that login-limiting plugins “still execute within PHP and thus consume some resources under heavy attack”, so they eat the thing they are defending.
The one number worth writing down
NIST is the federal standards agency. In Special Publication 800-63B, section 3.2.2, Rate Limiting (Throttling), the rule is that a verifier “SHALL limit consecutive failed authentication attempts using a specific authenticator on a single subscriber account to no more than 100 by disabling that authenticator.” The page carries a stamp of August 26, 2025, with no label saying what that date means.
Read the scope before you borrow the number. That document is written for government systems, and it says agencies may set a limit lower than 100. It is not a law your business has to meet, and nothing here is legal advice. If a contract or an insurer holds your company to a security standard, check that against your own state and your own attorney.
One hundred is still a ceiling worth borrowing. If your site logs hundreds of failed attempts against one username and nothing ever switches off, nothing is holding that ceiling. WordPress does not hold it on its own, which is why the WordPress.org page tells you to add throttling at the edge or with a plugin.
You can check the second number just as easily. The example Nginx configuration on that same WordPress.org page limits /wp-login.php and /xmlrpc.php to 10 requests a minute from any one address, with a burst of 20 allowed. Both figures are on public pages you can open yourself.
What actually cuts it down
This is the short version of the WordPress.org list, in the order most local business owners can act on it.
- Use a long, unique password on every account that can log in, kept in a password manager.
- Turn on two-factor authentication for every administrator. WordPress core does not ship it, so this needs a plugin or an outside login provider.
- Use passkeys if your plugin offers them. WordPress.org lists passkeys as its phishing-resistant option.
- Rate-limit the login page at the edge, meaning at your host or content network, so bad traffic stops before it reaches your server.
- Put a challenge on the login form to slow bots down.
- Turn off xmlrpc.php if nothing on your site needs it.
- Stop using the username admin, and delete old accounts nobody uses.
CISA, the federal cyber agency, gave the reason for two-factor in one line in its Multi-Factor Authentication fact sheet, dated January 2022: “Adversaries are increasingly capable of guessing or harvesting passwords to gain illicit access.”
Not every second factor is equal. CISA’s fact sheet Implementing Phishing-Resistant MFA, dated October 2022, lists the forms “from strongest to weakest” in a table. At the top sits phishing-resistant login. CISA writes: “The only widely available phishing-resistant authentication is FIDO/WebAuthn authentication.” That is what a passkey or a plug-in security key uses. A code from an app or a hardware token sits in the middle, and CISA calls those “the best options for small- and medium-size business that cannot immediately implement phishing-resistant MFA”. A code by text or voice sits last, and CISA says it “should only be used as a last resort MFA option.” CISA’s Cyber Guidance for Small Businesses, a page that says it was updated in April 2024, adds the practical version: “Any form of MFA is better than no MFA.”
Two things are not on the list. Hiding the login page is one. WordPress.org says obscuring the login URL “can reduce noise but should not be your only defense.” Permanent country blocklists are the other. WordPress.org says to avoid them, since they “can block legitimate users and are difficult to maintain.”
When to spend nothing
If every admin account already has a long, unique password, two-factor is on, and there is no user called admin, then failed login attempts are noise. Switch off the email alerts and get back to work. You do not need to buy a plugin, a service, or a rebuild.
Failed logins alone are not a reason to replace a website either. That is a bigger decision built on age, cost, and how much of the site still works, which is a separate question worth answering on its own terms. Keeping core, plugins, and themes current is on the WordPress list above, and whether to let those updates run overnight is its own argument.
Here is the honest version of what a rebuild changes. A site built as plain files has no login form and no database sitting on the public web. Bots still knock at /wp-login.php. Nothing there answers, and there is nothing there to guess. It does nothing for your email password, your Google account, or your hosting account, and those are still worth locking down properly.
What to do next
Work down this list in order. Most of it takes an afternoon.
- Log in and look at the user list. Delete anyone who no longer works for you, and change the role of anyone who does not need to be an administrator.
- If a user is named admin, make a new administrator with a different name, log in as that one, and remove the old account.
- Set a long, unique password on every remaining account. Use a password manager so nobody has to memorize it.
- Turn on two-factor authentication for administrators. A code from an app beats a code by text, and a passkey beats both.
- Call your host and ask one question: do you rate-limit wp-login.php before it reaches my site. If the answer is no, ask what they offer.
- Check whether anything on your site uses xmlrpc.php. If nothing does, ask your host or developer to turn it off.
Then stop watching the counter. The number of failed attempts is not a measurement of your risk. Whether the door holds is, and the steps above are what decide that.