WordPress Security Checklist That Is Worth the Effort

Where risk actually comes from: outdated plugins and themes, weak or reused passwords, and abandoned code nobody maintains. Work through this list in order — the first four items prevent the overwhelming majority of real incidents, and everything after them is refinement.

1. Keep everything updated

• Leave core minor updates automatic. They are security releases.
• Update plugins and themes on a schedule, tested — see how to update WordPress plugins safely.
• Apply security patches immediately, not at the next scheduled window.
• Run a supported PHP version. Old versions stop receiving fixes; test the change first, per what breaks after a PHP update.

If you have disabled automatic updates, make sure a person is genuinely covering that gap — how to disable automatic updates covers what to replace them with.

2. Remove what you do not use

Every installed plugin and theme is code that can be exploited, whether it is active or not.

• Delete deactivated plugins rather than leaving them, per deleting a plugin completely.
• Delete unused themes, keeping one default theme as a fallback.
• Never install nulled or pirated plugins. Cracked commercial code is a well-established malware delivery route.
• Check whether each plugin is still maintained. "Last updated three years ago" is a risk assessment.

3. Fix authentication

• Long, unique passwords for every account, stored in a password manager.
• Two-factor authentication on every administrator account, at minimum.
• No shared logins. One account per person makes audit logs meaningful.
• Limit login attempts, so brute force costs the attacker time.
• Remove the account named admin if it exists, by creating a new administrator and deleting the old one with content reassigned.

If you are locked out while doing this, resetting the admin password is the way back.

4. Give out the least privilege that works

Most people who "need admin" need editor. Administrator means installing code, and that is a full compromise if the account is stolen.

• Audit Users regularly and remove accounts for people who left.
• Give clients editor or a custom role rather than administrator where possible.
• Review roles added by plugins, particularly ones that can see customer data — see WordPress user roles explained.

5. Keep backups you have restored

A backup is the only control that works after everything else has failed.

• Files and database together, off-site.
• Retention long enough to reach back past a compromise you noticed late.
• Tested restore, at least once. Details in how to back up a WordPress site.

6. Harden the configuration

A short list of constants in wp-config.php that are worth setting:

<?php
define('DISALLOW_FILE_EDIT', true);   // no theme/plugin editor in the admin
define('WP_DEBUG', false);            // never display errors in production
define('FORCE_SSL_ADMIN', true);      // admin over HTTPS only

Also:

• unique salts, regenerated after any suspected incident;
• correct file permissions — directories 755, files 644, wp-config.php at 640 or tighter, and never 777;
• HTTPS everywhere with a valid certificate, per fixing the not secure warning;
• block direct access to wp-config.php and remove any .bak copies of it from the web root;
• disable XML-RPC if nothing you use needs it.

7. Monitor, so you find out early

• File integrity monitoring, which catches modified core files quickly.
• Failed-login alerting, to spot credential stuffing.
• Uptime monitoring, which often reveals a defacement before a customer emails.
• Search Console messages, which is how many owners first learn they were flagged.

A security plugin covers most of this — the options are compared in the best WordPress security plugins.

8. Protect the surrounding accounts

The site is only as secure as the credentials that can reach it:

• hosting panel and SFTP/SSH, with keys rather than passwords where possible;
• the domain registrar account, which controls DNS and therefore everything;
• the email account used for password resets — compromise it and every reset link goes to the attacker;
• the local machine, since stolen FTP credentials usually come from an infected computer.

What matters less than the internet suggests

• Hiding the WordPress version. Attackers scan for vulnerable files, not version numbers.
• Renaming the login page. Reduces log noise; does not stop a targeted attempt.
• Changing the table prefix on an existing site. Real risk of breaking serialised data for negligible benefit.
• Blocking wp-includes wholesale. Breaks legitimate core assets, as CSS not loading shows.

Spend the effort on updates, credentials and backups instead.

If the site is already compromised

Stop hardening and start responding — cleaning first, then closing the entry point, then rotating every credential. The full sequence is in how to fix a hacked WordPress site.