The WordPress Security Checklist for Small Businesses (No Paranoia Required)

Most WordPress security advice is written to scare you, usually with a premium plugin pitch at the end. This WordPress security checklist takes a calmer approach. The goal is not to make your site unhackable, because no site is. It is to make your site a harder target than the thousands of neglected sites automated bots scan every day. You do not need a security team to secure a WordPress site. You need a short list of habits, applied consistently.

Here is the honest framing: the overwhelming majority of WordPress compromises do not come from sophisticated attackers targeting you personally. They come from automated tools exploiting two things: outdated software (usually plugins and themes with known vulnerabilities) and weak or reused credentials. Fix those two categories and you have eliminated most of your real-world risk. Work through the sections below in order; the early items give the most protection per minute spent.

Keep Core, Plugins, and Themes Updated

This is the single highest-leverage item on the entire checklist. When a plugin developer patches a security flaw, the patch itself becomes a roadmap for attackers. Bots begin scanning for sites still running the vulnerable version, often within days. An outdated plugin is not a theoretical risk; it is a published, documented way into your site.

Concrete actions:

• Enable auto-updates for WordPress core. Minor releases (security and maintenance) update automatically by default. Leave that on.
• In the Plugins screen, enable auto-updates for plugins you trust and that are actively maintained. For business-critical plugins like WooCommerce, you may prefer manual updates after a quick check, but do them weekly, not "someday."
• Update your theme too. Themes ship PHP code just like plugins do, and vulnerable theme files are a common entry point.
• Check when each plugin was last updated in the plugin directory. A plugin abandoned for two years is a liability even if no vulnerability is public yet.

Set a recurring 15-minute calendar block every week. That is the entire maintenance budget for a typical small business site.

Use Strong Passwords and Two-Factor Authentication

The second big category of compromise is credentials. Attackers run automated login attempts against wp-login.php using lists of common passwords and credentials leaked from other services. If your admin password is reused from another account, or is something a wordlist would contain, this attack eventually works.

Concrete actions:

• Use a password manager and generate a unique, random password for every WordPress account, especially administrators.
• Add two-factor authentication (2FA). Well-known options include Wordfence Login Security, Two-Factor (maintained by core contributors), and WP 2FA. Any of these means a stolen password alone is no longer enough to log in.
• Require 2FA for every administrator and editor account, not just your own.
• Rename or delete the default "admin" username if your site still has one. Bots try it first.

Apply Least-Privilege User Roles

Every account is a potential entry point, and the damage an attacker can do is capped by that account's role. WordPress ships with a sensible role system; use it.

Concrete actions:

• Give people the lowest role that lets them do their job. A blog writer needs Author or Editor, never Administrator.
• Audit your user list quarterly. Remove accounts for former employees, old contractors, and agencies you no longer work with.
• If a developer or support tech needs temporary admin access, create a fresh account for them and delete it when the work is done, rather than sharing your own credentials.

Remove Unused Plugins and Themes

Deactivated plugins are not harmless. Their code still sits on your server, and vulnerabilities in that code can sometimes still be reachable. Every plugin and theme installed is attack surface, whether it is active or not.

Concrete actions:

• Delete, do not just deactivate, any plugin you are not actively using.
• Keep exactly one fallback theme (a current default theme like Twenty Twenty-Five) plus your active theme. Delete the rest.
• Before installing a new plugin, ask whether an existing plugin or a small code snippet already covers the need. Fewer moving parts means fewer things to patch.

Serve Everything Over HTTPS

HTTPS encrypts traffic between your visitors and your server, protecting login credentials and checkout details in transit. It is also a baseline trust signal: browsers warn users away from plain HTTP sites.

Concrete actions:

• Get a TLS certificate. Let's Encrypt certificates are free, and most decent hosts provision and renew them automatically.
• Set your WordPress Address and Site Address (Settings, then General) to the https:// version of your domain.
• Redirect all HTTP traffic to HTTPS at the server level so there is no unencrypted path to your site.
• Check for mixed content warnings after switching; a plugin like Better Search Replace can update old http:// URLs in your database.

Take Backups, and Actually Test Them

Backups are what turn a security incident from a catastrophe into an inconvenience, and a backup you have never restored is a hope, not a plan. The same backup methods covered in our migration guide apply here: whether you use a plugin like UpdraftPlus, host-level snapshots, or manual database exports, you are capturing files plus database. A migration is really just a restore to a new location, so testing your backups doubles as a migration rehearsal.

Concrete actions:

• Automate daily backups of both your files and your database.
• Store backups off-site (cloud storage, not the same server as the site). If the server is compromised, backups sitting on it may be too.
• Once a quarter, restore a backup to a staging site or local environment and confirm the site actually works.
• Keep at least two weeks of backup history. Some compromises are not noticed immediately, and you may need to restore from before the intrusion.

Limit Login Attempts

Out of the box, WordPress allows unlimited login attempts, which is exactly what automated password-guessing tools rely on. Rate limiting turns a brute-force attack from thousands of guesses per hour into a handful.

Concrete actions:

• Install a login limiting plugin such as Limit Login Attempts Reloaded, or use the login protection built into a security plugin like Wordfence.
• Lock out an IP after a small number of failures (five is a common default) with an escalating lockout duration.
• If your team logs in from fixed locations, consider restricting wp-admin access by IP at the server level for an even stronger control.

Disable File Editing in wp-admin

By default, WordPress includes a code editor inside the dashboard that lets administrators edit theme and plugin PHP files directly. If an attacker ever gains admin access, this editor is the fastest way for them to plant a backdoor. Almost no small business needs it.

Concrete action: add this line to your wp-config.php file, above the line that says "That's all, stop editing":

define( 'DISALLOW_FILE_EDIT', true );

This is a real WordPress constant, and it removes the theme and plugin file editors from the admin entirely. Legitimate code changes should happen through deployments or SFTP anyway, where they can be reviewed and reversed.

Keep PHP Current

WordPress runs on PHP, and old PHP versions stop receiving security patches. Running an end-of-life PHP version means known interpreter-level vulnerabilities go unfixed underneath your site, no matter how well you maintain WordPress itself. Newer PHP versions are also significantly faster, which matters if you care about performance topics like the ones in our guide to speed up WooCommerce.

Concrete actions:

• Check your PHP version in Tools, then Site Health.
• If you are below a currently supported PHP release, update through your hosting control panel or ask your host to do it.
• Test on staging first if you run older plugins, since very old plugins occasionally break on modern PHP.

Add an Activity Log

You cannot respond to what you cannot see. An activity log records who logged in, what was changed, which plugins were installed, and when. If something goes wrong, the log is how you reconstruct what happened and how far back your restore needs to go.

Concrete actions:

• Install an activity log plugin. WP Activity Log and Simple History are established options.
• Skim the log during your weekly maintenance block. You are looking for logins you do not recognize, unexpected new admin users, and plugin installs nobody on your team made.

Choose Hosting With Real Isolation

Everything above happens inside WordPress. This last item is about what sits underneath it. On traditional shared hosting, dozens of sites can run under conditions where a compromise of one poorly maintained site can spread to its neighbors. Your site's security then partly depends on strangers' update habits, which is a bad place to be.

The fix is host-level isolation: each site running in its own contained environment so a neighbor's compromise cannot cross over. This is one of the reasons we built Hosto the way we did: every site runs in its own isolated Docker container, with free SSL and daily backups included on all plans, so several items on this checklist are handled at the platform level before you install a single plugin.

Concrete actions:

• Ask your current host directly: are sites isolated from each other, and how?
• Confirm your host handles automatic TLS renewal and server-side backups, and find out what a restore costs.
• If you are comparing options, our breakdown of WordPress hosting cost covers what security features are typically bundled at each price tier, so you can tell what you are actually paying for.

Putting the Checklist Into Practice

A realistic rollout: this week, turn on auto-updates, set strong passwords, and enable 2FA. Next week, delete unused plugins and themes, add DISALLOW_FILE_EDIT, and install a login limiter. The week after, verify HTTPS, backups, and your PHP version, then add an activity log. After that, security becomes a 15-minute weekly habit plus a quarterly restore test. That is the whole program. No paranoia required.

FAQ

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

A security plugin like Wordfence is useful for login protection, malware scanning, and alerting, but it is a supplement, not a substitute. No plugin can save a site running two-year-old software with a reused admin password. Do the checklist first; add a security plugin as a monitoring layer on top.

How often should I update plugins?

Weekly is a sensible cadence for a small business site, with auto-updates enabled for low-risk plugins. If a plugin you use announces a security release, update the same day, because attackers move quickly once a vulnerability is public.

Is shared hosting safe for a business website?

It can be acceptable for a low-stakes site, but on poorly isolated shared servers your security partly depends on every other site on the machine. If your site takes payments or stores customer data, hosting with per-site isolation is a meaningful upgrade, not a luxury.

What should I do first if I think my site was hacked?

Change all passwords (WordPress, hosting, database, SFTP) from a clean device, then restore from a backup taken before the compromise. Update everything immediately after restoring, and review your activity log and user list for accounts or changes you do not recognize. If you cannot find a clean backup, a professional cleanup service is usually cheaper than doing it manually.