WordPress Security Audit Checklist: 25 Checks Before Hackers Find You

1. 11. Confirm the supported PHP and database versions. Unsupported runtimes accumulate known security issues and prevent plugins from receiving compatible updates. Test runtime upgrades on staging before changing production.
2. 12. Inspect file and directory permissions. Configuration files should not be writable by the public web process unless required. Look for world-writable directories, unexpected executable files in uploads, and ownership that differs from the rest of the installation.
3. 13. Protect wp-config.php and secrets. Database credentials, salts, API keys, and environment values should not be exposed in public repositories, backups, error messages, or downloadable files. Rotate secrets after staff or vendor changes.
4. 14. Review database users and privileges. The WordPress database account should be limited to the intended database and necessary operations. Remove old remote-access users and verify that database administration tools are not publicly exposed.
5. 15. Establish a clean-file baseline. File-integrity monitoring is useful only when it can distinguish approved deployments from unexplained changes. Confirm who receives alerts and how a changed file is investigated.

4. Application, API and Traffic Protection

1. 16. Check HTTPS and security headers. Redirect all HTTP traffic to HTTPS, review certificate renewal, and assess HSTS, content security policy, clickjacking protection, referrer policy, and MIME-sniffing protection according to the site’s functionality.
2. 17. Review XML-RPC and REST API exposure. Do not disable interfaces indiscriminately; determine which features depend on them. Restrict unnecessary methods, require authentication where appropriate, and test integrations after changes.
3. 18. Validate forms, uploads and custom code. Forms should use capability checks, nonces, server-side validation, and safe output escaping. File uploads need type, size, access, and storage controls rather than relying only on a filename extension.
4. 19. Audit the firewall configuration. Check whether protection exists at the CDN, hosting, server, or WordPress layer; confirm logging and rule ownership; and remove conflicting or duplicated controls that provide noise rather than coverage.

If you are deciding between endpoint and edge protection, use our practical comparison of Wordfence and Cloudflare for WordPress to understand where each control operates.

1. 20. Review spam and bot controls. Registration, login, checkout, search, comments, and contact forms can all be abused. Measure false positives as well as blocked traffic so security controls do not prevent legitimate customers from using the site.

5. Backups, Monitoring and Incident Readiness

1. 21. Verify backup frequency against business risk. A brochure site may tolerate a longer recovery point than a busy store. Define how much data the business can afford to lose, then make the backup schedule match that requirement.
2. 22. Confirm backups are offsite and protected. A backup stored only on the same hosting account can disappear with the site. Restrict access, retain multiple recovery points, and prevent public download URLs.
3. 23. Test a full restore. A successful backup notification is not proof that the archive can be restored. Periodically restore to an isolated environment and confirm files, database, media, users, orders, and integrations behave correctly.
4. 24. Check security, uptime and change alerts. Alerts should reach a monitored channel and include enough context to act. Test who responds outside business hours and what happens if the primary contact is unavailable.
5. 25. Maintain an incident-response record. Document hosting contacts, domain and DNS access, backup locations, responsible staff, escalation rules, customer-notification decisions, and the steps for preserving an infected copy for investigation.

How to Prioritize the Findings

Fix issues that provide direct access or prevent recovery first: unknown administrators, exposed credentials, actively exploited plugins, public backups, unsupported runtimes, missing offsite backups, and failed restore tests. Next address broad attack-surface problems such as unnecessary plugins, excessive permissions, weak login protection, and unmonitored file changes.

Lower-severity improvements should still be scheduled, but do not let cosmetic hardening distract from the controls that determine whether an attacker can enter, persist, or destroy the recovery path.

For a deeper implementation guide, read how to secure a WordPress website. If you need an independent review, our WordPress security service covers vulnerability assessment, hardening, monitoring, and a prioritized remediation plan.

What a Professional WordPress Security Audit Should Deliver

• A complete inventory of core, themes, plugins, users, integrations, hosting, DNS, and security controls.
• Evidence-backed findings ranked by likelihood, impact, and remediation effort.
• A clear distinction between confirmed vulnerabilities, configuration weaknesses, and optional improvements.
• Specific remediation steps, owners, and target dates rather than a generic scanner report.
• A recovery-readiness assessment covering backup integrity, restore testing, and incident contacts.
• A retest after critical changes are completed.

Security is not a one-time installation. Our WordPress maintenance and care plans combine tested updates, backups, monitoring, and ongoing review so the audit findings remain addressed after the initial project.

Frequently Asked Questions

How often should a WordPress security audit be performed?

Run a full audit at least quarterly for a business website and after major changes such as a redesign, migration, hosting move, or security incident. Updates, backups, uptime, and suspicious activity should be monitored more frequently.

Can a security plugin replace a WordPress security audit?

No. A plugin can scan files, block traffic, or enforce selected controls, but it cannot evaluate hosting access, staff accounts, DNS, backup recovery, business risk, custom code, and incident ownership as a complete system.

Does passing every check mean a WordPress site cannot be hacked?

No audit can guarantee that a website will never be compromised. Passing the checks reduces known exposure and improves detection and recovery, but new vulnerabilities, credential theft, hosting failures, and human error remain possible.

Should inactive WordPress plugins be included in the audit?

Yes. Inactive plugins and themes can still leave vulnerable files on the server. If an extension is not needed, delete it and retain a documented copy only where your recovery process requires one.

What should I fix first after a failed audit?

Prioritize active exploitation, unknown administrators, exposed credentials, unsupported software, vulnerable plugins, public backups, and failed restore tests. These issues can provide direct access or prevent reliable recovery.

Turn the Checklist into a Remediation Plan

A useful audit ends with verified changes, not a PDF that sits unread. If your review uncovers unknown accounts, malicious files, or spam pages, inspect the warning signs of a hacked WordPress site and move to containment. For preventive hardening and monitoring, request a scoped review through our advanced WordPress security service.