WordPress Hardening Checklist: 12 Fixes That Take an Afternoon

WordPress core is well-defended. What gets sites hacked is everything around it: vulnerable plugins, weak logins, default settings that leak information. Patchstack’s data makes the shape of the threat clear — nearly 8,000 new vulnerabilities a year, 96% of them in plugins.

Here are twelve fixes, each concrete, most reversible in a minute if something breaks. An afternoon covers all of them.

Reduce what attackers can learn

1. Hide the WordPress version.

remove_action('wp_head', 'wp_generator');
add_filter('the_generator', '__return_empty_string');

Also delete readme.html from the site root — it announces your version to anyone who asks.

2. Stop user enumeration. Attackers harvest your admin username from /?author=1 redirects and the REST API (/wp-json/wp/v2/users), then brute-force it.

// Block ?author=N scans
add_action('template_redirect', function () {
    if (is_author() && !is_admin()) { wp_safe_redirect(home_url('/'), 301); exit; }
});
// Hide the users endpoint from anonymous requests
add_filter('rest_endpoints', function ($endpoints) {
    if (!is_user_logged_in()) {
        unset($endpoints['/wp/v2/users'], $endpoints['/wp/v2/users/(?P<id>[\d]+)']);
    }
    return $endpoints;
});

3. Disable XML-RPC unless you actually publish remotely — it’s a classic brute-force amplifier:

add_filter('xmlrpc_enabled', '__return_false');

Lock the doors that matter

4. Strong, unique admin passwords + 2FA for every administrator account. This single habit defeats the most common attack there is. And no account named admin.

5. Rate-limit the login. Whether via your host’s tools or a lean snippet/plugin, failed-login throttling turns brute force from a threat into noise. Bonus: your login page doesn’t need to advertise which credential was wrong — generic error messages are fine.

6. Least privilege. Editors edit, authors write. The number of Administrator accounts on a normal business site is one, maybe two. Every extra admin is a second master key in circulation.

Close the built-in loose ends

7. Disable the file editor. By default, any compromised admin session can edit theme PHP right in the dashboard — turning a stolen cookie into remote code execution:

define('DISALLOW_FILE_EDIT', true); // wp-config.php

8. Correct file permissions. Directories 755, files 644, and wp-config.php at 600 if your host allows. Nothing under wp-content/uploads should ever be executable.

9. Turn off debug display in production:

define('WP_DEBUG', false);
define('WP_DEBUG_DISPLAY', false);

Stack traces are documentation for attackers.

Shrink the attack surface

10. Delete — don’t just deactivate — unused plugins and themes. Deactivated code is still exploitable code sitting on disk. A third of disclosed vulnerabilities had no patch at disclosure; the only complete fix for a plugin you don’t use is its absence. (Full method: the plugin audit.)

11. Update on a schedule. Weekly is fine for most sites: core minor updates auto, plugins reviewed and updated, one quick smoke-test after. Pair with the backup rule below and updates stop being scary. More in maintenance that protects.

12. Backups that restore. Off-server, automated, tested. A backup you’ve never restored is a hope, not a plan. This is your actual last line of defense — ransomware, botched updates, hosting failures all end the same way: restore and move on.

Finish with the headers

Hardening the application is half the job; the other half is telling browsers how to treat your site — HSTS, CSP, X-Frame-Options and friends. That’s a separate afternoon: security headers without a plugin.

Then verify from the outside: our free Site Analyzer checks HTTPS, exposed version, mixed content and all six security headers in one scan. Twelve fixes, one afternoon, and your site quietly drops out of the “easy target” pool — which is where the overwhelming majority of attacks are aimed.