WordPress Security Checklist (24-Point)

The 12-point security checklist (printable)

You secure a WordPress site in twelve points, executed in this order — accounts first (cheapest, highest leverage), then login surface, then server, then hygiene, then recovery:

1. Updates current (core, plugins, themes)
2. Strong unique passwords on every account
3. Two-factor authentication on administrators
4. Correct admin usernames (no 'admin')
5. Login attempt limiting
6. XML-RPC disabled unless needed
7. HTTPS everywhere with SSL
8. Correct file permissions
9. Vetted plugins only, lean count
10. Security keys and wp-config protection
11. Tested backups (3-2-1)
12. WAF/firewall plus the monthly routine

A full first run takes an evening; the monthly re-run takes thirty minutes.

Account security — passwords, 2FA, admin usernames

The WAF layer. Wordfence's endpoint firewall — the free tier is competent, filtering malicious requests before they reach WordPress with rules auto-updating — or server/edge WAF configurations on managed stacks: the filter that catches what updates and passwords cannot.

The monthly routine — thirty minutes, calendar-recurring: run updates and verify the site after; audit the users list (orphaned administrators downgraded or deleted); verify the last scheduled backups succeeded off-site. Run the malware scan and read the result; glance at login logs and uptime monitors for anomalies. Monthly is the rhythm at which WordPress security is actually kept. When the list outgrows your week, WebJi®'s WordPress security services take the routine over.

Login protection — limits, renamed URLs, XML-RPC

Two practical notes on limit login attempts: it interacts directly with caching and database response, and misconfiguration is the most common cause of 'hosting is slow' tickets. WebJi® support checks it as part of standard migrations.

Server-side — SSL, permissions, PHP versions

The server layer, itemised:

• HTTPS: an SSL certificate on every site (free Let's Encrypt ships with WebJi® plans) and WordPress URLs set to https:// — logins over plain HTTP are network-readable credentials.

• File permissions: files 644, directories 755, wp-config.php locked to 600 where the server permits; world-writable 777 anywhere is an open door.

• PHP version: current 8.x — EOL versions stop receiving security fixes; staging-test the change first.

• Disable file editing: define( 'DISALLOW_FILE_EDIT', true ); in wp-config.php, so a compromised admin session cannot edit theme files.

• Directory listing off: .htaccess Options -Indexes guarantees it; block script execution in uploads where the stack permits.

Plugin and theme hygiene — vetting and updates

Two practical notes on file permissions 644/755: it interacts directly with caching and database response, and misconfiguration is the most common cause of 'hosting is slow' tickets. WebJi® support checks it as part of standard migrations.

Code and config — salts, wp-config protection, DISALLOW_FILE_EDIT

Security keys: the AUTH_KEY/SALT set in wp-config.php cryptographic-signs sessions and cookies. Rotating them — generate a fresh set from the WordPress salt API and paste — invalidates every existing session; do it after any suspected compromise and annually as hygiene.

wp-config.php protection: file permissions at 600, .htaccess deny rules blocking web access to it, and never committing it to repositories — it holds database credentials and salts. Database least-privilege: the WordPress MySQL user needs CRUD on its tables, not root. And environment hygiene: stray wp-config.php.bak files and old .sql dumps in web-root are secrets lying in public — scanners find them, and so do attackers. Move or delete them.

Backups and recovery testing

A backup you have never restored is a hope, not a backup. Keep a copy off the same server that hosts the site, and restore files and the database together so they match. On WebJi®, free migration of an existing site is available subject to terms and approval — open a ticket before the old host deletes the account.