WordPress Security Best Practices That Hold Up Over Time

The four things that prevent most compromises

Across real incidents, the same small set of failures shows up again and again. Fixing these four removes the large majority of realistic attack paths, and everything else in this guide is refinement on top of them.

1. Keep components current. Outdated plugins and themes with public exploits are the most common entry point by a wide margin. This is not a preference, it is the control.
2. Protect administrator accounts. Unique passwords, two factor authentication, and no shared logins. Credential reuse is the second most common entry point.
3. Apply least privilege. Most people who have administrator access do not need it. Editor or author covers the actual job for the majority of content roles.
4. Keep working, tested backups off the server. Not on the same hosting account, and restored at least once so you know they work.

If time or budget is limited, stop reading after this section and do these properly. They outperform any plugin purchase.

Administrator access is the actual perimeter

Nearly every serious WordPress compromise ends with the attacker holding an administrator account, whether they exploited their way to one or simply logged in. Treating that account as the perimeter changes what you prioritise.

• Two factor authentication on every administrator, with no exceptions for the busy person.
• Unique passwords per account, generated and stored in a password manager, never reused from another service.
• Individual accounts, never a shared login, so that logs and revocation both work.
• A removal process, so accounts for former staff, agencies and contractors are deleted the week they stop working with you rather than three years later.
• Quarterly review of who holds administrator, which usually removes several people.
• Rate limiting on the login path so brute force attempts are throttled before they reach PHP.

The last one is worth doing at the edge rather than in a plugin, because a request blocked at the edge never consumes origin resources. The WAF guide covers the rule pattern.

Backups are a security control, and most are not tested

Backups are what caps the damage when everything else fails, and they are the control most likely to fail silently when it is needed.

Store copies off the hosting account, so a compromise or suspension of the account does not take the backups with it. Keep enough history to reach a point before a compromise you have not noticed yet, which realistically means at least thirty days rather than the last three. Back up files and database together so the restore is coherent. Then actually perform a test restore to a staging environment, because an untested backup is an assumption.

One caution: restoring a backup fixes the symptom, not the cause. If the vulnerable component is still installed after the restore, reinfection follows quickly. The cleanup guide explains why entry point analysis has to happen either way.

Where Cloudflare fits in the program

Edge protection is genuinely valuable and consistently oversold. What it does well is reduce volume: automated scanning, brute force attempts, scraping and application layer floods can be filtered before they consume origin resources. On a busy site that is the difference between a stable server and one falling over under noise.

What it does not do is fix the application. A WAF does not patch your plugin, remove a malicious administrator account or repair file permissions. Sites that treat Cloudflare as the security program tend to be well protected against generic scanning and wide open to the specific vulnerability they have.

The sensible order is application first, edge second. Once the site is maintained and hardened, add WAF rules matched to your endpoints, rate limiting on login and API paths, and bot controls tuned to your traffic. In that order, each layer adds real coverage instead of hiding a gap.

WordPress security questions