To harden a WordPress site, you work in layers: lock down how people log in, keep everything patched, reduce what is reachable from outside, put a filtering layer in front of the server, and make sure you would notice a compromise quickly. No single plugin does this. Hardening is a configuration you apply once and then maintain.
Here are the twelve steps that matter, roughly in order of how much protection they buy relative to the effort. Most sites are compromised through outdated software or a weak login, not a clever exploit, so the early steps carry most of the weight.
How attacks on small business sites actually work
Almost nothing is targeted. Automated scripts crawl the web looking for known vulnerable plugin versions and for login forms that accept unlimited guesses. When they find one, they try it. The site is not chosen, it is matched.
That is good news, because it means ordinary hygiene defeats most of it. The two conditions that get sites compromised are software with a known hole that was never patched, and an administrator account whose password can be guessed or was reused somewhere that leaked.
Once in, the usual goal is not defacement. It is quiet use of your site: spam pages for someone else’s SEO, redirects to scam destinations, mail relaying, or a foothold to sell on. That is why compromises often sit undiscovered for weeks.
How to harden a WordPress site in 12 steps
1. Remove the default admin username
If an account is called admin, half of every attack’s work is already done. Create a new administrator with a non-obvious username, log in as it, and set the old one to a subscriber role with a long random password. Never delete content-owning accounts outright.
2. Enforce strong, unique passwords on every account with access
Every administrator and editor account, plus hosting, SFTP, database and domain registrar logins. Unique per service, generated by a password manager. Most WordPress compromises that are not an unpatched plugin trace back to a password reused somewhere that was breached.
3. Turn on two-factor authentication for all elevated roles
This is the highest-value single change on the list. Two-factor makes a stolen or guessed password insufficient on its own. Apply it to every administrator and editor, not just your own account.
4. Rate-limit and protect the login form
Limit failed login attempts per IP, add a lockout period, and put a challenge on the form. Consider renaming the login URL — it stops a lot of unsophisticated bot noise, though treat it as tidiness rather than real security.
5. Keep core, themes and plugins updated on a schedule
Known vulnerabilities in outdated plugins are the single most common way sites get compromised. Weekly, tested on a staging copy, with a backup taken first. An update you have not applied is an open door that is publicly documented.
6. Remove everything you are not using
Every inactive plugin and unused theme is code still sitting on your server, still exploitable, and no longer being updated or watched. Deactivated is not safe; the files are still reachable. Keep only what is in use, and remove the rest rather than leaving it dormant.
7. Apply least-privilege user roles and review them
Nobody who writes blog posts needs administrator rights. Audit your user list and ask of each account: does this person still work with you, and do they need this level? Former developers and agencies with live admin access are a routine finding.
8. Harden file permissions and disable dashboard file editing
Directories at 755, files at 644, and wp-config.php tighter still. Disable the theme and plugin file editor in the dashboard, so a compromised admin session cannot immediately write PHP. Disable PHP execution inside the uploads directory, which closes a common path for uploaded shells.
9. Put a filtering layer in front of the site
A web application firewall at the edge inspects requests before they reach your server and blocks known attack patterns, injection attempts and bad bots. Edge WAF and DDoS protection also absorbs traffic floods that would otherwise take your hosting offline. This is the layer that protects you during the window between a vulnerability being published and your update being applied.
10. Enforce HTTPS everywhere and monitor the certificate
Valid certificate, all traffic redirected to HTTPS, no mixed-content warnings from assets still loading over HTTP. Then monitor the expiry date. Expired certificates take more small business sites out of action than attacks do, and the failure looks alarming to visitors.
11. Scan for malware and watch for file changes
Scheduled malware scans, plus file integrity monitoring that alerts you when core or theme files change unexpectedly. The second one is what shortens discovery time from weeks to hours, and discovery time determines how bad a compromise gets.
12. Keep tested off-site backups
Hardening reduces the odds. Backups determine what happens when the odds lose. Files and database, stored off-site, with a retention window long enough to reach back past a slow-moving infection, and tested by actually restoring one.
What each layer protects against
| Layer | What it stops | Effort |
|---|---|---|
| Two-factor on admin accounts | Stolen and guessed credentials | Low |
| Login rate limiting | Automated password guessing | Low |
| Scheduled updates | Known plugin and core exploits | Ongoing |
| Removing unused plugins and themes | Dormant vulnerable code | Low |
| Role and user audit | Over-privileged and stale accounts | Low |
| File permissions and editor lockdown | Escalation after a breach | Medium |
| Edge WAF and DDoS protection | Attack traffic and floods | Medium |
| Malware and integrity monitoring | Long undiscovered compromise | Medium |
| Tested off-site backups | Everything, after the fact | Medium |
Hardening mistakes worth avoiding
Installing three security plugins. They conflict, they duplicate work, they slow the site down, and the overlapping rules make it unclear what is actually enforced. One well-configured plugin plus the edge layer.
Treating security as a one-time setup. The configuration you applied last year does not cover plugins you installed since or vulnerabilities published since. This needs a cadence.
Hiding things instead of fixing them. Renaming the login URL and hiding your WordPress version are housekeeping. They are not substitutes for patching and two-factor.
Ignoring the hosting account. Your site can be perfectly hardened and still lost through a hosting login without two-factor, or a domain registrar account with a reused password.
Never checking that monitoring works. Alerts that go to an unread inbox, or scans that stopped running after a licence lapsed, are the same as nothing.
A maintenance cadence that keeps it hardened
- Weekly: core, theme and plugin updates on staging, then live, with a backup first. Review failed login patterns.
- Monthly: malware scan review, confirm backups ran and storage is not full, check the certificate expiry date.
- Quarterly: user and role audit, remove unused plugins and themes, restore a backup to staging, check the PHP version is still supported.
- Twice a year: full review of hardening settings, file permissions and firewall rules, plus a check on which third-party services still have access to the site.
Mark each item with a named owner and a specific day. Security work produces no visible result on a good week, which is exactly why it slides off a busy calendar.
Where to start if you only do one thing today
Turn on two-factor authentication for every administrator account and update everything that is currently behind. Those two actions close the two doors that nearly every compromise comes through, and both can be done this afternoon.
After that, work down the list in order. If you would rather have the current state assessed first — what is out of date, who still has admin access, whether the login is exposed — request that on the Free Website Audit page.