Most hacked WordPress sites were never specifically targeted — they were scanned automatically and compromised through outdated software, weak logins, or wide-open defaults. WordPress 7.1.3 shipped on October 6, 2026 as a security release with seven fixes, a timely reminder that security is a process, not a one-time setup. This WordPress security hardening checklist is the exact sequence I run through on client sites. Work through it once and you will close the holes that automated attacks look for first. Read the official WordPress 7.1.3 release notes here.
1. Update everything — then automate the small ones
Outdated core, themes, and plugins are the single most common way WordPress sites get compromised. Vulnerabilities in abandoned plugins are scanned for at scale within days of disclosure.
Update WordPress core, every active theme, and every plugin from Dashboard > Updates. Delete themes and plugins you do not use — code you do not run cannot be exploited. Then automate the security releases so you are not racing every patch:
// In wp-config.php, above "That's all, stop editing!"
define( 'WP_AUTO_UPDATE_CORE', 'minor' );This installs minor and security releases automatically while leaving major upgrades for you to review.
2. Strengthen logins: 2FA and attempt limits
Brute-force bots hammer wp-login.php around the clock. Two defenses matter here:
- Turn on two-factor authentication for every account that can publish, install plugins, or manage users. A free plugin like Wordfence Login Security adds TOTP-based 2FA (authenticator app) in minutes.
- Limit login attempts. Lock out an IP after a handful of failed tries. A firewall plugin, your host, or your WAF (see step 10) can do this.
Also audit the users list: remove accounts nobody owns, and make sure nobody logs in with “admin” as their username — it is the first guess every bot makes.
3. Give accounts the lowest role that works
A hacked admin account is game over; a hacked Editor account is a mess you can clean up. Give people the lowest role that lets them do their job — Editors rarely need to be Administrators. Review Users > All Users quarterly and demote anything that crept upward.
4. Disable XML-RPC if you don’t need it
xmlrpc.php is a legacy API used by the WordPress mobile apps, Jetpack, and a few older integrations. It is also a favorite brute-force and DDoS-amplification target because it allows many password attempts per request. Most sites do not need it — if you publish only from a browser and do not run Jetpack, you can turn it off.
The cleanest way is a server rule. On Apache, add to your root .htaccess:
<Files xmlrpc.php>
Require all denied
</Files>Verify it: a POST to /xmlrpc.php should now return 403. If you do use the mobile app or Jetpack, skip this one — breaking your publishing flow is not a security win.
5. Block PHP execution in the uploads folder
wp-content/uploads should only ever contain media — images, PDFs, video. If an attacker ever gets a malicious .php file into uploads, it should not be able to run. On Apache, create a .htaccess file inside wp-content/uploads:
<FilesMatch "\.(?:php[0-9]?|phtml|phar)$">
Require all denied
</FilesMatch>On Nginx, add the equivalent location rule in your server block. This is general hygiene, not a silver bullet — it blocks one of the most common payload paths.
6. Harden wp-config.php
wp-config.php holds your database credentials and secret salts, and a few constants make a real difference:
// Disable the in-dashboard theme/plugin code editor —
// a compromised admin account can't use it to inject PHP.
define( 'DISALLOW_FILE_EDIT', true );
// Force the admin and login pages over HTTPS.
define( 'FORCE_SSL_ADMIN', true );
// Never render PHP errors to visitors in production.
define( 'WP_DEBUG', false );
define( 'WP_DEBUG_DISPLAY', false );Also regenerate your security salts occasionally (the WordPress secret-key service issues fresh ones; changing them signs everyone out — a quick way to kill sessions after a scare). And set the file’s permissions to 600 — see the next step.
7. Set correct file and folder permissions
The baseline that keeps working on almost every host:
- Directories: 755
- Files: 644
- wp-config.php: 600 (or 640 if your host’s PHP runs under a different user)
Never use 777 — world-writable means any process on the server can modify your files. You can fix an entire install in one shot from SSH:
find . -type d -exec chmod 755 {} \;
find . -type f -exec chmod 644 {} \;
chmod 600 wp-config.phpRun it from the WordPress root and double-check your host’s documentation first — some managed hosts have their own ownership requirements.
8. Serve everything over HTTPS — and add HSTS
If your site still serves any page over HTTP, fix that before anything else: install a certificate (most hosts offer free Let’s Encrypt) and redirect all traffic to HTTPS. Then, once you are sure nothing loads over HTTP, add HSTS (Strict-Transport-Security) so browsers refuse to ever connect insecurely. A free Cloudflare plan in front of your site gets you both the redirect and HSTS in a few clicks.
9. Delete what you don’t use
Every inactive plugin and theme is code sitting on your server that still gets scanned for vulnerabilities. Keep one default theme as a fallback and delete the rest. Same for plugins: if you have not used it in six months, deactivate and delete it. Fewer moving parts, smaller attack surface.
10. Put a firewall in front of everything
A web application firewall (WAF) filters malicious requests before they reach PHP — blocking traversal patterns, known exploit signatures, and brute-force floods. Options that work well for WordPress: Cloudflare’s free plan (DNS-level, also handles the HTTPS redirect and HSTS from step 8), Wordfence’s free firewall, or Sucuri if you would rather have a fully managed option. This is the layer that catches the attack your other layers miss.
11. Back up automatically — and test the restore
Backups do not prevent hacks, but they are the difference between a bad afternoon and a lost business. Automate daily backups of both files and the database to off-site storage (your host’s storage is not off-site if the server is the thing that is compromised). Then, once, actually restore one to a staging folder. A backup you have never tested is a hope, not a plan.
12. Keep an eye on things
Finally, make monitoring a habit: Dashboard > Tools > Site Health flags real issues (debug display left on, outdated PHP, missing HTTPS), and an activity-log plugin records who logged in, what changed, and when — so you can tell the difference between “my site broke” and “someone broke my site.”
Wrapping up
WordPress security hardening is not about one magic plugin — it is about layering: updates, tight logins, least privilege, closed-off endpoints, hardened files, a firewall, and backups you trust. Work through this checklist once a year (and after every major change), and you will be a much harder target than the botnets are looking for. For a second reference, cross-check against this 2026 WordPress security hardening checklist.
Need help locking down or speeding up your WordPress site? I harden and optimize WordPress for clients — get in touch.
Further reading: How to Reduce Server Response Time in WordPress (TTFB) · How to Set Up Rank Math SEO on WordPress (Step-by-Step)