WordPress Security Hardening Checklist: 12 Steps to Lock Down Your Site

Why Hardening Matters More Than Cleanup

Removing malware from a WordPress site is like treating an infection - necessary, but not sufficient. If you don't strengthen your immune system afterward, the infection comes back. That's exactly what happens when site owners clean malware but skip hardening: within weeks, they're compromised again.

This checklist covers everything you should do after a malware cleanup - or better yet, before you ever get hacked in the first place.

The 12-Step WordPress Hardening Checklist

1. Change Every Password

Not just your WordPress admin password - every credential associated with your site:

• WordPress admin and all user accounts
• Database password (update wp-config.php to match)
• FTP/SFTP credentials
• Hosting control panel login
• Any connected API keys (payment gateways, email services, CDNs)

If an attacker had access to your wp-config.php, they have your database password. If they had database access, they could have dumped every user's hashed password. Assume everything is compromised and reset everything.

2. Update WordPress Core, All Plugins, and All Themes

Outdated software is the #1 attack vector for WordPress sites. After a cleanup:

• Update WordPress to the latest version
• Update every plugin - no exceptions
• Update every theme, including inactive ones
• Enable automatic updates for minor WordPress releases

Don't skip this step thinking "I'll do it next week." Attackers scan for known vulnerabilities in outdated plugins within hours of a CVE being published.

3. Remove Unused Themes and Plugins

Every piece of software on your site is a potential attack surface. That theme you tried once and deactivated? It's still hackable. That plugin you installed for a one-time task? It's still receiving requests.

Rule of thumb: If you're not actively using it, delete it. Keep only your active theme, a default WordPress theme as a fallback (like Twenty Twenty-Five), and the plugins you actually need.

4. Disable File Editing from the Admin Panel

WordPress includes a built-in code editor that lets administrators modify theme and plugin files directly from the dashboard. If an attacker gains admin access, this is the first tool they use.

Add this line to your wp-config.php:

define('DISALLOW_FILE_EDIT', true);

This disables the Theme Editor and Plugin Editor in the WordPress admin. You can still edit files via SFTP - which is both safer and more auditable.

5. Limit Login Attempts

WordPress doesn't limit login attempts by default, which makes brute-force attacks trivial. Implement rate limiting on wp-login.php:

• Install a reputable login security plugin
• Set a maximum of 3-5 failed attempts before lockout
• Lock out offending IPs for at least 15 minutes
• Consider implementing CAPTCHA on the login page

Better yet, use two-factor authentication (2FA) for all admin accounts. Even if an attacker guesses your password, they can't get past 2FA.

6. Set Correct File Permissions

Wrong file permissions are an open invitation. WordPress files should follow this permission scheme:

• Directories: 755 (owner can read/write/execute; group and others can read/execute)
• Files: 644 (owner can read/write; group and others can read only)
• wp-config.php: 600 (owner can read/write; no one else can access)

Never set files or directories to 777. If a plugin requires 777 to function, find a different plugin.

7. Implement a Web Application Firewall (WAF)

A WAF sits between your site and the internet, filtering malicious requests before they reach WordPress. It blocks:

• SQL injection attempts
• Cross-site scripting (XSS) attacks
• Known exploit patterns for popular plugins
• Automated vulnerability scanners

A WAF doesn't replace keeping software updated - it buys you time between when a vulnerability is discovered and when you apply the patch.

8. Set Up Automated Backups

Backups don't prevent hacks, but they're your safety net when one happens. Your backup strategy should include:

• Daily automated backups of both files and database
• Off-site storage - If your server is compromised, local backups might be too
• Retention of at least 30 days - You might not discover an infection immediately
• Regular test restores - A backup you've never tested isn't a backup

Make sure your backup solution stores copies outside your hosting account. A backup on the same server as your infected site is useless if the attacker deletes it.

9. Disable XML-RPC (Unless You Need It)

XML-RPC (xmlrpc.php) is a legacy WordPress API that's frequently abused for brute-force amplification attacks and DDoS. Unless you specifically need it (for Jetpack, the WordPress mobile app, or certain publishing workflows), block access to it entirely.

Most modern WordPress functionality uses the REST API instead of XML-RPC, so disabling it rarely breaks anything.

10. Secure wp-config.php

Your wp-config.php file contains your database credentials, security salts, and other sensitive configuration. Beyond setting 600 permissions:

• Move it one directory above your web root if your hosting allows it
• Add rules to block direct HTTP access to it
• Regenerate your WordPress security salts (these are used to hash session tokens)

If an attacker reads your wp-config.php, they have direct database access - making every other security measure irrelevant.

11. Set Up File Change Monitoring

You should know the moment any file on your site changes unexpectedly. File integrity monitoring:

• Alerts you when core files are modified
• Detects new PHP files in unexpected locations (like wp-content/uploads/)
• Logs all file changes with timestamps
• Provides a baseline to compare against after a suspected incident

This doesn't prevent attacks, but it dramatically reduces the time between compromise and detection - and faster detection means less damage.

12. Choose Secure Hosting

All the hardening in the world can be undermined by your hosting environment. Shared hosting, where hundreds of sites run on the same server, introduces risks no WordPress plugin can mitigate:

• Cross-site contamination through shared filesystems
• Shared PHP process pools that enable privilege escalation
• Resource contention from noisy neighbors
• Limited ability to configure server-level security

Isolated container hosting - where your site runs in its own environment with its own filesystem, processes, and network stack - eliminates an entire category of attack vectors. It's the single biggest security improvement most WordPress sites can make.

Hardening Is Not a One-Time Task

Security isn't a checkbox - it's an ongoing practice. After implementing this checklist:

• Review monthly: Check for new admin users, verify file integrity, review access logs
• Update promptly: Don't let updates sit for more than a week
• Audit annually: Review your plugin list, hosting setup, and backup strategy

Or consider a managed WordPress hosting solution that handles hardening, monitoring, and updates for you - so you can focus on your business instead of your server.