How to Secure Your WordPress Login Page (4 Key Steps)

Your WordPress login page is the front door to your website. It sits at a well-known address, it is open to the whole internet, and automated tools try common username and password pairs against it all day. This guide is for small business owners and the people who look after their sites. After reading it, you will know four changes that make a login a much harder target, and how to make them without locking yourself out.

In short: Start with strong, unique passwords. Then add two-factor authentication for every administrator and editor, limit failed login attempts, review whether you need XML-RPC, and reduce how easily usernames can be found. No site is ever completely safe, but together these changes remove the easy routes in.

Before you change anything

Checklist of four preparations: full backup you can restore, hosting panel and SFTP access, one signed-in window while testing in a private one, and one change at a time with a login test.

Take a full backup of files and database, and check you know how to restore it.
Make sure you can sign in to your hosting control panel and, if needed, reach your files over SFTP.
Keep one browser window signed in to WordPress while you test in a private window.
Change one thing at a time and test a normal login after each change.

WordPress is widely used, so one script can be pointed at thousands of sites. A standard install serves its login form at wp-login.php, and older sites may still have an obvious username such as admin. If an attacker gets into an administrator account, they can install a backdoor, redirect visitors or send spam from your domain. Your aim is simple: be a harder target than the next site on their list.

Step 1: Turn on two-factor authentication

Two-factor authentication (2FA) asks for a second proof after the password, usually a code from an authenticator app or a hardware security key. If a password is leaked or guessed, the attacker still cannot sign in with it alone.

Flow: password, then a second proof from an authenticator app or security key, then signed in. A leaked or guessed password alone is not enough. Limits: fake login pages and stolen sessions.

It is not perfect. Fake login pages can capture typed codes, and a stolen browser session can bypass the login form. Security keys (WebAuthn/FIDO2) resist phishing better than typed codes, so use them where your plugin supports them.

How to set it up

WordPress does not offer 2FA on the login form out of the box in standard installs, so you will usually need a plugin or a host feature:

Install a well-reviewed, actively maintained 2FA or security plugin from the WordPress plugin directory, or enable your host's option if it has one.
Require 2FA for every administrator and editor, not only yourself.
Have each person link an authenticator app by scanning a QR code, or register a security key.
Sign in from a private window to confirm the second step appears.

What people forget

Recovery codes. Choose a plugin that provides one-time recovery codes and store them in a password manager.
Unused accounts. 2FA only protects accounts where it is enabled. Delete old users, avoid shared logins and keep administrators few.
Application passwords. These let apps authenticate without the normal login form, so form-based 2FA may not cover them. Remove any you do not recognise.
Accounts around WordPress. Turn on 2FA for your hosting account, domain registrar and the email address used for password resets.

Rate limiting allows only a set number of failed logins from one source before it temporarily blocks further tries. WordPress core does not do this itself, but your host, CDN or a security plugin may. Check what you already have before adding another layer, because overlapping plugins can conflict.

Typical settings include allowed retries before a lockout, lockout length (often longer for repeat offenders) and email alerts, which can reveal a sustained attack.

Watch out: Do not set the retry count very low, or a staff member who mistypes a password will be locked out. If it happens, follow your plugin's documented recovery steps rather than editing the database by hand.

Limits to be aware of

Spread-out attacks. Per-address limits do not stop an attacker who rotates through many addresses. This is where 2FA and strong passwords carry the load.
Wrong visitor address. Behind a CDN or reverse proxy, WordPress can see the proxy's address instead of the visitor's. Limits may then fail to stop attackers, or block many real visitors at once. Check how your plugin detects the client address.
Blocking earlier. If your CDN or host offers rate-limiting rules, applying them to wp-login.php stops excess requests before they reach WordPress.

Step 3: Review XML-RPC

XML-RPC (xmlrpc.php) is an older WordPress interface used by some mobile apps, remote publishing tools and plugins. It is another place where login attempts can be made. If you do not need it, there is little reason to leave it open.

Three XML-RPC options: plugin switch (low effort, low risk), block xmlrpc.php at server or CDN (medium effort, can break integrations), leave it open (no effort, extra login route stays). Test integrations.

Before blocking it, check what might depend on it: mobile apps or publishing tools you use, plugins such as Jetpack (read the plugin's current documentation), and any third-party service that posts to or reads from your site.

Option	Effort	Risk
Plugin switch to disable XML-RPC login	Low	Low
Block `xmlrpc.php` at the server or CDN	Medium	Can break integrations
Leave it open	None	Extra login route stays

Blocking it at the server

If you can edit server configuration and WordPress sits at the web root, you can stop the request before PHP runs. On Apache 2.4 (where .htaccess overrides are allowed), add:

<Files xmlrpc.php>
  Require all denied
</Files>

On Nginx, add this inside your server block:

location = /xmlrpc.php {
  deny all;
}

Most CDNs and web application firewalls also let you block requests to the path /xmlrpc.php; check your provider's documentation. Afterwards, visit https://yourbusiness.com/xmlrpc.php: you should see an error such as 403 rather than the normal XML-RPC response. Then test every integration on your list.

Step 4: Make usernames harder to find

Before guessing passwords, attackers often collect valid usernames. WordPress can reveal them in several ways:

Three places WordPress can reveal usernames: /?author=1 may show the author slug, /wp-json/wp/v2/users can list display name and slug, and different login error messages confirm which usernames exist.

Where it leaks	What to know
`/?author=1`	May redirect to an author page showing the author slug, which is often, but not always, the login name
`/wp-json/wp/v2/users`	Can list public author details such as the display name and slug
Login error messages	Different messages for "unknown user" and "wrong password" confirm which usernames exist

What you can do

Use generic login errors. Many security plugins replace specific messages with one neutral "incorrect login details" message.
Separate display name and login name. In each profile, choose a public display name that differs from the username. The author slug may need changing separately.
Restrict the users endpoint with care. Some plugins can require authentication for /wp-json/wp/v2/users. Do not block the whole REST API, because the block editor and many plugins rely on it.
Intercept author scans. Many security plugins can block or redirect /?author=N requests.

Treat this as a speed bump. Usernames can still appear in post bylines, backups and compromised plugins, so never rely on a hidden username as protection.

Some guides suggest moving wp-login.php to a secret path. It can cut noise from untargeted scans, but it is obscurity rather than protection, and a mistake can lock you out. If you do it, keep it on top of the four steps above, not instead of them.

The official WordPress hardening guide and the OWASP Authentication Cheat Sheet are good next reads.

To see how your site looks from the outside, Lordevo's free Safe Scan checks public signals without changing anything on your site. It is a starting point, not proof that your login is secure.

[ ] Take a backup and confirm you can restore it before changing anything.
[ ] Turn on 2FA for every administrator and editor, and store recovery codes in a password manager.
[ ] Set login rate limits that tolerate an occasional typo, and check they see real visitor addresses.
[ ] Decide on XML-RPC: list what depends on it, block it if unused, then test the URL and each integration.
[ ] Use generic login errors and a public display name that differs from each username.
[ ] Keep WordPress core, themes and plugins updated, and remove any you no longer use.

FAQ

Is a strong password enough on its own?

It is the foundation, but passwords can be leaked, phished or reused. With 2FA, a stolen password alone is not enough to sign in.

Will blocking XML-RPC break my site?

Public pages will not be affected, but anything that uses XML-RPC may stop working, so test each integration afterwards.

Do I need a security plugin?

Not necessarily. Your host or CDN may already provide login limits, and you need a plugin only for features you lack, such as 2FA.

I locked myself out. What now?

Use your 2FA recovery codes, or wait for a rate-limit lockout to expire. If that fails, follow the plugin's documented recovery steps or ask your host for help, and restore from backup if needed.