WordPress Security Guide 2026: How to Actually Lock Down Your Site

Why Your Site Is Already a Target

WordPress runs about 45% of all websites on the internet. That market share makes it the most efficient target for automated attacks — if you build a scanner that exploits a WordPress vulnerability, you have a potential pool of hundreds of millions of sites. Every WordPress installation is being probed constantly. Not by humans, but by bots running 24 hours a day looking for specific version numbers, plugin vulnerabilities, and weak login credentials.

The client site I mentioned in the opening wasn't a famous brand or a financial institution. It was a local services business with maybe 400 visitors a month. Nobody "targeted" her specifically. The scanner found a vulnerable plugin, exploited it, injected spam content, and moved on — all automatically. This is how most WordPress hacks work. They're not targeted attacks. They're automated opportunism.

What attackers want from a compromised WordPress site varies: spam delivery, phishing page hosting, cryptocurrency mining, redirect traffic to scam sites, or simply adding your server to a botnet. None of it requires you to have anything valuable. Your server's compute resources and your domain's reputation are the assets.

Everything in this guide addresses one of those three entry points. Keep that framing in mind — it helps you prioritize when you're short on time.

The Front Door: Login Security

Default WordPress installations have two known URLs that every bot in the world knows: /wp-admin and /wp-login.php. They also have a default admin username that millions of people never change. That combination — known URL, known username, weak password — is the recipe for most brute force hacks.

Change the login URL

Install WPS Hide Login (free, 1 million+ installs, well maintained). It lets you change /wp-login.php to any path you choose — something like /manage-site or /dashboard-login. Anything that isn't the default. After making this change on a client site last year, I checked the server logs the next morning: failed login attempts dropped from roughly 300 per day to zero. The bots were still hitting /wp-login.php and getting 404s. They never found the new URL.

One important note: write down the new URL or save it in your password manager. I've had clients lock themselves out by forgetting what they changed it to. Not a security crisis, but a frustrating one.

Rename the admin username and use a real password

If your WordPress admin username is "admin," change it now. You can't rename it directly in the dashboard — create a new Administrator account with a different username, log in with the new account, delete the old "admin" user, and assign its posts to the new account. Two minutes of work that removes a known variable from brute force attacks.

The password question is simple: use a password manager (Bitwarden is free and excellent), generate a random 20+ character password, and never reuse credentials across services. If a data breach exposes your password from another site and you used the same password for WordPress, you're compromised. This has happened to clients who were otherwise careful about security.

Enable two-factor authentication

Wordfence's free version includes 2FA. So does the WP 2FA plugin. Enable it for all administrator accounts — this is non-negotiable if you have multiple admins. A stolen password alone is not enough to get in if 2FA is active. I've had this save a client account once: their password appeared in a credential dump from a different service, someone tried to log in, and the 2FA prompt blocked them.

Limit login attempts

WordPress by default allows unlimited login attempts. A script can try thousands of password combinations per hour against a known username. Limiting attempts to 3-5 before a temporary lockout stops this cold. Wordfence handles this automatically. If you're not using Wordfence, Limit Login Attempts Reloaded is the plugin for this — it's free, it works, it doesn't add bloat.

As for XML-RPC: disable it unless you specifically use the WordPress mobile app or Jetpack. It's an old remote access API that's a useful attack vector for brute force (it allows multiple login attempts per request, bypassing attempt limits on some configurations). Wordfence can block XML-RPC requests, or you can add a rule in your .htaccess file.

Plugin and Theme Hygiene

This is the category that causes the most hacks, and it's also the most preventable. The site I mentioned in the opening was compromised through an unpatched plugin — a plugin that had a publicly disclosed vulnerability for months before the attack. The fix would have taken thirty seconds to click "Update."

Updates: the habit that matters most

Enable auto-updates for WordPress minor releases (Settings General Automatic Updates on most hosts). For plugins, I selectively enable auto-updates for well-maintained, reputable plugins — Yoast, WooCommerce, WP Rocket. For less-maintained or older plugins, I prefer to review the changelog before updating, because occasionally a plugin update breaks something.

The practical system I use for client sites: a weekly Monday reminder to check wp-admin Dashboard Updates. Takes two minutes. I read the changelogs for anything I don't recognize, update everything on a staging copy first if I'm uncertain, then push to production. For most sites, this is overkill — you can just update directly. But for high-traffic or e-commerce sites, staging-first is worth the extra step.

Abandoned plugins: the hidden risk

An outdated plugin that was last updated in 2019 is a liability. Vulnerabilities get discovered; if the developer isn't maintaining it, they don't get patched. Check the "Last Updated" date on every plugin in your dashboard. Anything over two years with no updates should be evaluated — either find a modern alternative or accept that you're running unpatched code.

The WordPress.org plugin repository occasionally removes plugins that have known unpatched vulnerabilities or have been abandoned. If a plugin suddenly disappears from the repository, that's often why — and if you're still running it, you should be concerned.

Nulled themes and plugins: never, not once

Nulled themes are premium themes distributed for free on unofficial sites. I've heard every rationalization: "I just want to try it before buying," "the site looks reputable," "someone said it was clean." The reality is that nulled themes are the single most reliable malware delivery vector for WordPress. Even when they appear to work normally, they frequently contain obfuscated backdoors — code that looks like gibberish and does nothing obvious, until it receives a command from a remote server.

I've personally cleaned two sites that were infected through nulled themes. In both cases, the malware had been dormant for months before activating. If you find out you've been using a nulled theme, delete it, do a full malware scan, rotate all your passwords, and start from a clean backup if you have one. There's no "probably fine" scenario here.

Deactivated plugins still run code

Many people deactivate plugins they're not using rather than deleting them. Deactivated plugins don't load during normal page requests, but their files still exist on your server — and if they contain vulnerabilities, those vulnerabilities are still exploitable. Delete plugins you're not using. There's no upside to keeping them around, and there's a real downside.

wp-config.php Hardening

The wp-config.php file contains your database credentials and controls several WordPress security behaviors. A few additions to this file close some meaningful attack vectors. These go in the file above the line that says /* That's all, stop editing! */.

// Disable the theme/plugin file editor in wp-admin
// If an attacker gets admin access, this removes a major tool
define('DISALLOW_FILE_EDIT', true);

// Force HTTPS for all admin and login pages
define('FORCE_SSL_ADMIN', true);

// Turn off error display on production
// PHP errors can reveal server paths and version info
define('WP_DEBUG', false);
define('WP_DEBUG_DISPLAY', false);
@ini_set('display_errors', 0);

// Limit post revision storage (minor, but tidier database)
define('WP_POST_REVISIONS', 5);

// Move wp-config.php one directory above your WordPress root
// (many hosts support this — wp-config.php in /public_html/../)
// This keeps it outside the web-accessible directory

The DISALLOW_FILE_EDIT constant is the most important one. WordPress's built-in theme and plugin editor lets any administrator directly edit PHP files from the dashboard. It's a convenient feature that's also a direct path to running arbitrary code if an attacker gets into an admin account. Disabling it doesn't break anything — you can still edit files via SFTP — and it removes a tool from anyone who shouldn't have it.

On WP_DEBUG: I've seen production sites with debug mode on, which means PHP errors print to the page. Those errors can include full server file paths, database table names, and version information — all useful to an attacker doing reconnaissance. Turn it off on any live site.

File permissions

Correct permissions: directories at 755, files at 644, and wp-config.php specifically at 600 or 640. Wrong permissions let web processes write to files they shouldn't. Most hosts set these correctly by default — check after migrations or manual file edits, because those operations sometimes change permissions.

Also: use SFTP instead of FTP. FTP transmits credentials in plain text. SFTP encrypts the connection. Every host that's been in business for more than a few years supports SFTP — just change the port in your client (usually port 22 instead of 21). If your host genuinely only supports FTP, that's a signal about the quality of the infrastructure you're on.

Backups: Your Actual Last Resort

Everything else in this guide is about prevention. Backups are what you fall back on when prevention fails — which, if you manage enough sites for long enough, it will. The question isn't whether you'll ever need a backup. It's whether you'll have a clean one when you do.

The backup problem nobody talks about

In the 2021 incident I described: the client had backups. Her host kept weekly backups. But the spam injection had been live for three weeks before we discovered it — which meant the most recent backup was already contaminated. We had to go back five weeks to find a clean one, which meant losing five weeks of legitimate posts.

This is the problem with relying solely on your host's backup schedule. Weekly backups on a shared hosting plan might only retain 2-3 copies. If an attack goes undetected for more than a couple weeks, all your backups may be compromised. Daily backups with 30-day retention change that math significantly.

What I actually use

UpdraftPlus (free) configured to back up daily to Google Drive. It backs up the full WordPress installation — database, uploads, themes, plugins — and stores 30 copies before rolling over. Setup takes about 10 minutes: install the plugin, connect to Google Drive via OAuth, set the schedule, run a manual backup to confirm it works.

The critical step most people skip: test the restore. I did this on a development copy of the site — used UpdraftPlus to restore a backup to a staging environment. The restore of a 1.8GB site took about four and a half minutes. Everything came back correctly: database, theme, plugins, all uploaded media. If I hadn't tested, I wouldn't have known whether it actually worked until I needed it under stress.

For e-commerce or sites with daily transactions: daily backups to off-site storage are non-negotiable. Don't rely on your host's backup system as your only copy. If your host's infrastructure has a problem, your backups on the same infrastructure are at risk too. Google Drive, Dropbox, Amazon S3 — anything external.

Security Plugins: Wordfence vs Sucuri vs Malcare

There are three serious options in this space. Install one. Not two or three — security plugins routinely conflict with each other, and running multiple simultaneously creates false positives, performance issues, and occasionally breaks things. Pick one and use it properly.

Wordfence is my default recommendation for most sites. The free version is genuinely thorough — the firewall, scanner, login protection, and 2FA cover the essentials. The 30-day rule delay on free is a real limitation in theory, but in practice most attacks targeting shared hosting exploit vulnerabilities that have been known for months or years, not days. The main downside is performance: Wordfence's scanner runs on your server, which can slow things down on low-resource shared hosting plans. I've seen it add 2-3 seconds to admin dashboard load times on cheap hosting.

Malcare is worth considering specifically because it runs its scanning off your server — which means the scanning process doesn't consume your hosting resources. On a shared hosting plan with limited CPU, this matters. If you've noticed Wordfence making your admin area sluggish, switch to Malcare and the problem typically disappears.

Sucuri's free plugin is primarily a security monitoring and audit log tool — it doesn't include the full WAF in the free version. If you're paying for Sucuri Premium, the CloudProxy WAF is excellent. For free use, it's more of a monitoring tool than a full security suite.

Monitoring and Early Detection

The 2021 hack I described went undetected for three weeks partly because nobody was watching. The site appeared to load normally for legitimate visitors. The spam pages were in a subdirectory that wasn't on anyone's radar. If we'd had proper monitoring in place, the detection would have happened in days rather than weeks.

Uptime monitoring

UptimeRobot (free) checks your site every 5 minutes and emails you if it goes down. This sounds basic, but a site going offline is often the first symptom of an attack — DDoS, server suspension by host due to malware, or a hack that corrupts core files. Without monitoring, you might not find out for hours. With UptimeRobot, you know within minutes. I have it running on every site I manage. The free plan covers up to 50 monitors.

Google Search Console

Connect every site to Google Search Console and check it monthly at minimum. The Security & Manual Actions section shows Google-detected malware, hacked content, and manual penalties. This is often how site owners find out about injected spam pages — Google's crawlers find them before the owner does. Search Console will also notify you by email if a security issue is detected, though that notification can take a few days after Google's discovery.

Wordfence email alerts

Configure Wordfence to alert you on: admin logins from new devices, failed login lockouts, new administrator user creation, and scan results that find problems. These are low-frequency, high-signal alerts — you won't get email noise, but you'll know when something suspicious happens. The alert for "new administrator account created" is especially valuable: creating a backdoor admin is one of the first things an attacker does after gaining access.

After a Hack: The Recovery Process

Getting hacked is stressful. There's a strong urge to do everything at once. The six-step process below is the order I've learned matters — skip steps or do them out of order, and you risk either missing malware or getting reinfected within days.

When I worked through the 2021 client recovery, I had cleaned the site and thought we were done — then noticed new spam pages appearing two days later. The reason: we'd removed the injected files but hadn't identified the actual entry point, which was still vulnerable. The attacker re-exploited it. I had to go back through the full process, properly this time.

If you don't have a clean backup and the site is too compromised to restore, professional malware removal services (Sucuri, Wordfence Premium, Malcare Premium) range from $99-$199. For most attacks, this is less expensive than attempting a manual cleanup if you're not experienced with it — a manual cleanup that misses anything just means you're reinfected in a week.

Before You Start: Three Things Worth Knowing

The Free Security Stack

You don't need to spend money to have a well-secured WordPress site. This is the combination I use on most sites I manage:

Frequently Asked Questions