WordPress Security Audit: A Practical Checklist for Small Sites

A WordPress security audit is a structured review of your site's core files, plugins, themes, user accounts, file permissions, backups, logs and the server underneath them. You do it to find weak spots before an attacker does. For a typical small business site you can run the first pass yourself in an afternoon: take a tested backup, check for pending updates, review who has access, verify core files, read the logs, then fix what you found in order of risk.

This guide walks through that process step by step, with the exact checks, the commands, and the order in which to repair problems.

TL;DR

• An audit is a repeatable review of software, access, files, backups, logs and hosting, not a one-time scan.
• Start with a full backup of files and database, and test that you can restore it before you change anything.
• Fix active compromise first (unknown admins, changed core files), then known vulnerabilities, then lower-risk hardening.
• Combine automated checks with a manual look at users, plugins and logs; a scanner alone misses context.
• Repeat monthly, and again after any migration, new plugin or server move.

Table of Contents

• What a WordPress security audit covers
• Step 1: Back up first, and test the restore
• Step 2: Check hosting and server controls
• Step 3: Review core, plugins and themes
• Step 4: Audit users, roles and passwords
• Step 5: File permissions, configuration and database
• Step 6: Read the logs and watch for changes
• Tools that speed up the audit
• Step 7: Prioritize and fix what you found
• How often should you audit?
• Our perspective
• Make the audit easier with the right hosting
• FAQ
• Sources

What a WordPress security audit covers

Think of an audit as a health check for your whole site, not only the WordPress dashboard. It looks at five layers:

1. Software: WordPress core, plugins and themes, including whether they are current and still maintained.
2. Access: user accounts, roles, passwords and login protection.
3. Files and database: permissions, unexpected changes, and configuration.
4. Recovery: whether backups exist and actually restore.
5. Hosting: the server environment, HTTPS and the controls your host provides.

The official Hardening WordPress guide frames security in the same way: hosting, updates, passwords, file permissions, the database, backups and monitoring all count together, and a weakness in any one of them can undo the rest.

If you run a store, the audit has extra items: payment-related plugins, customer accounts and checkout pages. A roundup of security plugins for WooCommerce can help you decide which layer of protection to add once the audit shows what is missing.

An audit is also different from a malware scan. A scan answers one question: is something bad on the site right now? An audit asks why it could happen, who could do it, and how quickly you would recover. If you only want the malware side, our guide to two-step malware scanning on shared hosting covers it in detail.

Step 1: Back up first, and test the restore

Audits lead to changes: updates, deleted plugins, new permissions. Any of them can break a site, so the safety net comes first.

The Hardening WordPress guide says a sound backup strategy takes regularly timed snapshots of the entire installation, core files and database included, and stores them in a trusted location. It adds that encryption, independent hashes or read-only media give you more confidence the backups were not tampered with. You can read that in the official backup guidance.

A practical version for a small site:

• Export the database and copy the full file tree (wp-content, wp-config.php and any custom files).
• Store the copy off the server, not only in a folder on the same hosting account.
• Restore it to a staging copy or a local environment and click through the site: pages, forms, media, login, and checkout if you sell anything.

A backup you have never restored is a guess. Treat the restore test as part of the audit, not an optional extra.

Step 2: Check hosting and server controls

Many site owners audit WordPress and forget the layer it runs on. Ask these questions about your hosting:

• Is your PHP version still supported? Old PHP versions stop receiving security fixes.
• Is HTTPS valid on every page, and does the certificate renew automatically?
• Does your plan include daily backups you can restore yourself?
• Is there a web application firewall or edge protection in front of the login page?
• Who is responsible for server patching: you or the host?

On shared and budget plans the answers differ a lot between providers, which is why it pays to read your plan's actual feature list. Our website security guide for SMBs on WordPress and budget hosting explains what to look for, and the examples of site security features for small businesses shows what each control does in practice.

Add security headers to the list while you are here. They are a cheap hardening step, and we published copy-ready .htaccess and nginx snippets you can paste in.

Step 3: Review core, plugins and themes

Outdated software is the most common finding in any WordPress audit, so spend real time here.

Pending updates

WordPress Learn's security essentials tell site owners to open the Updates screen and look for pending core, plugin and theme updates. Do the same, and note the version numbers before you update so you can roll back. The WordPress Security Essentials activity is a good short reference.

Unused and abandoned plugins

The same page recommends deleting plugins that are unmaintained or redundant. Deactivated is not the same as removed: code that sits on the server can still be exploited. For each plugin ask:

• Do we still use it?
• Was it updated in the last year?
• Is it still listed in the WordPress.org directory, or has it been closed?
• Does another plugin already do the same job?

Every plugin you delete is one less thing to patch.

Themes

Keep one active theme and, at most, one default fallback. Delete the rest. Check that any child theme is not carrying copied code from an outdated parent.

Verify core files

The official WordPress developer blog recommends the WP-CLI command wp core verify-checksums, which compares your core files with the known files for your WordPress version and shows anything unexpected. See Website security checks with WP-CLI for the walkthrough. A modified core file is a red flag that deserves immediate investigation.

Step 4: Audit users, roles and passwords

Attackers often do not break in. They log in. Access review is cheap and catches a lot.

Open Users and check:

• Administrators: WordPress Learn advises limiting Administrator access, so downgrade anyone who does not need it. A writer needs Author or Editor, not Administrator.
• Unknown accounts: the WP-CLI guide says unexpected users, removed administrators or changed access can point to a dashboard compromise, or to an account created through executed files. If you do not recognize an account, treat it as an incident.
• Former staff and contractors: remove accounts for people who have left, and rotate shared passwords.
• Passwords and two-factor authentication: enforce strong, unique passwords and switch on a second factor for every administrator.

Then look at the login page itself. Brute-force attempts hit wp-login.php constantly. Rate limiting, blocking at the edge and a safe recovery path matter more than renaming the login URL, and we cover the setup in protecting the WordPress login on small sites.

Step 5: File permissions, configuration and database

The Hardening WordPress guide includes file permissions and database security in its checklist. For the audit, check these points:

• Permissions: files should not be writable by everyone. Follow the permission values in the official guide and avoid the quick fix of setting everything to 777.
• wp-config.php: confirm the authentication keys and salts are set and unique, and that debug output is off on the live site.
• Database: confirm the database user has only the privileges WordPress needs, and the password is not reused elsewhere.
• Exposed files: look for old backups, .sql dumps, readme files or test scripts sitting in public folders.
• Table prefix and leftovers: drop tables left behind by plugins you removed, after a backup.

Step 6: Read the logs and watch for changes

Logs tell you what actually happened, which a settings page cannot. According to WordPress.org, web-server logs can identify attack IP addresses, times and actions, including attempted cross-site scripting, file inclusion, directory traversal and brute-force attacks. File-monitoring tools such as diff, Git, inotify, Watcher and OSSEC can flag changed files. Both points come from the Hardening WordPress guide.

What to look for in access logs:

• Repeated POST requests to wp-login.php or xmlrpc.php from a single address
• Requests for plugin files you do not have installed
• Long query strings with script tags or SQL fragments
• Sudden traffic to a file in wp-content/uploads that is not an image

If you have no log access on your plan, that is itself an audit finding. A security plugin with an activity log can fill part of the gap by recording logins, setting changes and plugin installs.

Tools that speed up the audit

Automated tools save time on the repetitive checks. They do not replace judgment.

One option worth knowing about is the Security Check Report plugin on WordPress.org. Its listing says it runs 62 checks without changing settings, files or accounts, and explains each finding and how to fix it. The checks include PHP and WordPress support status, core checksums, abandoned or closed plugins, debug exposure, keys and salts, permissions, backups, administrator accounts, two-factor coverage, HTTPS, TLS, cookies, XML-RPC and user enumeration.

A read-only report like that is a fine starting point. Then do the manual parts yourself: read the user list, look at the logs, and test your restore.

Step 7: Prioritize and fix what you found

An audit that produces a list of forty items and no order produces nothing. Sort findings into three buckets.

Fix today: active compromise

• Unknown administrator accounts
• Modified core files or unfamiliar PHP files in uploads
• Spam content, redirects or a blacklist warning
• You are locked out of your own hosting or dashboard

Fix this week: known exposure

• Plugins or themes with a published vulnerability, especially without a patch available
• Abandoned plugins
• No second factor on administrator accounts
• Missing or untested backups

Schedule: hardening

• Security headers
• Tighter file permissions
• Removing leftover tables and files
• Log monitoring and alerting

That ordering follows a risk-based approach: contain what is already happening, then close what attackers can exploit today, then improve the baseline.

For each fix, work through the same loop: record what you found, decide the change, apply it, test the site, re-run the check that flagged it, and write down the result. The record matters. Next month you will want to know what changed and why.

When an update breaks something

It happens. The official WP-CLI guide says to check the site after updating, and if a core update causes trouble, revert with wp core update --version=<installed version> --force. Then ask a developer whether the plugin or theme that caused the break should be replaced, because code that fails on a minor release is likely to cause more problems later. The steps are in the WordPress developer blog post.

This is the reason Step 1 comes first, and the reason a staging copy is worth having. Test risky updates there, then push them live.

How often should you audit?

The Security Check Report listing recommends a monthly audit, plus another after any major change such as a migration, a new plugin or a server move. That is a sensible default for a small business site.

A simple rhythm:

Our website security checklist can serve as the recurring list, and the guide on securing your WordPress site for SMBs goes deeper on the hardening items.

Our perspective

Most small sites we see are not compromised by clever attacks. They are compromised by an old plugin, a forgotten admin account or a backup nobody tested. That is good news, because those are fixable with a routine.

We think the audit and the hosting should work together. Experienced SRE and DevOps engineers in the EU and US look after our infrastructure, and we build in the controls that make an audit shorter: daily backups, free migration, automated security and staging tools. When the server side is handled, your monthly review can focus on the parts only you can judge: who needs access, which plugins earn their place, and what your site must never lose.

Our advice is simple. Pick a day each month, work the checklist, write down what you changed, and keep a restorable backup within reach. A boring routine beats a heroic cleanup every time.

Ihor

Make the audit easier with the right hosting

An audit is much faster when your host already covers backups, malware protection and updates at the server level. inSave Hosting offers managed WordPress hosting built around WordPress management, with daily backups, free SSL, free migration, staging tools and automated security features, and a 30-day money-back guarantee. If you only need a simple site, our shared hosting plans include the same core protections, and larger projects can move to a VPS or dedicated server later.

Moving an existing site? We migrate it for free, so you can run your first audit on the new account with a clean, tested backup in place.

FAQ

How long does a WordPress security audit take?

For a small site, plan a few hours for the first pass, mostly spent on the backup test, user review and plugin cleanup. Later monthly checks go faster because you only look at what changed. Large stores and multi-author sites take longer.

Can I audit my WordPress site myself?

Yes, for the basics: updates, users, plugin cleanup, backups and a read-only report from a plugin. Bring in a developer when you find modified core files, unknown administrators or an update that breaks the site, since those need careful investigation.

Is a security plugin enough for an audit?

No. A plugin can automate many checks, but it cannot decide which administrators should exist or test whether your backup restores. Combine automated scanning with a manual review of users, plugins and logs.

What should I do if the audit finds a hacked site?

Take a backup of the current state for evidence, then remove unknown administrator accounts, replace modified core files with clean copies, and update or delete the vulnerable plugin that let the attacker in. Change all passwords and keys afterward. If you are unsure, ask your host or a WordPress security professional to help.

Sources

• Hardening WordPress, WordPress developer documentation
• WordPress Security Essentials, WordPress Learn
• Website security checks with WP-CLI, WordPress developer blog
• Security Check Report plugin, WordPress.org

Recommended

• Protect WordPress Login on Small Sites: Edge Blocking, Safe Recovery
• How to secure your WordPress site: proven steps for SMBs
• WordPress Security Headers: Copy Ready .htaccess and nginx Snippets
• Block Bad Bots on Small WordPress Sites Without Locking Out Users