Most WordPress compromises are not sophisticated. They are an outdated plugin with a known vulnerability, an admin password that has not changed in years, or a theme nobody has updated since the site launched. The fixes are unglamorous, and that is exactly why they get skipped.
The non-negotiables
- Core, theme and plugin updates applied on a schedule, not "whenever someone notices" - staged first if the site is business-critical
- Two-factor authentication on every admin account, with unique logins per person, no shared credentials
- A reputable security plugin doing file-integrity monitoring and login-attempt limiting
- Automated off-site backups, tested by actually restoring one occasionally rather than assuming they work
- Removing plugins and themes you are not using - installed-but-inactive is still installed
The ones people forget
Hosting-level hardening matters as much as anything inside WordPress itself: a Web Application Firewall in front of the site, disabling XML-RPC if nothing legitimately uses it, and locking down file permissions so a compromised plugin cannot write new files elsewhere on the server. None of this is visible to a visitor, which is exactly why it is easy to deprioritise until something goes wrong.
“A hacked WordPress site is rarely a sophisticated attack. It is usually a plugin that has been out of date for eight months.”
We run this checklist on every web development engagement and on every site we take over maintenance for, whether we built it originally or not. If you are not sure when your site was last properly audited, that is worth finding out before it becomes an incident - reach out and we will take a look.
