A WordPress security checklist covers the handful of controls that stop most real attacks: keep core, plugins and themes updated; use strong unique passwords with two-factor authentication; give each user only the role they need; harden configuration and file permissions; keep tested off-site backups; and monitor for changes so you notice problems early.
I keep this list short on purpose. Long checklists get ignored; this one gets done.
Why do WordPress sites get hacked?
Most compromised WordPress sites I have cleaned had at least one of these: a plugin or theme with a known vulnerability left unpatched, a nulled (pirated) premium plugin, a weak or reused admin password, or an old account nobody remembered. Attacks are mostly automated bots scanning for these weaknesses, not someone targeting you personally.
1. Updates
- Enable automatic minor core updates (on by default).
- Update plugins and themes regularly; enable auto-updates for well-maintained, low-risk plugins.
- Test major updates (especially WooCommerce and page builders) on staging first.
- Keep PHP on a version that still receives security support.
- Remove unused plugins and themes, see my plugin audit.
2. Accounts and login
- Unique, long passwords stored in a password manager.
- Two-factor authentication for every administrator and shop manager.
- No shared “admin” account; one account per person.
- Least privilege: editors do not need administrator rights.
- Remove accounts for people who left, and revoke unused application passwords.
- Rate-limit or protect the login page against brute force (host, firewall or plugin).
3. Configuration hardening
In wp-config.php:
define( 'DISALLOW_FILE_EDIT', true ); // no theme/plugin editor in admin
define( 'WP_DEBUG', false ); // never display errors in production
define( 'FORCE_SSL_ADMIN', true );
- Unique security keys and salts set.
- Database user has only the privileges WordPress needs.
wp-config.phpnot readable by other users on shared hosting.- Directory listing disabled.
- PHP execution blocked in
wp-content/uploads.
For Apache, a small .htaccess file inside uploads:
<FilesMatch ".(php|phtml|phar)$">
Require all denied
</FilesMatch>
4. File permissions
A common baseline is 755 for directories and 644 for files, with wp-config.php tighter where the host allows (for example 600 or 640). Never use 777. Exact needs depend on how your host runs PHP, so check its documentation.
5. HTTPS and headers
- Whole site on HTTPS with automatic redirects.
- HSTS once you are sure HTTPS works everywhere.
- Sensible security headers:
X-Content-Type-Options: nosniff, aReferrer-Policy, and frame protection. - A Content Security Policy if you can maintain it; start in report-only mode.
6. Firewall and bot protection
A web application firewall in front of the site (Cloudflare or your host’s) blocks a lot of automated noise before it reaches PHP, which also helps performance on slow servers. Combine it with login rate limiting.
7. Backups
- Automatic daily backups of database and files (more often for busy stores).
- Stored off-site, not only on the same server.
- Retention long enough to go back before an undetected infection.
- A restore tested at least once. An untested backup is a hope, not a plan.
8. Monitoring
- Uptime monitoring with alerts.
- Google Search Console verified, so security issues are reported to you.
- File change detection or malware scanning.
- Admin login notifications for administrator accounts.
- Periodic check for unknown admin users:
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered
Other useful commands are in WP-CLI commands.
9. Forms and spam
Contact and checkout forms attract bots. Use honeypots or a privacy-friendly challenge, validate server side, and never email raw uploaded files without restrictions. More in contact form best practices.
10. Incident response plan
If something looks wrong:
- Put the site in maintenance mode or block traffic if it is serving malware.
- Change all passwords: WordPress, hosting, database, FTP/SSH, and revoke API keys.
- Take a copy of the infected site for investigation.
- Restore a clean backup from before the infection, or clean manually: replace core, plugins and themes with fresh copies, inspect uploads and the database.
- Find and fix the entry point, or it will happen again.
- Request a review in Search Console if Google flagged the site.
Signs worth watching: search results showing pages in a language you never published, often Japanese or pharmaceutical spam, is a classic sign of an SEO spam infection.
Common mistakes
- Installing three security plugins that conflict and slow the site.
- Keeping backups only on the same server.
- Leaving staging copies public and unpatched.
- Giving every freelancer an administrator account forever.
Security is a habit, not a product. If you want a review of your site’s setup, contact me or browse my services. For the broader platform picture, see Laravel vs WordPress.
Frequently asked questions
Is WordPress secure?
WordPress core is actively maintained by a security team and receives automatic minor updates. Most risk comes from outdated plugins and themes, weak passwords and poor hosting.
Do I need a security plugin?
Not always. A good host, a web application firewall such as Cloudflare's, updates and two-factor login cover a lot. A security plugin can add login protection and file scanning if your host does not.
Should I change the wp-admin URL?
It reduces bot noise in logs but is not real protection on its own. Strong authentication and rate limiting matter more.
How do I know if my site is hacked?
Warning signs include unknown admin users, spam pages in search results, unexpected redirects, new files in uploads, and security warnings in Search Console.
