WordPress Security Checklist: 20 Checks for Business Sites

Most compromised WordPress sites we are asked to clean were not beaten by anything clever. An administrator password was reused, a plugin went two years without an update, or a backup existed but nobody had ever restored it. This WordPress security checklist covers those ordinary gaps: twenty checks in five groups, each one something you can verify today.

Work through it with the site open in one tab and the hosting panel in another. Mark each check as pass, fail or "do not know". The third answer counts as a fail until you find out.

Accounts and logins

1. Every administrator is a named person who needs the role. Open Users > All Users and click the Administrator filter, or run wp user list --role=administrator. Each account should belong to one current member of staff or one current supplier. Downgrade the rest to Editor or Author, and delete accounts for people who have left.

2. No shared logins and no account called "admin". A shared login cannot be traced to a person and cannot be switched off for one of them. Give everyone their own account. If an old admin user exists, create a new administrator under your own name, log in with it, then delete the old one and assign its content to the new user.

3. Two-factor authentication is on for administrators and editors. WordPress core does not include a second login step, so this comes from a plugin or from single sign-on. Enforce it by role so it is not left to each person to opt in. The trade-offs between apps, email codes and passkeys are in our guide to securing the WordPress login.

4. Passwords are unique, and so is the mailbox behind them. Every admin password should come from a password manager and exist nowhere else. Check the email account each administrator uses too. Whoever controls that inbox can reset the WordPress password, so it needs its own strong password and a second factor.

5. Registration is closed, or new users get the lowest role. Under Settings > General, "Anyone can register" should be unticked unless the site needs sign-ups, and "New User Default Role" should be Subscriber (or Customer on a store). If that setting shows a higher role and nobody on your team changed it, treat the site as compromised.

Updates and installed code

6. Core, plugins and themes are current. Dashboard > Updates should be empty or close to it. Leave automatic updates for minor core releases switched on, because that is how security fixes arrive without anyone having to act.

7. Nothing inactive is left on the server. A deactivated plugin still has files on disk, and those files can still be requested directly. Delete inactive plugins, and delete unused themes except one default theme kept as a fallback.

8. Every plugin is still maintained and came from its author. On each plugin's WordPress.org page, look at "Last updated" and for any notice that the plugin has been closed. Commercial plugins should be installed from the vendor's account with a valid license, never from a "free download" site. Pirated copies are a common way for backdoors to arrive.

9. PHP is a supported version. Tools > Site Health > Info > Server shows the version in use. Compare it with the supported versions list on php.net. A branch that no longer receives security fixes is a server problem that no plugin can cover.

Server and configuration

10. The whole site runs on HTTPS. Both addresses under Settings > General start with https://, plain HTTP redirects to them, and wp-config.php contains define( 'FORCE_SSL_ADMIN', true ); so logins and admin cookies never travel unencrypted.

11. The built-in file editor is off. Add define( 'DISALLOW_FILE_EDIT', true ); to wp-config.php. This removes the theme and plugin editors from the dashboard, so a stolen admin session cannot be turned into edited PHP files in two clicks.

12. File permissions follow the official guidance. Directories at 755, files at 644, and wp-config.php readable only by your account and the web server (440 or 400). Nothing should be 777. The WordPress hardening guide explains the reasoning behind each value.

13. PHP cannot run from the uploads folder, and no leftovers sit in the web root. The media library has no reason to execute code, so block PHP in wp-content/uploads at the server. Then list the site's root folder and remove anything that is not WordPress: old .zip and .sql backups, phpinfo.php, copies such as wp-config.php.bak, and database tools left behind after a migration.

14. Login attempts are rate limited. WordPress does not cap failed logins on its own. Put a limit on wp-login.php at the firewall, CDN or web server, and block xmlrpc.php if nothing you use depends on it.

Backups

15. Backups run automatically and include both halves of the site. That means the database and the files, on a schedule that matches how often the site changes. Daily is a sensible floor for a business site, and a store needs the database copied more often than that.

16. A copy lives away from the server. A backup stored in the same hosting account disappears with the account, and an attacker who can write to the site can also delete it. Send copies to separate storage under a different login.

17. Someone has restored one. Pick a recent backup, restore it to a staging site, log in and click around. Note how long it took. Until this has been done once, you have files and no proof that they work. Schedules, retention and restore drills are covered in a backup strategy you can restore from.

Monitoring and response

18. You would hear about downtime and changed files. An uptime monitor should alert a person, not a shared inbox nobody reads. A security plugin or a scanner at the host should report new or modified PHP files. On servers with WP-CLI, wp core verify-checksums compares core files with the official release whenever you want a second opinion.

19. Admin activity is logged. An activity log plugin records logins, new users, role changes and plugin installs. After an incident this is how you tell what happened and when. Before one, a weekly glance is enough to spot an administrator account nobody remembers creating.

20. There is a written plan for a bad day. One page is enough: who decides, where the backups are, how to reach the host's support, who holds the domain registrar and hosting logins, and who has to be told. Add the site to Google Search Console as well, because that is where Google reports hacked content and malware it finds on your pages.

What to fix first when several checks fail

Do not try to fix everything in one sitting. The order that removes the most risk for the least work is usually this: a tested off-site backup (checks 15 to 17), then administrator accounts and two-factor (1 to 3), then pending updates and unmaintained plugins (6 to 8). The configuration items in the third group take minutes each once you have file access.

Run the list again every quarter and after any change of staff, agency or hosting. Most checks take seconds the second time. The ones that have drifted are the reason to repeat it.

When to hand the WordPress security checklist to someone else

A site owner who is comfortable in the dashboard and the hosting panel can complete most of this alone. Get help when a check needs server access you do not have, when the site takes payments or stores learner or patient records, or when the list turns up something you cannot explain, such as an unknown administrator or PHP files in the uploads folder. That last case is a cleanup job, not a checklist item, and it should be handled before anything else.

Keeping these twenty checks green month after month is the core of what a WordPress maintenance plan does. It suits teams that would rather read a short monthly report than run the list themselves. If the failed checks are spread across several sites or stacks, our wider maintenance and support service covers those as well.

Frequently asked questions

Do I need a security plugin if I follow this checklist?

A security plugin is the easiest way to get several items on the list: two-factor login, attempt limits, file change alerts and an activity log. It does not replace updates, backups or tidy user accounts. Choose one and configure it properly, because two or three overlapping security plugins tend to conflict and slow the site down.

How often should I run a WordPress security check?

Run the full list every three months and again whenever someone with access leaves, you change hosting or you switch agencies. Updates are the exception: look at those weekly, and apply security releases within a day or two.

Is WordPress secure enough for a business website?

Yes, when it is looked after. WordPress core has a dedicated security team and ships regular security releases. The incidents we see nearly always trace back to an outdated plugin, a reused password or a neglected server, which is exactly what this list is designed to catch.

Does my hosting company take care of security for me?

Partly. A good host secures the server and the network, and many add a firewall, malware scans and backups. No host manages your administrator accounts, decides which plugins you install or tests that your backups restore. Ask yours for a written list of what is included so you know which checks remain yours.