WordPress security checklist – quick, actionable steps
Follow a short checklist now: updates, strong admin credentials + 2FA, disable in-dashboard file editing, enable HTTPS, automated offsite backups, and limit…
Priya Nair
September 27, 2026
Updated September 27, 2026
7 min read
Quick answer: follow a short, actionable checklist now (updates, strong admin credentials + 2FA, disable in-dashboard file editing, enable HTTPS, configure automated offsite backups, limit login attempts) and use the detailed sections below for implementation and verification.
Quick checklist
Why security matters
Common compromise vectors are outdated components, weak credentials, and insecure plugins or hosts. The attack surface grows with every plugin, theme, and unmanaged account. For an authoritative overview, consult WordPress.org security documentation: https://wordpress.org/about/security/ , consulted September 27, 2026.
Security is not a single product. Use layered controls: patching, strong access control, hardened configuration, monitoring, and tested recovery plans. Each layer reduces risk; none eliminates it.
Update policy: WordPress core, PHP, plugins, themes
WordPress core release cadence changed in 2025; cite the WordPress Project announcement when describing cadence implications: https://make.wordpress.org/project/2025/04/16/a-new-cadence-for-wordpress-core/ , consulted September 27, 2026.
Recommended practice: apply security patches quickly for critical fixes and perform a weekly review for minor updates. Present timing as a recommended practice, not a guarantee.
PHP must be a supported version per host or php.net. Do not list specific minor versions here without citing php.net or the hosting provider; check the host docs before acting.
Plugin and theme updates should be reviewed for changelogs and compatibility. If a plugin shows no recent maintenance, consider an alternative or remove it.
Backups and recovery
Mandatory backup policy: backup both files and database, store backups offsite, automate schedules, maintain a retention policy, and perform periodic restore tests. WordPress documents backup best practices here: https://developer.wordpress.org/advanced-administration/security/backup/ , consulted September 27, 2026.
Example schedule (labelled as example): daily incremental, weekly full, monthly snapshot. Treat these numbers as examples; align with your provider’s capabilities.
Failover/restore checklist: verify credentials, update DNS TTL if needed, prepare to deactivate plugins after restore, and confirm functionality after restore. Always test restores in a staging environment before relying on them.
Access control: accounts, passwords, and 2FA
Enforce least privilege: limit the number of administrator accounts and review roles regularly. Role reviews should be scheduled.
Require strong passwords and use a password manager for shared secrets. Store break-glass recovery codes securely in an access-controlled vault.
Enforce two-factor authentication for all administrator accounts. Recommended implementations exist in the official plugin repository, for example WP 2FA: https://en-gb.wordpress.org/plugins/wp-2fa/ , consulted September 27, 2026.
wp-config.php and file-level hardening
Move wp-config.php above the webroot if possible. Use file permissions that prevent world-write access. Disable in-dashboard file editing by setting DISALLOW_FILE_EDIT and DISALLOW_FILE_MODS in wp-config.php. See the wp-config reference: https://developer.wordpress.org/advanced-administration/wordpress/wp-config/ , consulted September 27, 2026.
Ownership and permission commands vary by OS and hosting; do not run generic commands without validating them in your environment. Ask your server administrator to provide tested commands for your OS.
HTTPS, HSTS, security headers, and TLS
Require HTTPS site-wide. Certificates can be obtained via Let’s Encrypt or the hosting provider. Test TLS configuration and prefer modern cipher suites as recommended by your host or CA.
Implement security headers such as Content-Security-Policy, X-Frame-Options, and Referrer-Policy. Test headers in a staging environment before rolling them out to production to avoid breaking site features.
Plugins and themes: selection and lifecycle
Install plugins and themes from trusted sources. Review changelogs and support history before installation. Remove unused plugins and themes to reduce attack surface.
Avoid abandoned plugins with no updates; define “abandoned” only if you cite the plugin repository date on the publish day. Do not claim a plugin is permanently secure without vendor-published, dated audits.
Server and network protections (hosting-level)
Prefer managed hosts that provide account isolation and WAF, or implement a WAF/CDN. Provider docs must be cited when recommending a specific configuration.
Use SFTP/SSH instead of FTP. Disable XML-RPC if unused. Consider host-level tools such as fail2ban for brute-force protection. For infrastructure examples, consult AWS best-practices for WordPress: https://docs.aws.amazon.com/pdfs/whitepapers/latest/best-practices-wordpress/best-practices-wordpress.pdf , consulted September 27, 2026.
Monitoring and incident detection
Implement uptime checks, file integrity monitoring, and log retention. Configure alerting for suspicious activity. Regularly review logs and alerts.
When an alert indicates a possible compromise, isolate the site, take a snapshot, and follow the incident steps in the “After a compromise” section below.
Automated protections and safe defaults
Recommended wp-config constants and WordPress options include disabling file editing and disabling XML-RPC when unused. See WordPress hardening and wp-config docs: https://developer.wordpress.org/advanced-administration/security/hardening/ , consulted September 27, 2026 and https://developer.wordpress.org/advanced-administration/wordpress/wp-config/ , consulted September 27, 2026.
Enable automatic minor security updates where appropriate. Understand WordPress auto-update behavior before adjusting settings.
Checklist for launch and periodic reviews (operational calendar)
Label all timeframes as recommended practices; do not treat them as guarantees.
What to do after a compromise (incident response)
Immediate actions: take the site offline or put it into maintenance mode; collect logs; snapshot files and database; rotate all credentials; restore from a known-good backup; scan locally for malware; audit plugins and themes.
Legal and notification obligations vary by jurisdiction. This guide does not provide legal advice; consult an appropriate legal authority for reporting obligations.
Resources and references
Primary sources cited in this guide (full URLs and consulted date):
Can a security plugin prevent all hacks?
No. A plugin can reduce risk as part of a layered defense, but layered controls and good operational practices remain necessary.
Is automatic update safe?
Automatic minor security updates are recommended by WordPress for many sites. Test major updates in staging before applying to production.
What we do not know (do not publish as facts)
Final notes
For WordPress hardening guidance, consult the official WordPress hardening handbook: https://developer.wordpress.org/advanced-administration/security/hardening/ , consulted September 27, 2026. For backups, consult: https://developer.wordpress.org/advanced-administration/security/backup/ , consulted September 27, 2026. For release cadence context, consult: https://make.wordpress.org/project/2025/04/16/a-new-cadence-for-wordpress-core/ , consulted September 27, 2026.
Related guides
Priya Nair
Priya covers hosting, performance, security and backups. She reads changelogs and pricing pages so readers don't have to, and flags what changed since the last update.
Updated on September 27, 2026
