WordPress still powers a large share of the web in 2026, and that popularity cuts both ways. It means enormous community support and a plugin for nearly anything you need, but it also means automated attack scripts are constantly scanning for the same handful of weaknesses across millions of sites at once. Most successful attacks aren’t the work of a person targeting your site specifically; they’re bots working through a checklist looking for outdated plugins, weak passwords, and misconfigured permissions. Hardening a WordPress install is really just closing off that checklist item by item.

Essential WordPress Security Measures

1. Keep Everything Updated

Outdated WordPress core, themes, and plugins remain the single biggest cause of security breaches, and it isn’t close. When a plugin developer patches a vulnerability, the patch itself often reveals exactly what was broken to anyone paying attention, which turns unpatched sites into an easy target the moment a fix ships. Enable automatic updates for minor core releases at minimum, and set a weekly reminder to check plugin and theme updates manually if you’re not comfortable with fully automated updates across the board.

Action: Enable automatic updates in WordPress settings and schedule regular manual checks. Remove any plugin or theme you’re no longer actively using instead of just deactivating it, since dormant code still sits on the server as a potential entry point.

2. Use Strong Authentication

Two-factor authentication turns a stolen or guessed password from a full compromise into a dead end, and it’s one of the highest-value security additions relative to the effort it takes to set up. Pair it with a password policy that actually gets enforced (not just suggested) and a hard limit on login attempts, since brute force tools will happily try thousands of password combinations per hour against a login form with no rate limiting.

Action: Install a 2FA plugin and require it for every account with publishing or administrative access, not just the main admin login. Set a minimum password strength requirement for all user roles.

3. Limit Login Attempts and Watch for Brute Force Activity

A login form with no limit on failed attempts is an open invitation. Automated brute force tools will cycle through common password lists against your username around the clock unless something stops them, and the fix is straightforward: lock an IP address out after a handful of failed attempts, and extend the lockout period for repeated offenders. This alone eliminates a huge share of the automated attack traffic hitting a typical WordPress login page.

Action: Configure login attempt limiting through your security plugin, and consider renaming the default login URL away from /wp-admin as an extra layer, understanding that this alone isn’t a substitute for the rate limiting itself.

4. Install Security Plugins for Spam and Firewall Protection

Use CleanTalk for spam and bot protection on forms and comments, combined with a comprehensive security plugin that handles firewall rules and malware scanning. A web application firewall filters out malicious requests before they ever reach WordPress itself, which matters because plenty of attacks target the server layer rather than a WordPress vulnerability specifically. Malware scanning catches the cases where something did get through, flagging modified core files or suspicious injected code before it does real damage.

Action: Install and configure security plugins, enable all protective features, and review scan results on a set schedule rather than only after something looks wrong.

5. Back Up Regularly and Test the Restore Process

Use BlogVault or a similar tool for automated daily backups stored off-site, away from the same server as the live site. A backup that only lives on the same machine as the site it’s protecting isn’t much of a backup if that server gets compromised or fails entirely. The part most site owners skip is testing the restore itself; a backup nobody has ever successfully restored from is an assumption, not a safety net.

Action: Set up automated backups with off-site storage and actually run a test restore to a staging environment at least once a quarter.

6. Choose Hosting With Real Security Features

Quality hosting from providers like Kinsta or SiteGround includes server-level security that a self-managed VPS often lacks by default: SSL certificates handled automatically, malware scanning at the infrastructure level, and isolation between sites on shared or managed environments so a compromise on one account doesn’t spread. Cheap shared hosting without those protections shifts more of the security burden onto plugins alone, which is a weaker position to defend from.

Action: Evaluate your current hosting provider’s security features against what a managed WordPress host offers, and upgrade if the gap is significant.

7. Secure File Permissions and Lock Down wp-config.php

File permissions that are too permissive give an attacker who gains any foothold an easy path to modifying files across the whole site. The standard baseline is 644 for files and 755 for directories, with wp-config.php locked down further since it holds your database credentials and security keys. Disabling file editing from the WordPress dashboard closes off a common path attackers use once they’ve gained admin access: editing a theme file directly through wp-admin to inject malicious code.

Action: Add define('DISALLOW_FILE_EDIT', true); to wp-config.php, verify file and directory permissions match the standard baseline, and set wp-config.php itself to 600 where your hosting environment supports it.

8. Restrict the REST API and Disable Unused XML-RPC Access

The WordPress REST API and XML-RPC both expose functionality that most sites never actually use directly, but that attackers regularly probe as an entry point, particularly for brute force attempts that bypass the standard login form’s rate limiting. If you’re not using XML-RPC for a specific integration (like a mobile publishing app), disabling it removes an entire attack surface. Similarly, review which REST API endpoints genuinely need to be public and restrict user enumeration endpoints that reveal usernames to anyone who asks.

Action: Disable XML-RPC through your security plugin if it isn’t actively used, and restrict REST API user endpoints that expose usernames publicly.

9. Add Security Headers and Enforce HTTPS Everywhere

Security headers like Content-Security-Policy, X-Frame-Options, and Strict-Transport-Security tell browsers how to handle your site defensively, blocking classes of attacks like clickjacking and certain cross-site scripting attempts before they can execute. Enforcing HTTPS across the entire site, not just the login page, protects data in transit and is now a baseline expectation rather than an optional extra, both for security and for how browsers and search engines treat unencrypted pages.

Action: Confirm HSTS is enabled at the server or CDN level, and add core security headers either through your hosting provider’s configuration or a security plugin that supports them.

10. Apply the Principle of Least Privilege to User Roles

Not every contributor needs administrator access, and every extra admin account is another password that could be weak, reused, or eventually forgotten and left dormant. Assign the WordPress role that matches what someone actually needs to do: Editor for someone managing content across the site, Author for someone who only publishes their own posts, and Administrator reserved for the small number of people who genuinely need full site control.

Action: Audit user accounts quarterly, remove accounts for people who no longer need access, and downgrade any account with administrator privileges it doesn’t actually use.

11. Change the Default Database Table Prefix

WordPress ships with wp_ as the default table prefix, and automated SQL injection attempts often assume that default without checking. Changing the prefix to something unique during installation, or migrating an existing site to a custom prefix, removes an assumption that a lot of generic attack scripts rely on. It won’t stop a targeted, competent attacker who inspects the database directly, but it does filter out a meaningful share of automated, unsophisticated attempts that are written to a generic template.

Action: Set a custom table prefix on new installs, and use a reputable migration plugin if changing the prefix on an existing site rather than editing the database by hand.

12. Hide Version Numbers and Disable Directory Listing

WordPress, by default, exposes its version number in page source and readme files, and plugins and themes often do the same. That information tells an attacker exactly which known vulnerabilities to try without any guesswork. Directory listing, if left enabled on your server, lets anyone browse the raw contents of folders like wp-content/uploads directly, which can expose files never meant to be publicly linked.

Action: Remove or obscure version number output through your security plugin, delete the default readme.html file from the WordPress root, and confirm directory listing is disabled at the server level.

Ongoing Security Maintenance

Security is an ongoing process, not a one-time setup checklist you complete and forget. Schedule monthly security audits that cover updates, user accounts, and scan results together rather than checking each in isolation. Monitor your site for suspicious activity, unexpected admin accounts, unfamiliar files in the uploads directory, sudden spikes in outbound traffic, and stay informed about new vulnerabilities affecting the specific plugins and themes your site runs. A ten-minute monthly check catches problems while they’re still small; a site left unmonitored for a year can accumulate multiple unpatched issues that compound into something much harder to clean up.

Keep a simple written record of what you changed and when, especially for security-related settings like firewall rules, user permission changes, and plugin removals. It sounds like unnecessary paperwork until the day something breaks and you need to work out whether a recent change caused it or whether it’s unrelated. A quick log turns that investigation from guesswork into a five-minute check.

What a Real Attack Attempt Usually Looks Like

It helps to understand the shape of a typical automated attack rather than treating security as an abstract checklist. Most attacks against WordPress sites start with reconnaissance: a bot fingerprints which plugins and theme a site is running, often just by requesting known file paths and checking the response. If that fingerprinting finds an outdated plugin with a known vulnerability, the bot moves straight to exploiting it, sometimes within minutes of identifying the target. If nothing obvious turns up, the bot often falls back to brute-forcing the login form with a list of common username and password combinations, which is exactly why login rate limiting and two-factor authentication matter as much as they do.

Once an attacker does get in, the goal is rarely to deface the site visibly, since a visible defacement gets noticed and cleaned up fast. More often, the goal is to inject hidden spam links, redirect a fraction of visitors to another site, or add the compromised site to a network used for further attacks, all while leaving the site looking normal to its actual owner. That’s part of why malware scanning and file integrity monitoring matter even when nothing looks wrong on the surface; a compromised site can keep functioning normally for the visitor while quietly doing damage in the background.

Contact form spam sits in a slightly different category from a full site compromise, but it’s worth addressing for its own reasons: it wastes staff time sorting real inquiries from junk, and a high volume of spam submissions can be a sign that a bot has already found and is actively probing your site, which sometimes precedes a more serious attack attempt. Treating spam filtering as a security measure rather than just an annoyance to tolerate is a reasonable way to think about it.

Common Questions About WordPress Security

Do I really need a security plugin if my host already has protections in place?

Host-level protection and a WordPress-specific security plugin cover different layers. Your host typically protects the server and network level; a security plugin adds WordPress-aware features like login rate limiting, file integrity monitoring for your specific theme and plugin files, and malware scanning tuned to WordPress’s file structure. Running both isn’t redundant, it’s layered defense, which is the whole point.

How often should backups actually run?

For a site that publishes content regularly or handles transactions, daily backups are the reasonable baseline. A site that changes rarely can get away with less frequent backups, but the real question to ask is: how much work would you be comfortable losing if you had to restore from the most recent backup right now? Set the frequency based on that answer, not on a generic recommendation.

Is renaming the login URL actually useful, or just security theater?

It’s a minor speed bump, not real protection on its own. It cuts down on the noise from unsophisticated bots hammering the default /wp-admin path, which can meaningfully reduce server load and log clutter, but it does nothing against a targeted attacker who can find the real login URL easily enough. Treat it as a nice-to-have addition on top of rate limiting and two-factor authentication, not a replacement for either.

What’s the first thing to do if I suspect my site has been compromised?

Change all passwords immediately, including database and hosting account credentials, not just the WordPress admin login. Then run a full malware scan and compare core WordPress files against a clean install to spot unauthorized modifications. If you have a recent, verified-clean backup, restoring from it is often faster and more reliable than trying to manually clean an active infection, especially if you’re not confident you’ve found every injected file.

After restoring or cleaning a compromised site, go back and figure out how the attacker got in before considering the incident closed. Restoring from a backup without identifying and closing the original entry point just resets the clock until the same vulnerability gets exploited again. Check the timeline of the compromise against your update and change log; it usually points directly at an outdated plugin, a weak password, or a misconfigured permission that needs fixing before the site goes back online.

Does a small blog or portfolio site really need this level of security?

Automated attacks don’t check how much traffic a site gets before targeting it; the bots scanning for vulnerabilities work through IP ranges and known WordPress installations regardless of site size. A small site is actually attractive in a specific way: it’s less likely to be monitored closely, which means a compromise can sit undetected for longer than it would on a heavily trafficked site with active monitoring. The core measures, updates, strong passwords, backups, and basic firewall protection, take roughly the same setup time whether a site gets ten visitors a day or ten thousand, so there’s little reason to skip them on a smaller site.

Should I run a security audit before or after installing new plugins?

Before, ideally, and again afterward. Check a plugin’s update history, support responsiveness, and how recently it was last updated before installing it; a plugin that hasn’t been updated in two years is a real risk regardless of how useful it looks. After installation, a quick scan confirms the new plugin hasn’t introduced an obvious conflict or vulnerability, and it’s worth repeating that check any time you add something new rather than only during a periodic full audit.

Security tooling and hosting plans change their feature sets fairly often, so it’s worth confirming current capabilities directly with your host and security plugin provider rather than assuming a feature list from a year ago still applies.