WordPress runs a huge share of the web, and that popularity cuts both ways. The same openness that lets you install a theme in two clicks or add a contact form plugin in thirty seconds also means your site is built from dozens of pieces of third-party code, each one a potential way in for someone who wants to plant malware, steal customer data, or quietly redirect your traffic to a spam site. None of that is a reason to avoid WordPress. It’s a reason to treat security as ongoing maintenance rather than a box you tick once during setup.

The good news is that most successful attacks on WordPress sites don’t rely on some exotic zero-day exploit. They rely on weak passwords, outdated plugins, and doors that were left unlocked because nobody got around to closing them. Fix those and you’ve already put your site ahead of most of the web. Here’s what actually moves the needle.

Lock out repeated failed logins

Brute-force attacks are exactly what they sound like: a script tries thousands of username and password combinations against your login page until one works. Without any protection, WordPress will let that script keep trying forever. A login-lockdown feature closes that door by watching for repeated failed attempts from the same source and blocking it, either for a set cooldown period or permanently if the pattern looks automated.

A lockdown plugin handles this without you having to think about it. Once it’s active, an attacker gets a handful of guesses before the door slams shut, which turns a brute-force attack from a real threat into a waste of their time.

Turn on two-factor authentication

A password alone is a single point of failure. If it leaks in a data breach somewhere else on the web, or gets phished, or is simply guessed, that’s the whole game for an attacker. Two-factor authentication adds a second, independent check: something you have in addition to something you know. That’s usually a time-based code from an authenticator app, though email codes and backup codes are common fallbacks.

Adding two-factor authentication to WordPress takes one plugin and a few minutes of setup. It’s the single most effective change on this list, because it neutralizes the most common attack vector, a leaked or guessed password, without asking much of you or your users.

Use a password that’s actually strong

“Strong password” gets repeated so often it’s easy to tune out, so here’s the concrete version: at least twelve characters, a mix of upper and lower case, numbers, and symbols, and never reused from another account. Anything shorter or more predictable can be cracked by automated tools in a reasonable amount of time, especially if it’s built from a dictionary word with a number tacked on the end.

A password manager solves this without asking you to memorize anything. It generates a random string for every account and fills it in automatically, which also means you’re not typing your admin password into a phishing page that looks like your login screen. If you manage a WordPress site with multiple authors, this is worth insisting on for every account, not just your own. One weak editor password is still a way into the whole site.

Move your login page off the default URL

Every stock WordPress install answers to /wp-login.php and /wp-admin, which means every automated scanner on the internet already knows exactly where to point its brute-force attempts. You don’t need those attempts to succeed to feel the cost: even blocked login attempts eat server resources and clutter your logs.

Changing the login URL to something custom doesn’t replace real authentication security, but it does mean the vast majority of scripted attacks never find your login form in the first place. Think of it as reducing noise rather than closing a real vulnerability, and pair it with the lockdown and two-factor steps above rather than relying on it alone.

Force HTTPS everywhere

An SSL certificate does more than put a padlock icon in the address bar. Without it, login credentials and any form data submitted on your site travel across the network in plain text, readable by anyone positioned to intercept it, which is a real risk on public Wi-Fi. With HTTPS enforced site-wide, that traffic is encrypted end to end.

Most hosts issue a free certificate automatically now through Let’s Encrypt, so there’s rarely a reason to skip this. Once it’s installed, make sure your site actually redirects HTTP requests to HTTPS rather than just making the certificate available, since a certificate that’s issued but not enforced protects nothing. Search engines also treat HTTPS as a baseline ranking signal, so this step pays for itself twice over.

Lock down the wp-admin directory

Your admin dashboard is the most attractive target on the entire site, since a successful break-in there means full control. Beyond the login-page protections above, you can add a second layer directly at the server level: password-protecting the /wp-admin directory itself through your host’s control panel, so a visitor needs to clear an additional authentication prompt before WordPress’s own login screen even loads.

It’s a small amount of setup for a meaningful increase in difficulty for an attacker, since it means compromising two separate credentials rather than one. If your host doesn’t offer this through cPanel or a similar tool, a security plugin can usually apply the same restriction, sometimes narrowed to specific IP ranges if you always administer the site from the same location.

Keep automatic, offsite backups

No security measure is airtight, which is why backups aren’t optional. If something does get through, whether that’s a hack, a bad plugin update, or your own mistake, a recent backup is the difference between an afternoon of restoring files and losing months of content permanently.

The backup needs to live somewhere other than the same server as your site. A backup stored alongside the site it protects gets wiped out along with everything else if the server itself is compromised or fails. Cloud storage, a separate host, or your hosting provider’s own offsite backup service all work. Set it to run automatically on a schedule that matches how often your content changes, daily for an active blog, and confirm every so often that a restore actually works rather than assuming the backup file is valid.

Watch the activity log

If more than one person can log into your WordPress site, an activity log tells you who changed what and when. That matters for two different reasons. First, it catches a compromised account early, since a login from an unfamiliar location or a sudden burst of file edits at 3 a.m. is a signal worth investigating immediately rather than discovering weeks later. Second, it gives you accountability across a team, so a content change or a settings tweak that broke something has a clear owner and timestamp attached to it.

Most activity-log plugins can email you when something specific happens, a new admin account created, a plugin installed, a password reset requested, so you’re not stuck manually checking a dashboard every day to catch a problem.

Pick hosting that treats security as part of the job

Not all hosting is equal, and the difference shows up most clearly during an attack. A host that patches its server software promptly, isolates accounts from each other on shared servers, and offers a real support team when something goes wrong is worth paying more for. A host that treats security as someone else’s problem leaves you exposed no matter how carefully you’ve configured WordPress itself.

If you’re on shared hosting, understand that a vulnerability in a neighboring account can sometimes affect yours too, depending on how well the host isolates tenants. Managed WordPress hosting exists specifically to address this: it typically includes server-level firewalls, automatic core updates, and malware scanning as part of the plan rather than as something you bolt on yourself.

Keep WordPress core, themes, and plugins updated

Most real-world WordPress compromises trace back to outdated software with a known, published vulnerability, not some novel attack nobody saw coming. When a plugin developer patches a security hole, the changelog and the vulnerability database entry that goes with it are effectively a map for anyone still running the old version. Delaying an update doesn’t buy you safety. It buys attackers time.

Turn on automatic updates for minor WordPress core releases at minimum, and review plugin and theme updates on a regular schedule rather than letting them pile up. If a plugin hasn’t been updated by its developer in a year or more, treat that as a warning sign and look for an actively maintained alternative, even if the old one still technically works.

Remove what you’re not using

Every inactive plugin and unused theme sitting in your WordPress install is still code that can be exploited, whether or not it’s currently switched on. Deactivating a plugin doesn’t always stop its files from being reachable directly. Deleting the ones you’re not using shrinks the attack surface and makes your update list shorter and easier to actually keep current.

This applies to old default themes too. If you’re running a custom theme, there’s rarely a reason to keep three unused starter themes installed alongside it. Clear them out during a routine maintenance pass.

Add a web application firewall

A web application firewall inspects incoming traffic before it ever reaches WordPress and blocks requests that match known attack patterns, SQL injection attempts, malicious file uploads, and known bad IP ranges among them. Plugins like Wordfence bundle this with malware scanning and login protection in one package, while a firewall running at the network edge through a service like Cloudflare filters traffic before it even reaches your server, which is generally the more efficient place to stop an attack.

Running both isn’t redundant. A network-level firewall catches volume-based attacks and known bad actors early, while a plugin-level firewall understands WordPress-specific attack patterns that a generic edge firewall might miss.

Set file permissions correctly and turn off in-dashboard file editing

WordPress ships with a built-in code editor under Appearance and Plugins that lets an administrator edit theme and plugin files directly from the browser. It’s convenient during development and dangerous everywhere else, because if an attacker ever does get into an admin account, that editor hands them a way to insert malicious code without needing FTP access or a server login at all. Disabling it removes one of the easiest post-compromise moves available to an intruder, and it costs you nothing if you’re not using it, which most site owners aren’t.

File and folder permissions matter for the same reason. Directories set to be writable by anyone, and PHP files with permissions looser than they need to be, give malware an easier path to plant itself and persist even after you think you’ve cleaned up. The general rule most hosts recommend is 755 for directories and 644 for files, with the wp-config.php file locked down further still, since it holds your database credentials in plain text. Most managed hosts set this correctly out of the box, but it’s worth confirming rather than assuming, particularly if you migrated the site from somewhere else or restored it from an old backup.

Turn off XML-RPC if you’re not using it

XML-RPC is an older WordPress feature that allows remote systems to publish posts, moderate comments, and perform a handful of other actions without loading the standard admin dashboard. Some tools still rely on it, notably the Jetpack plugin and certain mobile publishing apps, but if you’re not using any of those, it’s mostly sitting open as an extra target. Attackers use it for amplified brute-force attempts, since a single XML-RPC request can test hundreds of password combinations in one call instead of the one-at-a-time pace a normal login form allows.

If nothing on your site depends on it, disabling XML-RPC entirely closes that door. If something does depend on it, a security plugin can usually restrict it to specific trusted IP addresses instead of shutting it off completely, which keeps the functionality you need while cutting off the abuse.

Add security headers at the server level

A handful of HTTP response headers tell the browser itself to enforce protections that would otherwise depend entirely on your code being flawless. A Content-Security-Policy header restricts which sources scripts and styles can load from, which limits the damage if an attacker manages to inject a script tag somewhere on the page. An X-Frame-Options header stops your site from being loaded inside an invisible iframe on someone else’s page, a technique called clickjacking that tricks visitors into clicking something they didn’t intend to. A Strict-Transport-Security header tells browsers to only ever connect over HTTPS for your domain, even if a link or bookmark points to the old HTTP version.

These headers are usually set once at the server or CDN level rather than per page, so the setup cost is low relative to the protection they add. Most hosting control panels expose a way to add them without touching code, and a service like Cloudflare can apply them across the board even if your host doesn’t offer a direct option.

Stay informed through a vulnerability database

New vulnerabilities in WordPress core, popular plugins, and themes get discovered and disclosed constantly, and the gap between disclosure and a working patch is exactly when sites are most exposed. Services like WPScan maintain a public database of known WordPress vulnerabilities, searchable by plugin or theme name, so you can check whether something you’re running has an open issue before an automated scanner finds it for you.

You don’t need to check this manually every week. Several security plugins, Wordfence among them, cross-reference your installed plugins against a vulnerability feed automatically and flag anything that needs attention. The point isn’t to obsess over every disclosure. It’s to know within a day or two, rather than months later, when something you’re running needs an update or a temporary deactivation.

This matters more the more plugins you run. A site built on five well-maintained plugins is a much smaller target than one carrying twenty, several of which haven’t been touched by their developer in years. Every additional piece of installed code is another surface someone could probe, so it’s worth periodically asking whether a plugin is still earning its place or whether its function could be handled another way, folded into a plugin you’re already running, or dropped entirely because you stopped using the feature.

Give people only the access they actually need

WordPress ships with several built-in roles, and it’s tempting to make every regular contributor an administrator just to avoid dealing with permission errors down the line. Resist that. An administrator account can install plugins, edit any file through the dashboard, and change every setting on the site, which means a compromised administrator account is a compromised site, full stop. A writer who only ever publishes blog posts doesn’t need any of that.

Use the Editor role for people who manage content across multiple authors, Author or Contributor for people who only handle their own posts, and reserve Administrator for the one or two people who genuinely need full control. When someone leaves the project or stops contributing, remove their account rather than leaving it dormant. An old account with a password that was never rotated is exactly the kind of loose end that turns into a problem months later, usually discovered only after something has already gone wrong.

Treat security as maintenance, not a one-time setup

None of these steps is complicated on its own, and most take less time to implement than it took to read about them here. What actually protects a WordPress site isn’t any single plugin or setting, it’s the habit of checking on all of them regularly: updates applied, backups verified, logs reviewed, unused code removed. Set a recurring reminder if you have to. The sites that get compromised are usually the ones where security was configured once, in 2021 or whenever the site launched, and never looked at again.