WordPress Security Hardening: A Practical Checklist

Notice what isn't on that list: WordPress core itself. Core is audited and patched quickly, and minor releases install automatically by default. The risk is almost entirely in what's been added around it.

• An outdated plugin or theme with a publicly known vulnerability — by far the most common route in.
• Weak, reused or leaked passwords on an administrator account, found by credential stuffing or brute force.
• Nulled (pirated) premium themes and plugins, which frequently ship with a backdoor already installed.
• A neighbouring site on the same shared hosting account, when file permissions let one site reach another.
• An abandoned plugin that still works but no longer receives security fixes.

"Update everything automatically" and "update nothing until something breaks" are both bad policies. The first can take a site down on a Friday night; the second leaves a known hole open for months.

• Leave automatic updates on for WordPress minor and security releases.
• Update plugins and themes on a schedule — weekly is reasonable for most sites — and read the changelogs for breaking changes.
• Apply anything flagged as a security fix immediately, not at the next scheduled window.
• Test major updates on a staging copy first, especially on WooCommerce sites.
• Delete deactivated plugins and unused themes. Inactive code is still reachable code.

• One account per person, never a shared "admin" login — you cannot audit what you cannot attribute.
• No user literally named admin, and no account whose username matches the author slug shown publicly.
• Long, unique passwords from a password manager. Reuse is what makes credential stuffing work.
• Give each person the lowest role that lets them do their job. Editors don't need Administrator.
• Remove accounts when people leave the project — including the developer's, once handover is done.

Two-factor authentication on every administrator account is the single highest-value control on this list. Even a leaked password becomes useless on its own.

Pair it with rate limiting so brute-force attempts are throttled rather than merely logged. Limiting failed attempts per IP, and adding a CAPTCHA after a few failures, stops the automated traffic that makes up most login attempts.

• Directories 755 and files 644 as a baseline; wp-config.php can be 640 or stricter. Nothing should ever need 777.
• Set DISALLOW_FILE_EDIT to true in wp-config.php so nobody can edit theme or plugin code from the dashboard — that turns one compromised admin session into arbitrary code execution.
• Move or protect wp-config.php and .htaccess from direct HTTP access, and block PHP execution inside wp-content/uploads.
• Replace the default database table prefix on new installs, and generate fresh authentication salts in wp-config.php.
• Turn off directory listing, and keep WP_DEBUG_DISPLAY off in production so errors don't leak paths.

• Disable XML-RPC unless something genuinely needs it — it's a common brute-force and amplification target.
• Restrict or disable the REST API's user enumeration endpoints on sites that don't need public user data.
• Only allow the file types you actually accept in uploads.
• Keep staging and development copies behind HTTP authentication and noindex, so they don't become the forgotten way in.

A backup you have never restored is a hypothesis, not a backup. Ransomware and defacement are survivable with a good restore; they are business-ending without one.

• Automated daily backups of both files and database, kept off the web server itself.
• Keep enough history to reach back past a compromise you didn't notice for a week.
• Restore to a staging site at least once so you know the process and how long it takes.
• Store credentials for the backup service somewhere other than the site you're backing up.

• HTTPS everywhere, with HTTP redirected and HSTS enabled.
• Security headers: X-Content-Type-Options, X-Frame-Options or frame-ancestors, Referrer-Policy and a Content-Security-Policy where the site's assets allow one.
• A web application firewall in front of the site — at the host or a CDN — to filter known exploit patterns before they reach PHP.
• File integrity monitoring so changed core files are noticed quickly rather than at the next visit.
• Keep the hosting control panel and domain registrar accounts on 2FA too; they're the keys to everything else.

Some popular advice is mostly theatre. Renaming wp-login.php, hiding the WordPress version number and changing the admin URL all reduce noise in your logs without stopping a targeted attack. Do them if you like a quieter log, but don't count them as protection.

The same goes for stacking three security plugins. They overlap, slow the site down and conflict with each other. One well-configured plugin plus the server-level controls above does more.

• Take a full copy before changing anything — you'll need it to work out how they got in.
• Change all passwords and rotate the wp-config.php salts, which forces every session to log in again.
• Restore from a known-clean backup rather than trying to pick malware out of files by hand.
• Update or replace whatever was vulnerable before putting the site back online, or it will simply happen again.
• Check for accounts, scheduled tasks and uploaded PHP files that were added while they had access.

Security is maintenance, not a one-off project. If you'd like an existing WordPress site reviewed and hardened — or cleaned up after a compromise — send me the URL and a short description of what's happened, and I'll tell you what I'd do.