Securing WordPress: The Order That Pays Off

Search for “secure WordPress” and you'll find lists with twenty items. The problem isn't that the items are wrong, but that they sit side by side with equal weight. The first three do more than the other seventeen combined.

No. 1: Updates — and promptly

Most compromised sites don't fall to a sophisticated attack but to a known vulnerability in a plugin that has had an update available for weeks. Automated mass scans look for exactly that.

In practice, that means: security updates automatically, feature updates by hand after a quick check — and a restore point before every update, so that fear of the update doesn't become a reason to postpone it.

A plugin that hasn't received an update in two years is a risk, even if it works. Clean up while you're at it: whatever isn't used should be deleted, not deactivated.

No. 2: The login

The second most common door is a password. Four measures, in this order:

1. Limit failed attempts — that takes away the basis for automated guessing.
2. Enforce password strength, at least for everyone who is allowed to publish.
3. Turn on a second factor, at least for administrators.
4. No account with the username “admin,” and no role higher than necessary.

Moving the login URL is a fifth item, but a weaker one: it keeps mass scans away and saves load, but it doesn't replace any of the four measures above. If you use it, write down the new URL before you save.

No. 3: Hardening — set it once, then forget it

• Disable file editing in the backend — that's where malicious code is most often planted
• Disable XML-RPC if nothing needs it
• Prevent directory listing
• Block PHP execution in the uploads folder
• Restrict user enumeration via the REST API
• Set security headers

These toggles cost nothing in operation, and each one closes a known shortcut. They're the best effort-to-benefit item on the whole list.

No. 4: Seeing what changes

From here on, it's no longer about preventing but about noticing. Two things are worth it:

The core check compares the WordPress files with the checksums from api.wordpress.org. A changed core file is a very clear sign — nobody has a legitimate reason to change anything there.

The file monitor takes a baseline and reports deviations. It's only as good as the moment the baseline was taken: a baseline taken after an infection declares the malicious code the normal state.

Take the baseline while the site is verifiably clean — ideally right after a fresh installation or after a verified restore.

No. 5: Firewall and scan

Both make sense, and both are deliberately down here. A firewall in PHP only runs once WordPress is already starting — it doesn't replace a firewall in front of the web server. A scan finds what resembles its patterns, not all malicious code.

More important than the number of rules is how false positives are handled. A tool whose overview is permanently red no longer protects anything — it trains you to click things away. So first let the firewall only report for a week and go through the log before you let it block.

What often sits at the top and doesn't belong there

The point almost every list forgets

A security plugin prevents incidents; a backup survives them. If you had to choose between the two, take the backup — it's the only measure that still helps when all the others have failed.

Frequently asked questions