WordPress security audit in 5 practical steps

A security audit is a structured pass over the site: what is installed, who can log in, what is outdated or known-vulnerable, whether files look wrong, and whether backups restore. It is not a certificate and it is not a scare score.

WordPress is a common target because it is common. Small and mid-size sites get hit by automation as often as big brands. The fix is process, not panic.

For the longer loop (tools, prioritization, when to get help), use the WordPress security audit guide. Printable companion: security checklist.

What you are checking

1. Tools that surface configuration gaps and known issues
2. Recovery (backups you can restore)
3. Admin and user access
4. Unused or untrusted plugins and themes
5. Server and FTP/SFTP credentials

1. Run security checks you can act on

Install a security plugin you trust, or use the one you already have, and run the checks you will actually fix. Useful capabilities:

• Configuration / hardening tests
• Known vulnerability checks for plugins, themes, and core
• Login protection and alerts
• Optional malware scanning and file integrity
• Activity or event history when something looks wrong

Inside Security Ninja that maps to security tests, vulnerabilities, core scanner, and (Pro) malware scanner. Scanner types compared: scanner comparison.

Skip tools you will never open again. An unread report is not an audit.

2. Confirm backups and a restore path

Updates matter for stability and security. Backups matter when an update, mistake, or malware incident goes wrong.

During the audit:

• Confirm automatic backups exist (host, plugin, or both)
• Confirm copies land offsite, not only on the same server
• Note retention (how many days/weeks you keep)
• Schedule or perform a restore to staging if you have never done one

Habits: WordPress backup tips. Buyer notes: backup and security plugins.

Also check that core, plugins, and themes are current while you are in the dashboard. Updates and backups belong in the same sitting.

3. Review admins and user roles

Not everyone needs Administrator. Writers rarely need plugin installs. Apply least privilege.

Audit checklist:

• List every user; remove accounts you do not recognize (after confirming they are not a forgotten contractor)
• Count Administrators; demote people who only need Editor or Author
• Avoid the username admin when you can; create a new admin with a better name, reassign content, delete the old one
• Turn on 2FA for remaining admins

Roles explained: WordPress user roles. Login hardening: login security guide.

4. Remove unused themes and plugins

Inactive plugins and themes still sit on disk. They add attack surface and clutter. During the audit:

• Delete what you do not use (not only deactivate)
• Investigate anything you do not recognize; unexpected plugins after a compromise are common
• Remove nulled or pirated packages immediately; they often ship malware

Keep one theme (and maybe a parent/child pair) and the plugins you need. Plugin risk overview: WordPress plugin security risks.

5. Review FTP/SFTP and hosting access

File transfer and hosting panel access bypass wp-admin entirely. Anyone with those credentials can edit PHP on disk.

In the host control panel:

• List FTP/SFTP accounts; remove stale ones
• Rotate passwords for accounts that remain
• Prefer SFTP/SSH keys over plain FTP when the host allows it
• Review who has panel login (and 2FA there too)

Related incident pattern: leftover “helpful” server tools that outlive a developer handoff (helpful backdoor).

Wrap-up

Five passes cover most DIY audits: run checks, prove recovery, tighten users, shrink install surface, rotate server access. Revisit monthly, or after major site changes.

If you need the fuller process (priorities, tooling, when to escalate), stay with the security audit guide. If the site already looks compromised, switch to hacked site steps before rearranging settings for sport.