WordPress powers a huge share of the web, which makes it a huge target — but the attacks are rarely sophisticated. Studying for my cyber security diploma at NED University confirmed what a decade of client rescues taught me: most compromised sites fall to the same five open doors, and closing them takes one afternoon.
Door one: stale plugins. Every plugin is third-party code with database access. Delete what you do not use, update what you do, and prefer plugins that are actively maintained over ones with more features. Door two: the admin username. Automated bots try “admin” first on every login form on the internet; renaming it removes half the noise from your logs instantly.
Door three: passwords without a second factor. A password manager plus two-factor authentication on every admin account is non-negotiable — it is free and it defeats credential-stuffing outright. Door four: file editing from the dashboard. One line in wp-config (DISALLOW_FILE_EDIT) means a stolen admin session can no longer inject code through the theme editor.
Door five: no offsite backups. Hardening reduces risk; it never eliminates it. A daily automated backup that lives somewhere other than the hosting account is the difference between a bad morning and a lost business. Test the restore once a quarter — an untested backup is a hope, not a plan.
None of this requires a security budget. It requires an afternoon, a checklist, and the discipline to repeat it every time you ship a new site.
Door one, in practice: plugins
The instinct is to keep a plugin around in case it is needed later. Deactivated is not removed — the files still sit on the server, and a vulnerability in a deactivated plugin is still reachable in many cases. Delete rather than deactivate.
When choosing between two plugins that do the same job, the deciding factor should be maintenance, not features. Check the last update date and whether the developer responds in the support forum. A plugin with fewer options and an active maintainer is a smaller long-term risk than a feature-rich one that was abandoned two years ago.
The same applies to themes. Most sites carry two or three unused default themes; keep one as a fallback for troubleshooting and remove the rest.
Door two: usernames and the noise problem
Renaming the admin account will not stop a determined attacker, and it is not meant to. What it does is remove the overwhelming majority of automated attempts, which matters for a practical reason: it makes your logs readable. When every failed login is noise, you cannot see the one attempt that was actually targeted.
While you are there, check the author archive. WordPress will often expose the real username publicly through author URLs, which quietly undoes the change unless the display name and login differ.
Door three: why two-factor is the single biggest win
Most compromises do not involve breaking anything. They involve a password that was reused on a site that leaked, and a bot that tried it here. That is credential stuffing, and it is the most common route in.
Two-factor authentication defeats it outright, because the stolen password is no longer sufficient. It is free, it takes ten minutes to set up, and it is the one item on this list I would keep if I could only keep one.
Door four: locking the file editor
The dashboard theme and plugin editor lets anyone with admin access run arbitrary code on your server through a browser. That is convenient roughly once a year and dangerous permanently.
Adding DISALLOW_FILE_EDIT to wp-config means a stolen admin session can no longer inject a backdoor that way. It costs you nothing, because editing production files through a browser was never a good idea in the first place.
Door five: backups that actually restore
The part people get wrong is location. A backup stored on the same hosting account as the site is not a backup — if the account is compromised or suspended, both go together. Offsite means a different provider entirely.
The other half is testing. Restore the backup somewhere — a staging site, a local environment — once a quarter and confirm the site actually comes up. Backups fail silently more often than anyone expects: a plugin stops running after an update, a disk fills, a scheduled task quietly dies. You find out either during a routine test or during an emergency, and only one of those is survivable.
What this checklist does not cover
This is baseline hygiene, not a security programme. It closes the doors that automated attacks walk through, which is where the overwhelming majority of WordPress compromises come from. It will not stop a targeted attacker with time and motivation, and it does not replace keeping the hosting stack patched.
It is also not a one-time job. New plugins arrive, staff leave with active accounts, and a site that was hardened eighteen months ago has usually drifted. Put the checklist in your calendar quarterly rather than trusting that it stayed done.
