The WordPress site health warnings that matter are the critical items tied to security and updates: plugins, themes or a minor WordPress release waiting to be installed, a PHP version that no longer gets security fixes, errors shown to visitors, open registration with an Administrator or Editor default role, and a site that cannot reach WordPress.org. Most recommended items, such as inactive themes, a missing object cache or a disabled opcode cache, are advice rather than faults. One critical item is enough to turn the status to "Should be improved."
WordPress version: 7.1.2 (released September 22, 2026). Last verified: September 23, 2026, against WordPress.org documentation, the WordPress developer reference and the WordPress core source code.
Where Site Health lives and what its two tabs show
Open Tools > Site Health. The WordPress.org Site Health screen documentation (last updated July 12, 2026, which we read on September 23, 2026) describes two tabs:
- Status runs the tests and groups results by severity: critical issues, recommended improvements and passed tests.
- Info is read-only. It lists your WordPress version, active and inactive themes and plugins, media handling, server, database, constants and file permissions. You cannot change anything from it, but it has an export that copies all of that information to your clipboard, which is exactly what a host's support team will ask for.
Each result expands into a plain-language explanation. Many include a link straight to the screen where you fix it, and each carries a small badge naming its area, such as Security, Performance or Privacy.
The same summary appears on the Dashboard in the Site Health Status widget, so you may see a warning count there before you ever open Tools.
How WordPress decides "Good" or "Should be improved"
Few of the guides ranking for this topic explain this part, and it answers the real question: "It's showing six issues. Are any of them real?"
The label comes from a short calculation in WordPress core's own Site Health script (site-health.js in the wordpress-develop repository, read September 23, 2026):
- A critical issue counts as 1.5 failures. A recommended improvement counts as half of one.
- The failures are compared against all tests and turned into a score out of 100.
- The label reads Good only when the score is 80 or higher and there are zero critical issues. Anything else reads Should be improved.
Two made-up sites, run through that formula:
| Passed | Recommended | Critical | Score | Label |
|---|---|---|---|---|
| 20 | 6 | 0 | 88 | Good |
| 20 | 5 | 1 | 84 | Should be improved |
Six recommended items and no critical ones can still read Good. One critical item turns the label orange however high the score is. So read the critical list first, and treat the recommended count as a to-do list rather than a verdict.
The triage table: which WordPress site health warnings matter
The severity column is what WordPress core assigns in its own test code, checked in the developer reference and core source on September 23, 2026. The "does it matter" column is our reading for a small, public, live site.
| Warning, as WordPress words it | Core rating | Does it matter? | First move |
|---|---|---|---|
| You have plugins (or themes) waiting to be updated | Critical | Yes | Back up, then update from Dashboard > Updates |
| A new minor update is available | Critical, Security badge | Yes, today | Update WordPress |
| WordPress update available (a new major version) | Recommended | Plan it, do not rush it | Read the release notes, test on a copy |
| Outdated version of PHP that no longer gets security updates, or soon will not be supported | Critical | Yes | Check your version, ask your host |
| Older version of PHP that is still supported | Recommended | Low urgency | Put it on the calendar |
| Your site is set to display errors to site visitors | Critical (Recommended on development or local sites) | Yes, on a live site | Turn error display off |
| Your site is set to log errors to a potentially public file | Critical if the log sits inside the WordPress folder, otherwise Recommended | Yes, when critical | Turn logging off when you are done |
| Open Registration with privileged default role | Critical, new in 7.0 | Yes, today | Use the "Change these settings" link |
| Could not reach WordPress.org | Critical | Yes | Ask your host |
| REST API error, or a failed loopback request | Critical when it fails outright | Yes, if the editor or scheduled posts misbehave | Run a conflict test |
| Background updates are not working as expected | Critical or Recommended | Depends on who manages your updates | Ask your host |
| A scheduled event has failed, or is late | Recommended | Sometimes | Watch whether it repeats |
| Autoloaded options could affect performance | Critical (since 6.6) | Speed, not safety | Advanced cleanup |
| Page cache, persistent object cache, opcode cache | Recommended (page cache turns Critical when the site is slow and no cache is found) | Speed advice, usually server-level | Ask your host |
| You should remove inactive plugins (or themes) | Recommended | Worth doing, low urgency | Remove what you will not use |
| Search engines are discouraged from indexing this site | Recommended (since 6.9) | More than its rating suggests | Settings > Reading |
| Site does not use HTTPS | Recommended | Yes, on a public site | Ask your host |
Fix these today: the critical warnings that are real
Pending plugin, theme and minor core updates
The WordPress.org documentation puts it plainly: plugins "have deep access to your site, so it's vital to keep them up to date." Minor WordPress releases often carry security fixes. WordPress 7.1.2, released September 22, 2026, contained a single fix for a vulnerability WordPress News rated critical severity. That is why core flags a pending minor release as critical but a new major version only as recommended.
Before you click Update, make sure your latest backup actually restores. Site Health never checks that, so verify your WordPress backup first, then update one item at a time.
PHP that no longer gets security updates
Core marks PHP critical in two cases: the version no longer receives security updates, or it sits below the minimum WordPress plans to require next. WordPress 7.0 raised the minimum to PHP 7.4. Your host controls the PHP version, not WordPress. Our guide on how to check your PHP version before an upgrade walks through finding it and asking for the switch without breaking anything.
Debug output left on
"Your site is set to display errors to site visitors" means error text can appear on public pages, and the documentation warns that debug output "may contain sensitive information." The log warning is critical only when the log file lives inside the WordPress folder, where it may be publicly reachable. If you need the log for troubleshooting, turn on the debug log without showing errors, then switch it off again when you are finished.
Open registration with an Administrator or Editor default role
This test arrived in WordPress 7.0. The WordPress 7.0 Field Guide (Make WordPress Core, May 14, 2026, read September 23, 2026) records that Administrator and Editor were removed from the new user default role selector on the General settings screen, and that Site Health now alerts you if one of them was already set before the update. If anyone can register and new accounts become Editors or Administrators, a stranger can sign up with that level of control. Click "Change these settings" in the warning, then either turn off open registration or pick a lower default role.
Could not reach WordPress.org, REST API and loopback failures
If your site cannot reach WordPress.org, it cannot check for or install updates. The documentation explains that loopback requests (your site calling itself) are used to run scheduled events and by the built-in theme and plugin editors to check code before saving. A REST API or loopback failure is worth chasing when you also see a symptom: posts that miss their scheduled time, or an editor that refuses to save. If it lines up with something broken, start with the 15-minute WordPress diagnosis rather than changing settings at random.
Warnings you can usually leave alone, and when not to
Performance recommendations. The page cache, persistent object cache and opcode cache checks are speed advice. Per the Make WordPress Core post announcing the cache checks in WordPress 6.1 (October 6, 2022), the page cache check compares server response time against a 600 millisecond default, and the object cache check only recommends one once a site passes thresholds for posts, users, comments and options. The opcode cache test was added in 7.0. All three are usually server settings, so the fix is a question to your host, not a job for you.
Background updates on a managed host. Some hosts switch off WordPress's own background updates on purpose and run updates themselves. If your host's documentation says so, this warning describes their setup, not a fault. If nobody is updating the site, it matters.
Inactive themes. Core also recommends keeping a default theme installed ("Have a default theme available"), so deleting every inactive theme can swap one recommendation for another.
The exception that deserves attention anyway. "Search engines are discouraged from indexing this site" is only a recommendation, because private and staging sites set it on purpose. On a public site you want found, that one checkbox under Settings > Reading matters more than its rating.
Why a staging copy shows different warnings
Site Health adjusts to the environment type WordPress thinks it is running in, shown under Info > WordPress > Environment type. According to the developer reference and the 6.1 announcement:
- The page cache and persistent object cache checks run only on production sites.
- "Display errors to site visitors" drops from critical to recommended on development or local sites.
So a staging copy can look healthier, or simply different, from the live site. Judge the live site by the live site's own Site Health screen.
What Site Health does not check
A Good label means your configuration matches what WordPress recommends. It does not mean the site is backed up, free of malware or online around the clock. None of the tests listed in the developer reference cover backups, malware scanning or uptime.
There is also no dismiss or ignore button described in the documentation. The only core way to switch a test off is a developer filter called site_status_tests. Hiding a test changes the score, not the problem it measured, so use it only for checks that genuinely do not apply to your setup.
FAQ
Is "Should be improved" bad?
Not by itself. The label appears whenever there is even one critical issue, or when the score falls below 80. Open the Status tab and read the critical list. If it is empty, you are looking at recommendations, not faults.
Can I turn off WordPress site health warnings?
WordPress documents no dismiss button for individual results. A developer can remove tests with the site_status_tests filter, but that only hides the result. It is better to fix the critical items and accept that some recommendations will stay visible.
What changed in Site Health in WordPress 7.0 and 7.1?
WordPress 7.0 added a critical test for open registration with an Administrator or Editor default role, a recommended opcode cache test, and OPcache details under Info > Server. The search engine visibility test arrived in 6.9. The WordPress 7.1 Field Guide lists no Site Health changes.
Does a Good status mean my site is secure?
No. It means the settings WordPress can see match its recommendations. Site Health does not scan for malware, confirm your backups restore or watch uptime. Those checks still have to happen somewhere else.
