Stopping Brute Force Logins on a WordPress Guild Site

The first time I opened the access log of a small guild site I help run, I counted 4,200 requests to wp-login.php in a single night. The guild had 31 members. None of them were awake at 3 a.m. trying the username "admin" with the password "123456". That was a bot, or more accurately several hundred of them, working through a list of leaked passwords against every WordPress install they could find.

Brute force logins are the most common attack a WordPress guild site will ever see, and the good news is that they are also among the easiest to shut down. You do not need a paid security suite or a server admin. You need about an hour, a clear order of steps, and a willingness to ignore a couple of popular tips that do less than they promise.

What Brute Force Logins Actually Cost a Small WordPress Site

Most guild admins assume the risk is only a stolen password. That is the worst outcome, but not the most frequent one. The everyday damage is quieter.

• Server load. Every login attempt runs PHP and queries the database. On cheap shared hosting, a few thousand attempts an hour can slow raid sign-up pages to a crawl right when members need them.
• Host suspensions. Some budget hosts throttle or suspend accounts that burn too much CPU, even when the traffic is not your fault.
• Locked-out officers. Clumsy lockout plugins can block your own moderators if they share an IP address at a LAN event or on the same mobile network.

So the goal is twofold: make the attempts fail, and make them cheap to reject.

Step One: Fix the Accounts Before the Login Page

Bots succeed because somebody on the team uses a weak or reused password. Start with people, not plugins.

1. Go to Users and check for any account named admin, administrator or the site name. Create a new administrator with a different name, log in with it, and delete the old one, assigning its posts to the new account.
2. Count your administrators. A guild site rarely needs more than two. Officers who post news only need the Editor role, and event organisers can usually work as Authors. Our guide to WordPress user roles for a volunteer team explains how to split those duties.
3. Ask every remaining administrator to switch to a password manager and a unique password of at least 16 characters.

Fewer powerful accounts means fewer doors worth forcing.

Step Two: Add Two-Factor Authentication for Staff

Two-factor authentication turns a guessed password into a dead end. Free plugins can add app-based codes for chosen roles. Require it for administrators and editors; leave it optional for regular members, or your forum will fill with "I lost my phone" threads.

One practical detail: generate backup codes for each officer and store them somewhere the guild leader controls. When a raid leader replaces their phone mid-season, those codes save you a support evening.

Step Three: Limit Attempts Without Locking Out Your Own Officers

A login limiter blocks an IP address after a set number of failures. The settings matter more than the brand of plugin.

Check whether your site sits behind a proxy or CDN. If it does, the plugin must read the visitor's real IP from the forwarded header, or it will lock out the proxy itself and with it every visitor at once.

Step Four: Close XML-RPC If Nobody Uses It

The file xmlrpc.php is an older remote publishing interface. It also lets a bot test hundreds of passwords in one request, which bypasses many login limiters entirely. If your officers do not post through the old mobile app or a desktop blogging client, disable it, either with a small security plugin option or a deny rule your host can add.

Test afterwards. Some plugins, including a few Discord integrations and older Jetpack features, depended on XML-RPC. Our plugin audit walkthrough for a clan site is a good moment to find out which ones still do.

Advice That Sounds Good but Barely Helps

Renaming the login URL

Moving wp-login.php to a secret address does cut log noise, and I do not object to it. But it is not protection. The address leaks through password reset emails, cached pages and browser history, and any bot hitting XML-RPC skips it entirely. Treat it as tidying, not security.

Hiding the WordPress version

Brute force bots do not care which version you run. They try passwords on everything. Removing the version tag changes nothing about this attack.

Installing three security plugins at once

Overlapping firewalls and limiters fight each other, double the database writes and make lockouts impossible to debug. Pick one tool that covers attempt limits and two-factor, and stop there.

Step Five: Read the Signs That It Is Working

After a week, check three things. Failed logins in the limiter log should be climbing, which means bots are being caught, not that you are losing. CPU usage in your hosting panel should have dropped. And no officer should have contacted you about a lockout. If one did, raise the attempts allowed to 7 before you start allowlisting IPs.

A monthly five-minute look at the administrator list catches the other risk: an old officer account nobody removed after they left the guild.

FAQ

Will Cloudflare alone stop brute force logins?

Its free plan blocks some known bad traffic, but many attempts still reach your login page. Combine it with a login limiter that reads the real visitor IP, and you cover both layers.

Should regular guild members have to use two-factor?

Usually no. Members with the Subscriber role cannot change content or settings, so a stolen member password has limited impact. Spend your effort on staff accounts.

Is a failed login email alert worth turning on?

Only for successful administrator logins from new devices. Alerts for every failure will flood your inbox within hours and train you to ignore the one that matters.

The One Hour Plan for This Weekend

Delete any account named admin, cut administrators down to two, switch on two-factor for staff, set a login limiter to 5 attempts and 20 minutes, and disable XML-RPC if nothing needs it. That sequence handles nearly every brute force login a guild site will face. For more maintenance routines like this one, browse our WordPress guides.