WordPress Security Checklist: 15 Steps to Lock Down Your Site

Most WordPress security advice is either too vague ("keep your site secure") or too paranoid ("disable everything"). This checklist focuses on what actually prevents the majority of WordPress attacks, based on real breach data.

Work through these 15 steps in order. Each one closes a specific attack path, the same ones we map out in how WordPress sites actually get hacked.

The Basics (Do These First)

1. Update WordPress Core, Plugins, and Themes

This single step prevents more attacks than everything else on this list combined. Patchstack's 2026 report found that 91% of WordPress vulnerabilities come from plugins, and most exploits target known vulnerabilities in outdated versions. The pace hasn't slowed either: our August 2026 vulnerability roundup counted 929 new disclosures in a single month, 75 of them critical.

Enable automatic minor updates for WordPress core (enabled by default)
Update plugins within one week of new releases
Update themes the same way
Remove any plugin or theme you are not actively using. Inactive plugins are still attackable.

2. Use Strong, Unique Passwords

Wordfence blocks 65 million brute force login attempts every day. Many succeed because site owners reuse passwords from other services.

Every admin account needs a unique password of at least 16 characters
Use a password manager (1Password, Bitwarden, or similar)
Never share admin accounts. Create separate accounts for each person who needs access.

3. Enable Two-Factor Authentication

Even strong passwords can be stolen through phishing or data breaches at other services. 2FA adds a second layer, so a stolen or reused password alone no longer gets an attacker in.

Use a plugin like WP 2FA or Wordfence Login Security. Prefer authenticator apps (Google Authenticator, Authy) over SMS-based 2FA.

4. Remove Default and Unused Admin Accounts

Delete the default "admin" username if it exists. Remove any user account that is not actively needed. Every admin account is a potential entry point.

Check for suspicious accounts you did not create. This is a common sign of a previous compromise where the attacker created a backup account for re-entry.

5. Set Up Automated Backups

Backups do not prevent attacks, but they make recovery possible. Without a backup, a compromised site may mean starting from scratch.

Daily database backups (your content changes daily)
Weekly full-site backups (files change less often)
Store backups off-server (if your server is compromised, on-server backups are too)
Test restoration at least once. A backup you have never tested is not a backup.

Server-Level Hardening

6. Set Correct File Permissions

Wrong file permissions let attackers modify files they should not be able to touch.

Directories: 755 (owner can read/write/execute, others can read/execute)
Files: 644 (owner can read/write, others can read only)
wp-config.php: 600 (only owner can read/write, nobody else)

If your permissions are set to 777 anywhere, fix that immediately. 777 means any process on the server can read, write, and execute the file.

7. Disable File Editing in WordPress Admin

WordPress has a built-in code editor that lets admins modify plugin and theme files directly from the dashboard. If an attacker gains admin access, this editor lets them inject malware without needing FTP or SSH.

Add this line to wp-config.php:

define('DISALLOW_FILE_EDIT', true);

This disables the editor completely. You can still edit files via FTP or SSH.

8. Protect wp-config.php

Your wp-config.php contains database credentials, security salts, and other sensitive configuration. It should not be accessible via the web.

Ensure it has 600 file permissions
Delete any backup copies (wp-config.php.bak, wp-config.old, wp-config.txt)
Some hosts support moving wp-config.php one directory above the web root for additional protection

9. Disable Directory Listing

If directory listing is enabled, anyone can browse your file structure by visiting a directory URL. This reveals plugin names, versions, and file structure to attackers.

Add this to your root .htaccess file:

Options -Indexes

10. Remove Exposed Files

Debug logs, database backups, and configuration backups sitting in accessible locations are goldmines for attackers.

Delete or restrict access to:

wp-content/debug.log (contains error traces with file paths and query details)
Any .sql files in the web root (database dumps)
wp-config.php.bak, wp-config.old, wp-config.txt
phpinfo.php or any PHP info files
.git directory if present (exposes your entire version history)

A free WP Vanguard scan checks for 15+ exposed file patterns automatically.

Application-Level Security

11. Limit Login Attempts

Without rate limiting, attackers can try thousands of password combinations against your login page. Install a plugin that limits failed login attempts and blocks repeat offenders.

Most security plugins (Wordfence, Limit Login Attempts Reloaded) include this feature. Configure it to lock out IPs after 5 failed attempts for at least 30 minutes.

12. Change the Default Database Table Prefix

New WordPress installations use wp_ as the table prefix by default. While changing this alone is not a strong defense, it blocks lazy SQL injection attempts that assume the default prefix.

For existing sites, this requires careful database migration. For new installations, set a custom prefix (like wpx_ or site_) during setup.

13. Disable XML-RPC If Not Needed

XML-RPC (xmlrpc.php) is a legacy API that many sites do not use. It allows authentication without rate limiting and has been used in amplification attacks.

If you do not use the WordPress mobile app, Jetpack, or other services that require XML-RPC, disable it. On Apache, add this to your root .htaccess:

<Files xmlrpc.php>
    Require all denied
</Files>

On nginx, add location = /xmlrpc.php { deny all; } to the server block. A security plugin with an XML-RPC toggle does the same job if you can't edit server files.

14. Review and Regenerate Security Salts

WordPress uses security salts (defined in wp-config.php) to secure cookies and sessions. If your site has ever been compromised, regenerate them immediately.

Get fresh salts from the WordPress salt generator API and replace all eight constants in your wp-config.php. This instantly invalidates all existing logged-in sessions, forcing every user (including any attacker with a stolen session) to log in again.

15. Scan Your Site Regularly

All the hardening in the world does not help if you do not check whether it is working. New vulnerabilities are disclosed daily. A plugin that was secure last month might have a critical flaw today.

Monthly minimum: Run a free surface scan to check for known vulnerabilities, exposed files, and blacklist status
After any incident: Run a $1 deep scan to verify no malware or backdoors remain
Monitor Google Search Console for security alerts

Check That It Worked

A checklist you ticked off from memory is a checklist you haven't verified. With WP-CLI on the server, most of it can be checked in a minute, run from the site's root directory.

wp core version
wp plugin list --update=available --fields=name,version,update_version
wp user list --role=administrator --fields=user_login,user_email,user_registered
wp config is-true DISALLOW_FILE_EDIT && echo "file editing is off"
find . -type d ! -perm 755 -not -path "./wp-content/uploads/*"
find . -type f ! -perm 644 -not -path "./wp-content/uploads/*"

The first two show what needs updating, and the third lists every administrator so you can ask whether you recognise each one. The fourth confirms step 7, and the two find commands list anything that doesn't match the permissions in step 6. Some hosts deliberately use different values, so treat a result as a question to answer, not an automatic fix.

Where This Checklist Stops

Everything above happens inside the WordPress install and its files. Two layers sit outside it: the network in front of your site, with DNS, TLS and a firewall, and the server underneath it, with PHP settings, SSH and database access. A site can pass all fifteen steps and still be exposed through either one.

When you've finished, follow our guide to auditing WordPress security at every layer, which covers those two layers in the same order. Both use the same rule: fix what's exposed to the most people first.

How Often to Revisit It

Security isn't a one-off job, but not every step needs the same rhythm. A schedule that's easy to keep beats an ambitious one that lapses.

Weekly: plugin and theme updates, and a look at what's waiting. Our weekly patch list shows which fixes can't wait.
Monthly: a scan, and a glance at the administrator list.
Quarterly: a restore test from your backup, and a review of users, plugins and themes you no longer need.
After any incident or staff change: reset passwords, regenerate the salts in step 14, and remove accounts that shouldn't exist.

Put these in a calendar, because the steps you skip are the ones that depend on remembering.

The Priority Order

If you can only do five things, do these:

Update everything (plugins are where most vulnerabilities are found)
Use strong unique passwords + 2FA (stops credential attacks)
Remove unused plugins and themes (reduces attack surface)
Set up automated backups (enables recovery)
Scan monthly (catches what you miss)

Everything else on this list is valuable, but these five cover the vast majority of real-world attacks. Start here, then work through the rest as time allows.

Scan your site free to see how your current security stacks up.