WordPress powers 40%+ of the web, which also makes it the most heavily targeted CMS by automated attack tools. Most compromises aren't sophisticated — outdated core/plugin versions, weak admin credentials, or nulled plugins with backdoors baked in. Here's a hardening checklist ordered by priority.
- Stay current — the cheapest security you'll ever get
Enable core auto-updates in wp-config.php:
php
define( 'WP_AUTO_UPDATE_CORE', true );
Plugin auto-updates can be toggled individually from the dashboard. If you're running custom development or version-pinned plugins, manual update control is safer — auto-updates that break something are harder to debug blind.
- Kill the low-hanging brute-force targets
Don't use admin as your username — it's the first string every attack tool tries. Passwords: 16+ characters, generated (not memorized), stored in a password manager. Then layer 2FA on top — Wordfence Login Security or the Two-Factor plugin, ~10 min setup, meaningfully closes the gap even if a password leaks.
- HTTPS, no exceptions
Free via Let's Encrypt, one-click on most hosts. After installing: update both WordPress Address and Site Address to https:// in settings, then (once on Cloudflare) enable Always Use HTTPS + Automatic HTTPS Rewrites to kill mixed-content warnings.
- One security plugin — not multiple
Overlapping security plugins conflict and tank performance. Pick one:
Wordfence — free tier includes WAF, brute-force protection, malware scanning. Free-tier firewall rules lag 30 days behind premium.
Solid Security (formerly iThemes) — friendlier config UI, DB prefix modification, decent free Site Scanner.
Sucuri — free tier is monitoring/logging only; paid WAF is solid but pricier, better suited to higher-traffic sites.
- Rate-limit login attempts
5 failures → 15-30 min IP lockout. Built into Wordfence/Solid Security, or use the lightweight Limit Login Attempts Reloaded standalone.
- Move off /wp-admin and /wp-login.php
Doesn't fix root-cause security, but filters out a large volume of automated scanning traffic. WPS Hide Login handles this. Critical: write down your new path immediately, and confirm you have SSH/FTP fallback access before you change it — locking yourself out is a real failure mode here.
- Backups — files AND database, both
Database-only backups can't restore themes/media. File-only backups can't restore orders/users. Tiered retention: 7 daily / 4 weekly / 3 monthly. UpdraftPlus free tier handles scheduled pushes to Drive/Dropbox/S3. Even if your host does automatic backups, keep an independent copy elsewhere — don't let both copies live on the same infrastructure.
- Cloudflare in front of everything
Free tier gets you CDN, basic DDoS mitigation, DNS. After switching nameservers, enable Bot Fight Mode, Browser Integrity Check, Security Level → Medium+. Cloudflare filters at the network layer before requests hit your server; your security plugin filters at the application layer after. They're complementary, not redundant — you need both.
- Delete, don't just deactivate
A deactivated plugin's files still sit on disk. If there's an unpatched vuln in those files, direct path access can still exploit it. Audit periodically: remove anything unused entirely, and flag anything not updated in 2-3 years or marked "untested" with the current WP version for replacement.
Never run nulled plugins/themes — injected backdoors are endemic in these, and they undermine every other item on this list.
- WooCommerce-specific additions
Audit admin/shop-manager role assignments periodically. Keep payment plugins (Stripe, PayPal) updated with priority — vulnerabilities here carry higher blast radius. Enable email alerts for orders and admin logins. Watch for anomalous refund patterns as a signal of account compromise.
If you do get compromised: take the frontend offline immediately, restore from the last known-clean backup, rotate all credentials, then audit for unfamiliar PHP files — wp-content/uploads is the most common webshell drop location since it's usually writable and rarely audited.
Full writeup with a cost breakdown table and additional context: [https://kuajingbase.com/en/articles/1cg02jkd-wordpress-security-guide-2026-a-10-step-checklist-to]
Curious what others are running for the login-path change — anyone using firewall rules to restrict /wp-admin to specific IP ranges instead? Seems more robust than obscuring the path.
