How to protect your WordPress site against hackers

Running a WordPress site is the easy part. Keeping it standing while half the internet tries to log in as admin is where things get interesting. If you sell, publish or just keep client work on WordPress, hackers will eventually knock on your door, and the door they pick is almost always a forgotten plugin, a weak password or a wp-admin page that nobody bothered to hide.

You don’t need a security degree to make a site hard to break into, and most of the tips below take ten minutes to apply each, so the whole list is a long afternoon of work rather than a project. If you want the wider picture beyond the specific actions in this article, our broader WordPress security strategy goes deeper into the thinking behind the controls.

Security isn’t a one-time project, it’s maintenance. Code needs upkeep, plugins age, and what was safe last year may have a public CVE this year.

Basic tips

1. Keep everything up to date

WordPress core, themes and plugins are the three things you have to keep current, because outdated software is the single most common way sites get compromised — public vulnerabilities turn into automated scans within hours of being disclosed.

The proper order matters more than people realise: back up first, then update, then verify the site still works. Skipping the backup step is how a five-minute update becomes a four-hour rollback, and skipping the verification step is how broken checkouts get discovered by customers instead of by you. Enable automatic updates for minor core releases and trusted plugins, but keep major versions and themes manual so you can test on staging.

2. Use strong passwords

Yes, this is obvious, and yes, people are still using password123 in 2026. A strong password is long, mixes upper and lower case, numbers and symbols, and lives in a password manager like Bitwarden or 1Password rather than in your head. Reusing the same password across WordPress, hosting and email is a fast track to disaster, because a breach in any one of them cascades into the other two.

3. Remove what you don’t use

Every inactive theme and every deactivated plugin still sits on the server, still has code that can be exploited, and still adds to the maintenance burden. If you’re not using something, delete it, don’t just deactivate it. Review the list once a quarter and prune anything you can’t justify keeping.

4. How to choose a secure plugin

This is the section nobody writes about, and it’s where most infections start. Before you install a plugin, spend two minutes evaluating it on four signals.

First, the last updated date on the WordPress.org repository. A plugin untouched in twelve months is either finished and stable, or abandoned and dangerous, and you can’t tell which from the outside — treat anything older than a year with suspicion.

Second, active installations. A plugin with 3,000,000 active installs has thousands of eyes on the code and a real incentive to patch fast, whereas a plugin with 200 installs may be fine, but if there’s a vulnerability you might be the one who discovers it the hard way.

Third, the rating and reviews. Open the one-star reviews specifically, because that’s where you find out if the plugin breaks sites, calls home or stops working after a recent update.

Fourth, a quick search on Google and the WPScan vulnerability database for the plugin name plus “CVE”. If something nasty has been disclosed in the last twelve months and not patched, walk away.

A healthy plugin looks roughly like this: 4.5+ stars, several hundred thousand active installs, last updated within the last two or three months, no open security issues in the public databases.

5. Install a security plugin

A security plugin won’t save a badly maintained site, but it will catch the noise — failed logins, suspicious file changes, malware signatures — and surface it before things escalate. Wordfence, Sucuri and Solid Security (formerly iThemes) are the usual suspects, and any of them is better than nothing. Turn on alerts for admin logins, new user creation and core file changes, because most attacks leave a footprint in one of those three.

6. Change the login URL

By default everyone knows your login lives at /wp-admin or /wp-login.php. Moving it to something nobody can guess — say /manage-1729 — cuts brute-force traffic enormously, simply because the bots never find the page. Not real security on its own, but a cheap layer that reduces log noise and CPU load. WPS Hide Login does the job in two clicks.

7. Limit login attempts

If a script can try ten thousand passwords against your login form, eventually one will work, especially if your editorial team has a fondness for predictable passwords. Limiting attempts blocks the IP after a handful of failures and forces attackers to slow down or move on. Five failed tries in fifteen minutes, then a thirty-minute lockout, is a reasonable starting point.

About CAPTCHAs: personally we would avoid them by default, because they hurt accessibility, frustrate legitimate users and rarely stop modern bots, which solve them through paid services for fractions of a cent. Add one only if you are seeing genuine abuse that rate limiting cannot handle.

8. Make regular backups

Backups are the seatbelt of WordPress security. You hope you never need them, and the day you do, you will be glad they exist. Daily backups for active sites, weekly for the rest, stored off-site in S3, Google Drive or Dropbox, never only on the same server.

The part everyone forgets is testing the restore. A backup file that will not restore is not a backup, it is a file. Once a quarter, pick a random backup and restore it to staging to make sure the process actually works. UpdraftPlus, BackWPup or your hosting provider snapshot system all work; if you manage many sites, centralised backups through Modular DS save the pain of logging into each one.

9. Disable file editing from the WordPress dashboard

WordPress lets administrators edit theme and plugin files directly from the dashboard, which is convenient for developers and catastrophic if an attacker gets in, because they can drop a backdoor through the same editor. Turn it off by adding one line to wp-config.php:

define( 'DISALLOW_FILE_EDIT', true );

If you actually need to edit theme files, do it through SFTP.

10. Use two-factor authentication (2FA)

Two-factor authentication stops the vast majority of credential-stuffing attacks dead, because even a stolen password is useless without the second factor. Plugins like Wordfence Login Security, Two Factor or WP 2FA all do the job with TOTP apps such as Google Authenticator, Authy or 1Password.

One detail that catches people out: do not leave a “grace period” where new admins can log in without 2FA set up. Force the setup on first login, for every administrator, no exceptions — and extend it to editors and shop managers, because they are valuable targets too.

11. Apply role-based access control

WordPress ships with several roles for a reason. Administrator, Editor, Author, Contributor and Subscriber each have a specific set of capabilities, and giving every user Administrator access is a habit worth breaking.

Before you create a new user, spend ten minutes thinking about what they actually need to do. A copywriter who writes drafts needs Contributor or Author, not Administrator, while a client who reviews posts before publishing needs Editor. The marketing person who installs plugins they read about on LinkedIn does not need to install plugins at all — they need to send you a link and let you evaluate it first. Smaller blast radius per account means a compromised user is a problem, not a catastrophe.

Audit your user list twice a year, because old freelancers, ex-employees and demo accounts add up quickly and every one of them is an attack surface.

12. Monitor your website regularly

Set a recurring calendar reminder, monthly at minimum, to check for unfamiliar users, modified files, unexpected pages, weird outbound links or core file changes. Many compromised sites stay compromised for months because nobody looks, and five minutes once a month closes that window.

Advanced tips

1. Use a Web Application Firewall (WAF)

A WAF sits between the internet and your server, filtering out malicious requests before they ever reach WordPress, and blocking SQL injection probes, XSS payloads, malformed requests and traffic from known bad IP ranges at the edge. Cloudflare free tier covers basic WAF rules and bot protection, Sucuri Firewall is a managed option, and Wordfence runs at the application level inside WordPress. Whichever you choose, make sure it sees real visitor IPs and not the load balancer IP, otherwise rate limiting and geolocation rules become useless.

2. Change the database prefix

WordPress defaults all tables to wp_, which automated SQL injection scripts assume blindly. Changing the prefix to something custom — mds_82a9_, for instance — breaks those automated attacks without affecting anything else. On existing sites, plugins like Brozzme DB Prefix & Tools change it safely; back up the database first, because a botched prefix change locks you out completely.

3. Disable XML-RPC (and consider disabling external WP-Cron)

XML-RPC was useful in the era of remote publishing apps, but in 2026 it is mostly a brute-force amplifier and a DDoS vector. If you do not use the Jetpack mobile app or remote publishing, kill it. Add to .htaccess:

# Block requests to XML-RPC
<Files xmlrpc.php>
order deny,allow
deny from all
</Files>

In the same spirit, the built-in WordPress cron runs on every page load and external attackers can use it to amplify load. If your hosting supports real system cron, disable WP-Cron in wp-config.php with define('DISABLE_WP_CRON', true); and set up a system cron job to hit wp-cron.php every five minutes.

4. Configure HTTP Security Headers

HTTP security headers tell the browser how to behave when loading your site, and they shut down whole classes of attacks — XSS, clickjacking, MIME sniffing, protocol downgrade — for the price of a few server config lines. The ones to care about are Content-Security-Policy, Strict-Transport-Security, X-Frame-Options, X-Content-Type-Options and Referrer-Policy. Scan your domain at securityheaders.com to see your current grade, then add the missing ones through your server config or a plugin like HTTP Headers. Aim for A or A+.

5. Force HTTPS across the entire site

HTTPS is the baseline on every page, every asset and every admin request, because mixed content warnings are annoying for users and a real risk for sessions in transit. Get a free Let’s Encrypt certificate through your host, then force HTTPS at the server level (or with Really Simple SSL if you cannot), and enable HSTS once you are confident everything is on HTTPS so browsers never fall back even on a typed-out URL.

6. Use public/private key-based authentication

For SSH access to the server itself, ditch passwords entirely. Generate an Ed25519 key pair on your machine, drop the public key into ~/.ssh/authorized_keys on the server, and disable password authentication in sshd_config. Brute force against your SSH port stops working overnight. Keep the private key encrypted with a passphrase, and back it up in your password manager, because losing it means losing access.

7. Audit your site with WPScan

WPScan is the tool penetration testers use to enumerate WordPress installations, and you can use it on your own site to find what an attacker would find. It checks core version, plugin versions, theme versions, user enumeration and known CVEs against the WPScan vulnerability database. The easiest way to run it is through Docker:

docker run --rm -it wpscan/wpscan --url https://yoursite.com --api-token YOUR_TOKEN

A free API token from wpscan.com gives you 25 scans per day, more than enough for personal use.

Two warnings before you fire it off. Scanning sites that are not yours is not okay legally or ethically, so stick to your own. And run the scan from a VPS or a dedicated environment, not from your home IP, because if the target sits behind Cloudflare or a similar WAF the scan looks exactly like a real attack, and Cloudflare may flag your IP as malicious, which then bleeds into other services that use shared threat intelligence. A throwaway DigitalOcean droplet for five euros a month solves it cleanly.

8. Continuous auditing and monitoring

A scan is a snapshot, but real protection needs continuous monitoring that logs logins, file changes, role changes, plugin installs and content modifications, and alerts you when something looks off. WP Activity Log and Stream are solid free options, and managed platforms like Modular DS centralise the logs across all your client sites in one place. Forward critical alerts to a channel you actually check, like Slack or Telegram, because an alert in an inbox you do not read is not an alert.

9. Subscribe to security bulletins

Vulnerabilities do not announce themselves on your dashboard. They get disclosed in mailing lists, on the WordPress.org security blog, in vendor advisories and on services like Patchstack and WPScan, and the faster you hear about a critical CVE in a plugin you use, the faster you patch.

A minimum useful diet looks like this: the WordPress Core development blog, the wp-hackers security mailing list, and the changelog or social account of every plugin you depend on for critical functionality (membership, ecommerce, forms). For the rest, Patchstack weekly digest or the WPScan feed catches the big stuff. Pay particular attention to plugins that go quiet — if a plugin you rely on has not been updated in twelve months, start looking for an alternative now, before a CVE forces you to migrate in a panic.

Final words

Hardening a WordPress site is not a weekend project, it is a habit. Updates run weekly, plugin audits happen every few months, backups get tested, WPScan runs every now and then, and 2FA stays on for everyone. None of these items is hard on its own, and together they put you well ahead of the vast majority of sites that get compromised through neglect rather than skill.

If you would rather work from a printable list than try to remember it all, we keep a step-by-step security checklist you can use as your monthly routine.

Treat the site like the asset it is, give it the maintenance it needs, and you will spend a lot more time growing it and a lot less time recovering from incidents.