Most hacked small business sites are not hit by a clever, targeted attack. They are found by automated scanners looking for one known, already-patched flaw in a plugin, or for an admin account with a reused password. Hardening is about closing those easy doors, in the order that gives the most protection for the least effort.
This checklist is ordered that way. Do the first section this week, the second within a month, and turn the third into a routine.
Where attacks on small business sites actually come from
- Plugins and themes, not core. Year after year, security researchers such as Patchstack and Wordfence report that the vast majority of new WordPress vulnerabilities are in plugins and themes. WordPress core itself is rarely the entry point.
- Flaws that already have a fix. Many compromises use a vulnerability that was patched days or weeks earlier, on a site that simply hadn’t updated. Exploitation of popular plugins now often starts within hours of a public disclosure.
- Stolen or reused passwords. Credential stuffing uses password lists from other breaches. Limiting login attempts doesn’t stop it if the password is correct.
- Too much access. Old staff accounts, shared admin logins, agencies that never had their access removed, and hosting or FTP passwords nobody has changed in years.
Do these first (high impact, low effort)
1. Lock down admin accounts
- List every user with the Administrator role (
wp user list --role=administrator). Remove or downgrade anyone who doesn’t need full control. Editors can publish; they don’t need to install plugins. - One person, one login. Never share an admin account between staff.
- Enable two-factor authentication for every admin and shop manager. Passkeys are an even stronger option where your login plugin supports them.
- Use a password manager and unique passwords, including for hosting, database, SFTP and the domain registrar.
2. Update everything, and delete what you don’t use
- Update core, plugins and the active theme. Turn on automatic updates at least for minor core releases and for low-risk plugins.
- Delete inactive plugins and themes. Deactivated code is still on the server and can still be exploited directly. Keep one default theme as a fallback.
- Check for abandoned plugins: anything closed on WordPress.org, or not updated in over a year, should be replaced.
3. Make sure backups exist off the server, and that they restore
- Daily automatic backups of files and database, stored away from the hosting account (cloud storage, not just the same server). See backup plugins compared.
- Restore one to a staging site at least once. A backup you have never restored is a hope, not a plan.
Do these next (within a month)
4. Harden wp-config.php
define( 'DISALLOW_FILE_EDIT', true );removes the built-in theme and plugin code editor, a favourite tool for attackers who get into an admin account.define( 'FORCE_SSL_ADMIN', true );if your site isn’t already fully HTTPS.- Make sure the security keys and salts are set and unique. Regenerate them after any suspected breach; this logs everyone out.
- Set permissions: 644 for files, 755 for directories, and 600 or 640 for
wp-config.phpwhere your host allows it. Never 777.
5. Put a firewall in front of WordPress
A web application firewall blocks known exploit patterns before they reach PHP. Edge firewalls (Cloudflare, Sucuri, or one included with managed hosting) stop traffic before it hits your server. Plugin firewalls like Wordfence run inside WordPress. Either is far better than none. See security plugins compared for the trade-offs.
6. Reduce the login attack surface
- Limit failed login attempts, and add a CAPTCHA or proof-of-work challenge to login and registration forms.
- Disable XML-RPC if nothing you use needs it (Jetpack and some mobile apps do). It allows many password guesses per request.
- Moving the login URL cuts bot noise in your logs, but treat it as housekeeping, not protection.
7. Close common leaks
- Turn off directory listing (
Options -Indexeson Apache, or your host’s equivalent). - Block PHP execution in
wp-content/uploads. Uploaded files should never run as code. See file upload security. - Make sure
WP_DEBUG_DISPLAYis off in production, so errors don’t reveal file paths. - Review what the REST API exposes, especially user enumeration through
/wp/v2/users. - Remove old staging copies,
.zipbackups andphpinfofiles left in the web root.
Keep these running (monthly routine)
| Check | What you’re looking for |
|---|---|
| User list | New admins nobody recognises, ex-staff, agency accounts |
| Plugin list | Plugins someone installed without telling you; abandoned plugins |
| Updates | Anything pending more than a week, especially security releases |
| Backups | Last successful backup date, and a test restore each quarter |
| Security logs | Failed-login spikes, file-change alerts, malware scan results |
| Uptime and Search Console | Unexpected downtime, “security issues” or spam pages appearing in Google |
Write down a one-page incident plan as well: who to call, where the last clean backup lives, and how to put the site into maintenance mode. It saves hours on a bad day.
If you think the site is already hacked
Put it into maintenance mode, then follow a hacked site recovery checklist: restore a clean backup or clean the files, change every password and key (WordPress, hosting, database, SFTP), update everything, and find the entry point. If you skip the last step, re-infection within days is common.
Want this checklist done for you? We harden and maintain WordPress sites for small businesses: updates, backups, 2FA, firewall and monitoring. See our WordPress care services.
Frequently Asked Questions
Is renaming the wp-admin login URL worth doing?
It cuts automated bot noise, which makes real attempts easier to spot in your logs. It is a small, useful step, but no substitute for strong passwords and 2FA.
Do I need a security plugin if my host has a firewall?
Not necessarily for the firewall itself, but you still want login protection, 2FA and malware scanning from somewhere. Check what your host actually includes before adding overlapping tools.
How often should a small business site be reviewed?
Monthly is realistic for most small sites: users, plugins, updates and backups. Do a deeper review whenever staff or agencies change, or after any major plugin is added.
What single mistake undoes most of this checklist?
Sharing one Administrator login between several people. It removes accountability, and one leaked password exposes everyone’s access at once.