Start a Project

WordPress

WordPress security: the five things that actually matter

Most hardening advice is theatre. These five prevent nearly every real-world compromise we have cleaned up.

WordPress is not inherently insecure. Nearly every compromise we have been called in to clean traces back to one of five things, and none of them requires a security suite.

1. Out-of-date plugins and themes

This is the overwhelming majority. Attackers scan for known vulnerabilities in specific plugin versions; the exploit is published, and the scan finds you within days. Update promptly, remove what you do not use, and delete rather than deactivate.

2. Weak or reused admin passwords

Credential stuffing works because people reuse passwords. A long unique password and two-factor authentication on every administrator account closes this entirely. Also: stop using admin as a username, and make sure your author archive URLs do not enumerate usernames for you.

3. Unsupported PHP

Running PHP 7.4 in 2026 means running software that stopped receiving security fixes years ago. Check your version, upgrade to a supported one, and test on staging first because some old plugins will complain.

4. Too many administrators

The freelancer from 2021, the previous marketing manager, the developer who left. Every dormant admin account is a door. Audit the user list quarterly and demote anyone who does not need to install plugins.

5. No tested backup

This is not prevention, it is the thing that turns a disaster into an afternoon. Off-site, automatic, and restored to a test environment at least once so you know it works.

What is mostly theatre

Hiding wp-admin behind a custom URL. Removing the WordPress version from the page source. Disabling XML-RPC when nothing uses it anyway. These are not harmful, they simply do not stop a real attack. A security plugin that reports 400 blocked "attacks" a day is counting automated scans that would have failed regardless.

If you have been compromised

Do not just delete the visible spam. Take the site offline, change every password including the database and hosting, restore from a backup predating the compromise, then update everything before going live. Scan for modified core files and for PHP in the uploads folder, which should never contain any. And if personal data may have been accessed in the EU, remember the 72-hour notification duty under the GDPR — that clock starts when you become aware.

Working on something like this?

Tell us what you are building — we reply to every enquiry.

Start a Project