WordPress Login Protection: What I Saw and What to Check

A new site was already getting login attempts

I saw login attempts on a brand-new WordPress site with no public content. The names matched real accounts on an older WordPress site. That older site had run without its security plugin for a while.

The sites shared neither content nor users. I don't know where the names came from or whether the incidents were linked. What I do know: leaving a site empty didn't keep login attempts away.

The checks below come from documentation

I haven't reproduced these protection steps in a controlled test for this article. They're drawn from the linked WordPress, cPanel and Cloudflare guidance. Have your maintainer check how each applies to your setup.

A change that blocks an attacker can also lock out your staff or break a connected tool. Try access changes in staging first. Keep a way to recover the account before changing how people sign in.

Several small protections do different jobs

WordPress's hardening guide treats security as reducing risk. You still need someone watching failures and handling a restore. Installing a plugin doesn't answer who will do that.

Start with the checks below. If your existing site works, strengthening its weak spots may be enough. A password attempt alone doesn't make replacing the website worthwhile.

Five areas to review with your maintainer

1. Keep the software current

Check the core software, themes and plugins. Remove plugins you no longer use. The WordPress security team officially supports the latest version. Older releases may get fixes as a courtesy; don't build your plan around that.

Before a major update, check the backup and a route back if something fails. A current site with a broken booking form still needs attention.

2. Make the account hard to take over

Use a unique password and a password manager. Add two-factor authentication for administrators: a second check beyond the password. WordPress core doesn't provide it; you'll need a suitable plugin or sign-in service.

Store recovery codes somewhere you can reach without that account. Give staff only the access their work needs. The login protection guide also discusses passkeys and limits on repeated attempts.

3. Check what the host actually protects

Repeated guesses can be slowed at the network edge or server, before they consume WordPress resources. A plugin may add protection inside WordPress. Ask which layer covers your login and who watches its records.

For example, cPHulk protects listed hosting services, including cPanel, WHM, mail, FTP and SSH. WordPress login isn't on that list. A host saying it has brute-force protection doesn't settle that question.

Cloudflare's custom rules can filter requests before they reach the site. Its country-blocking example shows one capability. Broad country blocks can exclude real users, including you when travelling.

4. Review connections and editing access

If XML-RPC isn't used, your maintainer can assess restricting it. Check first: connected tools such as Jetpack or mobile apps may depend on it.

Application Passwords let connected services use the API, rather than the browser login. Revoke unused ones after checking what relies on them. Hiding a username isn't a substitute for protecting the account.

Your maintainer can also disable dashboard file editing using WordPress's documented setting. That removes one way to change code after a login. It doesn't prevent every route for uploading harmful files.

5. Prove that the backup can be restored

Keep a separate backup and rehearse a restore. Confirm what it covers: files, database and any records your business depends on. Agree who receives alerts and who acts when an update or login looks wrong.

My WordPress work covers sites already running. New builds use a different approach. The support plan begins at $75 monthly, paid annually. Each repair gets its own quote.