Does changing my login URL actually stop brute-force attacks?

It stops the vast majority of automated attacks, which target /wp-login.php by convention. Bots that discover your custom URL through crawling or plugins that expose it can still reach you, so treat it as one layer in a stack rather than a complete solution.

Will login attempt limiting lock out my real users?

Only if they repeatedly enter the wrong password. Set the threshold at 5 attempts over 5 minutes and most legitimate users will never notice it. The lockout duration (30–60 minutes) is the setting that matters more — make it long enough to be painful for bots but not catastrophic for a user who forgot their password.

My host says the attacks are coming from hundreds of different IPs. Can I block them all?

Manually blocking individual IPs is futile against distributed botnets — the list is effectively infinite. Focus instead on server-level rate limiting, blocking wp-login.php by default, and a WAF like Cloudflare that maintains crowd-sourced botnet IP lists automatically.

Is this different from a DDoS attack?

Related but distinct. A brute-force attack specifically targets the login endpoint to gain access. A DDoS floods any URL to overwhelm the server. A heavy brute-force campaign can look like a DDoS in terms of load, but the fix is different — rate-limiting the login endpoint and adding a WAF addresses both simultaneously.

Stop WordPress Brute-Force Attacks Before They Succeed

A brute-force login attack is when automated bots cycle through thousands of username and password combinations against your wp-login.php page until one works. The good news: every effective defence is a configuration change, not a purchase — and you can layer several of them in under an hour. The bad news: most WordPress sites ship with zero of these layers in place.

What You're Seeing (and What's Really Happening)

You might notice this problem in several ways:

Your host emails you about unusually high CPU or bandwidth usage
The WordPress admin feels sluggish or throws a 503 even when you're not doing anything heavy
Your security plugin logs show hundreds of failed login attempts from rotating IP addresses
Server access logs are full of POST /wp-login.php entries from IPs you don't recognise

What's happening under the hood: bots send POST requests to wp-login.php at a rate a human never could — sometimes thousands per hour. Each request burns PHP cycles and database queries. Even a failed login is expensive. On shared hosting, that volume alone can trigger rate limits or bring down the entire site, even though no account has been compromised yet.

There are two broad flavours of attack. A simple brute force tries every possible combination. A credential stuffing attack replays real username/password pairs stolen from data breaches elsewhere. Credential stuffing is harder to block with lockouts alone, because each pair is only tried once or twice before moving on — never tripping a "too many failures" rule.

The Five Layers of a Solid Defence

No single measure stops everything. The goal is to stack cheap, low-friction layers so that breaking through one still leaves four more to defeat.

Layer 1: Rename or Block wp-login.php at the Server Level

This is the highest-leverage change you can make. Bots look for /wp-login.php by convention. If it doesn't respond — or responds with a 403 before PHP even loads — the attack costs you nothing.

If your host uses Apache and you have access to .htaccess, add this block before the WordPress rewrite rules (always back up .htaccess first):

# Block wp-login.php except for your IP
<Files wp-login.php>
  Order Deny,Allow
  Deny from all
  Allow from YOUR.IP.ADDRESS.HERE
</Files>

Replace YOUR.IP.ADDRESS.HERE with your actual IP. If your IP is dynamic, use your ISP's IP range in CIDR notation, or skip the allowlist and rely on the other layers instead — a blanket 403 still stops bots even if it stops you too, which is why Layer 2 matters.

Alternatively, many security plugins (Wordfence, Solid Security, and others) offer a "custom login URL" feature that moves the login endpoint to a path bots don't know. This works well, but document the new URL somewhere safe — losing it locks you out.

Layer 2: Rate-Limit Login Attempts

A lockout after, say, five failed attempts in five minutes stops simple brute force dead. Use a plugin to implement this, or — on Nginx — a server-level rate limit directive. Most quality security plugins include this as a core feature. Set the threshold low (3–5 attempts), the lockout duration long (30–60 minutes), and configure email notifications so you know when it fires.

One important nuance: lock out by IP and by username separately. Locking by username alone lets an attacker lock you out of your own account on purpose (a denial-of-service variant). Locking by IP alone is defeatable with rotating proxies. Both together is much harder to beat.

Layer 3: Enforce Strong Credentials and Change the Default Username

If your admin username is still admin, change it today. That's the username in roughly 60% of credential stuffing lists. You can't rename a user in the WordPress UI directly, but you can: create a new administrator with a different username, log in as that user, then delete the original admin account (assigning its content to the new user).

Pair this with a passphrase of 20+ characters for every admin account, and enable password confirmation on user profile saves so a compromised editor can't quietly escalate privileges.

Layer 4: Add Two-Factor Authentication

Two-factor authentication (2FA) is the single most effective defence against credential stuffing, because a stolen password alone is no longer sufficient. Even if a bot gets the right username and password, it can't produce the time-based one-time code.

Plugins like WP 2FA or the 2FA module built into Wordfence and Solid Security handle this cleanly. Enforce 2FA for all administrator and editor accounts — not just your own. A compromised editor account can still do serious damage.

Layer 5: Use a Web Application Firewall (WAF)

A WAF sitting in front of your site can identify and drop bot traffic before it ever reaches WordPress. Cloudflare's free plan includes bot-fighting rules that significantly reduce brute-force volume. Their "I'm Under Attack" mode is a blunt instrument for genuine emergencies — it adds a JavaScript challenge to every visitor — but their finer-grained WAF rules and rate-limiting are the better long-term choice.

Host-level WAFs (common on managed WordPress hosts like WP Engine, Kinsta, or Pressable) operate at the server before PHP runs, which is the most efficient place to stop the traffic entirely.

What Not to Do

A few "fixes" circulate online that cause more problems than they solve:

Deleting wp-login.php entirely. WordPress will recreate it on the next update, and in the meantime you're locked out.
Setting wp-login.php to 000 permissions. This breaks your own login and is only a temporary measure at best.
Blocking entire countries via IP. Bots use VPNs and exit nodes in every country. You'll block legitimate visitors while doing little to stop determined attackers.
Relying on CAPTCHA alone. Modern bots solve audio CAPTCHAs or use CAPTCHA farms. It raises the cost slightly, but it's not a wall.

A Practical Implementation Order

Back up your site before touching any configuration file or access control setting.
Install a reputable security plugin and enable login attempt limiting immediately — this is the fastest win.
Change the admin username if it's still admin.
Enable 2FA for all admin accounts.
Add server-level protection for wp-login.php (IP allowlist or custom login URL).
Point your DNS through Cloudflare (or confirm your managed host's WAF is active).
Review your security plugin logs a week later and tune the lockout thresholds based on what you actually see.

How to Spot a Successful Intrusion Early

Even with all five layers, you want detection in place in case something slips through — especially credential stuffing, which is designed to evade lockout rules.

Turn on email alerts for new admin account creation. Any security plugin worth using offers this.
Check the Users list in WordPress Admin periodically for accounts you don't recognise.
Monitor for unexpected administrator role changes on existing accounts.
Enable activity logging (Wordfence, WP Activity Log, or similar) so you have a timestamped record if you ever need to investigate.

If you suspect an account has already been compromised, reset all admin passwords immediately, revoke all active sessions (the "Log Out Everywhere Else" link in your profile, or a plugin that clears all auth cookies), and audit recently modified files. For a deeper forensic walkthrough, see the WordPress site hacked cleanup guide.

Preventing the Next Attack

Brute-force protection isn't set-and-forget. Rotate admin passwords every six to twelve months. Review your lockout logs quarterly — a spike often signals a new campaign targeting your niche or platform. Keep WordPress core, themes, and plugins updated, because attackers sometimes combine a known vulnerability with credential attacks to escalate access once they're in. For a structured approach to keeping all of this maintained, the WordPress maintenance routine that prevents emergencies lays out a practical calendar.

When to Call a Professional

If your site is actively under heavy attack — admin is unreachable, the server is throwing 503s, or you suspect an account has already been taken over — this is no longer a "configure a plugin" situation. You need someone who can act at the server level, assess whether a breach has already occurred, and restore normal service without locking out legitimate users in the process.

That's exactly the kind of situation Mend's Emergency Rescue is built for. Senior engineers triage, lock down, and clean up — most fixes the same day — with a full plain-English report of what happened and what changed. If you're not sure how serious it is, a free Diagnosis triages the situation first and quotes a flat price before any work starts. No card required.

For ongoing peace of mind, the Mend Care Plan includes managed updates, security monitoring, and regular backups — so the next wave of bots hits a hardened target instead of an unattended one.