Knowledge · WordPress Web Design
WordPress Security Hardening: The Mid-Market Checklist
WordPress runs 43% of the web. That makes it the largest single target on the internet. ‘WordPress is insecure’ is a lazy take — the platform itself is fine. What gets hacked is the configuration around it: weak passwords, abandoned plugins, no 2FA, default wp-admin URLs, hosts that don’t isolate accounts. Here’s the 18-item checklist we apply to every mid-market site we ship.
№ 01The 5 causes of every WordPress hack we’ve cleaned up
We’ve cleaned up 40+ hacked WordPress sites in the last 5 years. Every one traced to the same shortlist:
- Admin account with a weak password. ‘Welcome2023!’ isn’t a password. Credential stuffing finds it in 4 minutes.
- An abandoned plugin with a known CVE. The plugin hasn’t shipped an update in 18 months. The vulnerability is published on WPScan. Bots have a list.
- No two-factor authentication. Once the password is compromised, there’s no second line.
- Cross-contamination on shared hosting. The site next door on Bluehost got hacked. The malware traversed the shared filesystem. Yours is now compromised too.
- An outdated PHP version. PHP 7.4 reached end-of-life in November 2022. Sites still running it have 3 years of unpatched CVEs.
Fix those five and you’ve closed 98% of the attack surface. The remaining 2% is sophisticated and rare.
№ 02The hardening stack we apply
1. Security plugin: Wordfence Premium ($119/yr) OR Solid Security Pro (formerly iThemes, $99/yr). Pick one. Don’t run both.
2. 2FA enforced on all admin accounts: via the security plugin or Two Factor (free, official). Required, not optional.
3. Login URL changed: from /wp-admin to a non-guessable slug. Cuts brute-force attempts by 99%.
4. Login attempts limited: 5 failed attempts → 24-hour IP block. Built into Wordfence and Solid Security.
5. XML-RPC disabled unless actively needed for a specific integration. Most sites don’t need it.
6. REST API restricted to authenticated requests where business logic allows.
7. File permissions: 644 on files, 755 on directories, wp-config.php at 600.
8. Disabled file editing in wp-config.php: define('DISALLOW_FILE_EDIT', true);
9. Database table prefix changed from default wp_. Set during install.
10. SSL enforced site-wide via HSTS headers, not just a redirect.
11. WAF in front of the site: Cloudflare Pro ($25/mo) or your host’s WAF (Kinsta and WP Engine include one).
12. Daily off-site backups via BlogVault or Updraft Premium. Backups on the same server are not backups.
13. Plugin update cadence: 2×/month minimum on a staging environment first, then production.
14. Abandoned plugin audit quarterly: any plugin not updated in 6 months gets evaluated for replacement.
15. PHP 8.2+ enforced. 8.1 is acceptable through 2025. 7.x is unacceptable.
16. Admin accounts named anything but ‘admin’. ‘admin’ is the first username every bot tries.
17. Activity log enabled via WP Activity Log. You want to know what happened, when, by which user.
18. Disable PHP execution in /wp-content/uploads/ via .htaccess or nginx config.
№ 03The host matters more than the plugin
Wordfence on Bluehost shared hosting is theater. The most aggressive security plugin can’t protect against neighbor compromise on a shared server.
Managed WordPress hosting (Kinsta, WP Engine, Pressable, Pantheon, Cloudways) handles the infrastructure layer: isolated containers, automatic core updates, server-level malware scanning, server-level WAF, hardened nginx configs. The plugin layer becomes redundant defense, not first defense.
If you’re serious about security and you’re still on Bluehost, GoDaddy shared, or HostGator: move first. Harden second. Order matters.
№ 04What ‘security plugins’ can’t fix
Compromised admin credentials. If the password leaked and 2FA isn’t on, the attacker IS an authorized user as far as the plugin can tell. The login looks legitimate. The plugin won’t flag it.
Supply-chain attacks via plugin updates. A trusted plugin gets bought by a bad actor (it’s happened: AccessPress, August 2022). The next update ships malware. Your security plugin trusts the source. You’re compromised through the front door.
Zero-day vulnerabilities. By definition, the security plugin doesn’t know about them yet. Defense in depth is the only mitigation: WAF, isolated host, daily backups, monitoring.
№ 05Incident response: what to do when it happens
Step 1: Take the site offline. Maintenance mode plugin or host-level ‘suspend.’ Don’t let visitors land on compromised pages.
Step 2: Restore from the most recent clean backup (pre-compromise). Off-site backup, not server backup.
Step 3: Rotate all credentials: WordPress admin, hosting, database, SFTP, all API keys.
Step 4: Audit installed plugins. Remove anything you don’t actively use. Update everything remaining.
Step 5: Run a malware scan (Wordfence, Sucuri SiteCheck, MalCare) before bringing the site back online.
Step 6: Submit to Google Search Console for reconsideration if the site was flagged as deceptive.
Average incident response cost on a Care Plan: 4-8 hours. Off a Care Plan, expect $1,500-$4,000 from a WordPress security firm (Sucuri, WP Rescue).
⚠What to avoid
- Running 3 security plugins because ‘more is better.’ They conflict. They compete for the same hooks. They double-process every request. Pick one, configure it well.
- Using ‘hide my WP login’ plugins as a security strategy. Security through obscurity buys you 6 hours. Real hardening is configuration, not URL obfuscation.
- Trusting GoDaddy ‘Managed WordPress’ or Bluehost ‘WP Pro’ as security infrastructure. They’re shared hosting with a WordPress branded UI. Real managed WP (Kinsta, WP Engine) is structurally different.
Related questions
Go deeper
Three Ways to Start · No Sales Pitch
Want this analyzed on your site?
$500 audit. 5-day delivery. Refundable on engagement.