Almost nothing that compromises a WordPress site is clever. Sites are not usually targeted; they are found by scripts working through a list of known holes, and the hole is nearly always something that was already fixed months earlier by an update nobody applied.
That is the good news, because it means the defences that matter are dull, cheap and mostly free. It also means the things people spend money on — a security plugin with a dashboard full of green ticks — are rarely the things doing the work.
Here is what actually gets sites broken into, in order, and what to do about each.
How sites are actually broken into
- An out-of-date plugin. This is the overwhelming majority. A vulnerability is published, a fix ships the same week, and scanners start sweeping the internet for sites still running the old version. The window between disclosure and mass exploitation is days.
- An abandoned plugin. Worse than out of date, because no fix is coming. Plugins get removed from the directory quietly and stay installed on your site indefinitely.
- A nulled theme or plugin. Pirated commercial code, downloaded free from somewhere. A meaningful share of it ships with a backdoor already in it. You are not being attacked here; you installed the attacker.
- A reused or guessable admin password. Credential stuffing against
wp-login.phpcosts an attacker nothing. If your admin password appears in any past breach, it is already being tried. - The hosting account, not the site. Shared hosting with several sites in one account means the weakest site compromises all of them. So does an old FTP password stored in an editor on a machine with malware on it.
Notice what is absent from that list: anything requiring skill, and anything about your business being interesting. Most compromised WordPress sites are used to send spam, host phishing pages or inject links. The attacker does not know or care what you sell.
The things that actually work
In priority order. The first three do more than everything below them combined.
- Update, on a schedule, with a way to undo it. This is the whole game. Not automatically and unattended on a site that earns money, because an update can break a checkout as easily as it can close a hole — but weekly, on staging first, with a backup taken before. Uptake is what separates sites that get hacked from sites that do not.
- Delete what you are not using. Deactivated plugins and unused themes are still files on the server and are still exploitable. Deactivating is not removing. Every plugin you delete is a vulnerability you can never have.
- Two-factor authentication on every administrator. It ends password attacks outright. It takes ten minutes to set up and it is the highest-value thing on this page after updating.
- Unique passwords, from a password manager. For WordPress, for hosting, for the database, for FTP. Different ones. The most common route into a “WordPress” hack is a hosting password that was reused somewhere that got breached.
- The right role for each person. Everybody is an Administrator on most sites we look at. People who write posts should be Editors or Authors. An account that cannot install a plugin cannot be used to install a backdoor.
- Off-server backups you have actually restored from. A backup stored on the same server as the site is not a backup — it is compromised along with everything else. And an untested backup is a hope. Restore one to a staging site once, so you know it works before you need it.
- Turn off file editing. One line in
wp-config.php—define( 'DISALLOW_FILE_EDIT', true );— removes the plugin and theme editors from the dashboard. It does not stop an intruder getting in, but it removes the easiest way to write code once they have. - Correct file permissions and a locked-down
wp-config.php. Folders 755, files 644, nothing set to 777 for any reason ever. Someone will tell you 777 fixes an upload problem. It fixes it the way removing your front door fixes a sticky lock.
What security plugins do, and what they do not
They are worth having. They are not a substitute for the list above, and they are frequently sold as if they were.
What they genuinely do well: rate-limit login attempts, add two-factor, alert you when a core file changes, and give you a readable log of who did what. The file-change alert in particular is one of the few things that will tell you about a compromise you have not otherwise noticed.
What they do less well than the marketing implies. A plugin-based firewall runs inside WordPress, which means the request has already reached your PHP before anything inspects it — a firewall at the edge, at your host or through a CDN, sees it earlier and costs your server nothing. Malware scanning finds the common signatures and misses obfuscated code that was written to be missed. And “hardening” toggles like hiding your WordPress version or moving the login URL are obscurity rather than security; they cut the noise in your logs, and a scanner that is actually looking is not fooled.
One clear rule: install one security plugin, not three. Overlapping plugins fight over the same hooks, produce contradictory alerts, and slow the site down. We have found sites running three scanners, none of them configured, all of them emailing.
Hosting is half of your security
The parts of this that WordPress cannot do for you belong to the host, and they matter as much as anything on the site itself.
A supported PHP version, because an unsupported one stops receiving security fixes entirely and a surprising number of live sites are on one. Account isolation, so a neighbour’s compromised site is not your problem. SFTP rather than plain FTP, which sends passwords in clear text. Automatic off-server backups. And a way to reach a human when something is wrong at 2am.
If your host cannot answer those questions, that is worth more attention than any plugin setting. Moving is a migration, from $299, and it can be done with no downtime.
If you think you are already compromised
Stop hardening and start diagnosing. Every measure on this page is prevention, and none of it removes code that is already running on your server. Locking the door does nothing about the person already inside.
Work out whether it is real first — how to tell if your WordPress site is hacked covers the two findings that settle it outright and the two symptoms that usually mean nothing. Then the order is: take a copy of the site as it is, including the infection, so there is evidence; change every password including hosting and database; clean or rebuild; and only then find the entry point. Cleaning without finding the entry point means being reinfected within days, which is why malware removal, from $199, is priced around finding it rather than around deleting files.
What this cannot fix
- Nothing here makes a site unhackable. Anyone promising that is selling something. Hardening reduces the chance and limits the damage; backups are what make a bad day survivable.
- A hardened site that is never updated is not secure. The single biggest factor is update discipline, and it is ongoing work rather than a one-off job. That is what a care plan is, from $299 a month.
- We cannot secure a site around a nulled plugin. If pirated code is running, the honest fix is to buy the licence or remove it. We will not build defences around a known backdoor and pretend the site is clean.
- Security does not survive shared credentials. If the admin password is in a shared inbox, on a whiteboard, or held by three former contractors, no configuration compensates for that. That part is yours.
Questions we get asked
Is WordPress secure?
WordPress core is well maintained and core vulnerabilities are rare and patched quickly. Nearly every compromise happens through third-party plugins and themes, or through credentials, rather than through WordPress itself. The platform’s reputation comes from its size — it runs a large share of the web, so it is the biggest target, and most of the sites running it are never updated. A maintained WordPress site is not the security risk it is often described as.
Do I need a security plugin?
One is worth having, mainly for two-factor authentication, login rate limiting and file-change alerts. It is not a substitute for updating, and it will not save a site running a plugin with a known hole in it. Install one, not three — overlapping security plugins conflict, generate contradictory alerts and slow the site down.
Should I turn on automatic updates?
For core security releases, yes. For plugins on a site that takes money, be careful — an unattended update can break a checkout at 3am with nobody watching, and a broken checkout costs more than most vulnerabilities. The right arrangement is updates applied on a schedule, tested on staging, with a backup taken first and someone who notices if something breaks. That is the argument for a care plan rather than for a checkbox.
Does hiding the login URL help?
It cuts the noise in your logs and stops the laziest automated attempts. It is obscurity, not security — anything genuinely looking will find the login. It is fine to do and it is not where your attention should go. Two-factor authentication on every administrator does far more, in about the same amount of time.
How often should a WordPress site be updated?
Weekly is a sensible rhythm for most sites, with security releases applied as soon as they appear rather than waiting for the next cycle. What matters more than the interval is that a backup is taken before and that someone checks the site afterwards — particularly the parts nobody looks at, like the contact form and the checkout, which are exactly where a bad update shows up.
Can you check whether my site is secure?
Yes. Send the URL through the contact form and the free written audit covers it: what is out of date, what is installed that should not be, whether anything looks already compromised, and what we would change in priority order. You get it in writing within two business days, with one fixed price if there is work worth doing — and if the site is in reasonable shape, the audit says that instead.