# WordPress security audit: what 71 checks look at, and what they miss

What a WordPress security audit checks, how the score and grade are worked out, what snooze and not applicable do, how often it runs, and what it is not.

By M Asif Rahman, Oct 20, 2026. Updated Nov 7, 2026.

A WordPress security audit reads your site’s configuration and reports what is open, what is exposed and what is out of date, then gives you a score and a grade. The **BetterShield** audit runs 71 read-only checks, and it is not a malware scan: it looks at how the site is set up, not at what an intruder might have left on it.

If you are still comparing tools, [WordPress security plugin: six questions to ask before you choose](/blog/choose-wordpress-security-plugin/) covers the wider decision. This post stays with one thing, the audit itself: what it looks at, how it adds up the score, and what you can do with a result.

## Quick summary

- The audit is 71 read-only checks across access, exposure, updates and extensions, server settings and configuration. It changes nothing on your site.
- It runs when you activate the plugin and once a day after that. **Run an audit now** starts one whenever you want a fresh result. The score and Findings also update on their own after a fix or a settings change made in BetterShield.
- The score combines 60 points for setup essentials and 40 for site health, and an open critical finding caps it at 74. A snoozed finding still counts against the score. A finding you mark **Not applicable** does not.
- The scoring changed in BetterShield 1.1.3, so a score can move after you update without anything new going wrong. Recheck any `--fail-under` threshold you use in a script.
- It is a configuration audit. BetterShield has no firewall and does not scan for or remove malware.

## What a security audit is, and is not

A security audit compares your site against a list of known good settings and known weak spots. Is the sign-in page limited? Is PHP still supported? Is the WordPress version printed on every page? Each answer is a check, and a check that fails becomes a finding.

That is a different job from a malware scan, which looks inside files for code that should not be there. A configuration audit cannot tell you a site is clean. It tells you how well the doors are set up. The two questions are worth keeping apart, because a green grade says nothing about whether something is already inside.

[Wikipedia’s entry on vulnerability scanners](https://en.wikipedia.org/wiki/Vulnerability_scanner) describes the wider family of tools if you want the general background. For BetterShield, the rest of this post is what the audit does and does not cover.

## What the 71 checks look at

The checks fall into five areas, the same five that **BetterShield › Findings** uses as categories. The site’s [security checklist](/checklist/) lists every one with why it matters and what could break if you act on it.

| Area | What it covers | An example |
| --- | --- | --- |
| Access | Who can sign in, and how | Idle Admin accounts nobody has used in over six months, user profiles that visitors can list |
| Exposure | What a visitor can see or reach | Missing security headers, the dashboard file editor, the WordPress version on every page |
| Updates & extensions | Software that is out of date or not what it should be | Plugins closed on WordPress.org, or with no update for years |
| Server | The environment WordPress runs in | An outdated PHP version |
| Configuration | Settings and files WordPress relies on | Secret keys in wp-config.php that are missing or unchanged |

The readme also names installer or database tools left in the web root after a migration, a domain without SPF, DMARC or CAA records, and core and plugin files that no longer match the official copies. The [WordPress file integrity check](/blog/wordpress-file-integrity-check/) goes deeper on that last one.

Two of the 71 are the vulnerability checks: installed versions with known vulnerabilities, and vulnerability data that is old. They are optional and start off. Turn on vulnerability checks in Settings and BetterShield compares the plugins, themes and WordPress version you have installed against published advisories from BetterShield Hub. No Hub account or paid license is needed, and the matching of versions happens on your site. While the checks are off, the Findings screen says nothing was checked, which is not the same as nothing being vulnerable. It never shows an empty list as a clean result.

Here is what leaves the site when you turn them on: the slugs and versions of your components go to the Hub once a day, on request and after updates or removals, and the Hub sees your connection’s IP address. Nothing else is sent. BetterShield keeps the result with its age, and if a refresh fails it keeps the last good result and shows a warning instead of dropping it. Separately from advisories, the audit still flags plugins the WordPress.org directory has closed or that have had no update for years.

## How the score and grade are worked out

The score combines 60 points for setup essentials and 40 for site health. Setup findings use their own item weights; other findings reduce site health by severity. Any open critical finding caps the total at 74. A snoozed finding still counts; a finding marked not applicable does not.

The 60 setup points are split across 16 items, from your way back in and two-factor for privileged accounts to sign-in limits and a few hardening settings. The doc [Understand and improve your security score](/docs/security-score/) lists what each one is worth. BetterShield also gives credit for protection your host already provides, such as security headers your web server sends, folder listing it refuses, or backups and a way into the site that your host reports.

Site-health deductions apply only to findings outside setup essentials:

| Severity | Site-health points removed |
| --- | ---: |
| Critical | 10 |
| High | 5 |
| Medium | 2 |
| Low | 1 |
| Info | 0 |

Grades follow from the score: A for 90 to 100, B for 75 to 89, C for 60 to 74, D for 45 to 59 and F below 45.

Three rules keep the number honest. A snoozed finding still counts, because it is still open. A finding marked **Not applicable** does not count. And a check that could not run is never counted as a pass: the score card shows how many checks ran and how many could not, so a low-information result does not look like a clean one.

If you updated from a version before 1.1.3, run an audit first. Earlier versions scored from a single 100 with larger deductions, so a jump in your score across the update can come from the new calculation and the new checks, not only from fixes. The grade boundaries did not change. If you use `wp bettershield audit --fail-under` in a script, check its threshold against the new numbers.

Use the score to choose an order of work, then read the evidence before you change anything. We recommend starting with Critical and High findings. The doc [Understand your security score and grade](/docs/security-score/) has the details.

## Read a result: Findings, Explain and the status tabs

Open **BetterShield › Findings** for every saved result. The status tabs are **Open** (the default), **Snoozed**, **Fixed**, **Not applicable** and **All**. **Search findings** matches titles and areas inside the tab you are on, and **Group by** offers **Severity** (the default), **Finding**, **Category**, **Impact** and **Recommended action**.

Each row has **Explain**, which opens the facts behind it:

- **Why it matters**: the practical concern, in plain words.
- **Before you act**: what could break if you change it.
- **Effect on the score**: the severity and the points.
- **Evidence**: the values the check used.
- **Last checked**: how current that evidence is.

If an AI provider is connected to WordPress, **Explain this in plain language** can rewrite the recorded evidence, and **Explain my audit** summarizes the open findings. That is optional, and the audit works without it. The doc [Read and filter the Findings report](/docs/findings-report/) walks through the screen.

## What to do with a finding

You have four honest options, and they are not all “fix it now”.

1. **Apply Fix.** For findings with a matching one-click fix, **Apply Fix** applies the correction and records the change. It tells you what it did and offers **Undo**. All but one of the 30 fixes wait for your choice, and each has an undo that does not expire. Tick several rows and **Apply Fix (n)** applies the ones with a one-press fix together; if one cannot change its item, the rest still run, and the receipt lists what was skipped. Version 1.1.5 added direct fixes, each with **Undo**, for file permissions, folders anyone can write to, plugin updates, inactive plugins and themes, and dormant accounts.
2. **Do it by hand.** Other rows link to the WordPress or BetterShield screen that handles them. A finding about a public REST route works differently: it watches the route for a week before you can close it, as described in [requiring sign-in for a WordPress REST API route](/blog/wordpress-rest-api-require-sign-in/).
3. **Remind me later.** Choose **In 7 days** or **In 30 days**. The finding moves to **Snoozed**, stays open and still affects the score. It comes back on the date, or earlier if its severity gets worse. **Show it now** returns it at once.
4. **Mark not applicable.** Use it only when the check genuinely cannot apply to this site, not because the correction is inconvenient. **Put back in the report** reverses it.

Snoozing and marking not applicable do not change WordPress. They change reporting and, for not applicable, the score. [Snooze a finding or mark it not applicable](/docs/manage-findings/) covers both.

## Set it up: run and schedule the audit

There is nothing to switch on. The audit runs when the plugin is activated, which is why you see a score straight after installing, and once a day after that.

1. Go to **BetterShield › Settings › General** and open **What this site checks**.
2. Find **Scheduled audits** and read the last and next audit times.
3. Select **Run an audit now** when you want fresh results straight away, or **Run audit** in the BetterShield header from any plugin screen.
4. Select **See the full report** to open the Findings report.

WordPress runs scheduled work when the site gets visitors, so a quiet site can pass its next audit time before the audit starts. If that happens, the doc [Run and monitor scheduled audits](/docs/scheduled-audits/) explains what to check.

From the command line, `wp bettershield audit` runs the same read-only audit and prints the score, grade and open findings by severity. Add `--fail-under=80` or `--fail-on=high` and it exits with an error when the result is worse than you want, which suits a deployment step. The [WP-CLI guide](/blog/wordpress-security-wp-cli/) covers the other commands.

## What it can break, and how to undo

The audit itself breaks nothing. It reads the site’s current state and updates only BetterShield’s own score, findings and history. Running it twice does not add risk, and there is no change to undo.

The actions beside a finding are different. **Apply Fix** can change how the site behaves: a request rule can conflict with a service or plugin, and an access rule can change how people sign in. Read **Before you act** first, apply one correction at a time on a site with a current backup and a way back in, and test the affected feature before the next one. To reverse a fix, open **BetterShield › Protection**, find the matching protection and turn it off or use its recorded undo. [Apply a fix from a finding](/docs/apply-finding-fixes/) covers it.

## Check it is working

- The score card shows the number of checks run, any that could not run, and the time of the latest audit.
- After **Run an audit now**, the **Scheduled audits** row says the site was audited just now, and **Last audit** in the header updates.
- After you resolve a finding in BetterShield, it should move to **Fixed** and its points should come back without another audit. If it stays open, press **Check Again**, which says what the check still sees.
- A change made outside BetterShield, such as in WordPress itself, at your host or in a file manager, is read the next time you open a BetterShield screen once the last audit is five minutes old. **Run an audit now** brings it in at once.

## Recommended settings

We recommend letting the daily audit run and adding a manual one after anything that changes the site from outside BetterShield, such as a hosting, domain, plugin or theme change. For the order to work through what the audit finds, see [how to secure a WordPress site](/blog/how-to-secure-wordpress-site/).

| Site | What we recommend |
| --- | --- |
| Blog or brochure site | Let the daily audit run, then run one after a plugin, theme, hosting or domain change |
| Store, membership site or busy community | Also run one after releases and after changing account or access policies |
| Staging copy | Run one after copying the site, so the results describe that environment |

For the standards behind this kind of review, [OWASP’s Top Ten](https://owasp.org/www-project-top-ten/) is a widely used reference for web application security risks, and the WordPress project’s own [hardening guide](https://developer.wordpress.org/advanced-administration/security/hardening/) covers the platform side.

## Frequently asked questions

### Is a WordPress security audit the same as a malware scan?

No. An audit reads your configuration and reports weak settings. A malware scan looks inside files for harmful code. BetterShield does the first, and it does not scan for or remove malware.

### How often does the audit run?

Once a day, plus once when you activate the plugin. You can run it again at any time with **Run an audit now**, and a manual run does not need a switch or a schedule.

### Does the audit change my site?

No. All 71 checks only read. Nothing changes until you choose **Apply Fix** on a finding, and each fix can show what it will change first.

### Why is my score low if nothing looks wrong?

Since BetterShield 1.1.3 the score is 60 points for setup essentials and 40 for site health. Setup findings cost their own points, other findings reduce site health by severity, and any open critical finding holds the total at 74. A snoozed finding still counts; a finding marked not applicable does not. Open the finding’s **Explain** to see what it costs.

### Does the audit tell me about vulnerable plugins?

Yes, once you turn on vulnerability checks in Settings. They are optional and off until then. BetterShield compares your installed components with published advisories from BetterShield Hub, with no account needed, and sends the Hub only slugs and versions. It also flags plugins the WordPress.org directory has closed or that have had no update for years, with the checks on or off.

## Conclusion

A security audit is a map of your site’s settings, not a verdict on whether it is clean. Read the score as an order of work, use **Explain** before you act, snooze only for a reason and run another audit after each change.

BetterShield is free on [WordPress.org](https://wordpress.org/plugins/bettershield/). The docs cover each part: [Score and findings](/docs/score-and-findings/), [Dashboard and Site Health](/docs/dashboard-and-site-health/) and [Run and monitor scheduled audits](/docs/scheduled-audits/).