WordPress Site Health is the one diagnostic screen already installed on every WordPress site, and it will tell you about updates, PHP, HTTPS, scheduled tasks, REST API reachability, plugins and themes without you installing anything. Find it under Tools → Site Health.
You do not have to act on every recommendation, and chasing a perfect score is how working sites get broken. The useful approach is to read what each item actually says, decide whether it affects your site, and change one thing at a time.
What Site Health actually checks
Two tabs, and they do different jobs. Status runs a set of tests and sorts the results into critical issues and recommended improvements. Info gathers environment details — WordPress, server, PHP, database, active plugins and themes, media handling, filesystem permissions — into one page you can copy when asking for help.
Treat it as a starting point rather than an audit. It is a fixed list of checks, so a clean Status tab means those particular tests passed at that moment, not that your site is healthy.
Read before you fix
Critical issues, recommendations and what each is worth
| Result | What it means | How to treat it |
|---|---|---|
| Critical issue | A test failed in a way that can affect security, functionality or reliability | Investigate the same week. Read the explanation and fix the named cause, not something adjacent to it |
| Recommended improvement | A maintenance or configuration item that could be better | Queue it. Weigh it against your hosting and what the site is for — some of these are not worth acting on |
| Good | These checks passed right now | Not evidence of a healthy site. Slow queries, broken integrations and accessibility problems are all invisible here |
The five findings that come up most often
1. Outdated core, plugins or themes
The most common finding and the most worth acting on, because unmaintained code is how sites get compromised. Back up, update, then test the things that earn money rather than just loading the homepage — how to test your WordPress site after a major update is a usable checklist, and updating plugins safely covers the order to do it in.
Delete plugins and themes you are not using instead of leaving them deactivated. Inactive code still sits on disk and still needs patching.
2. An unsupported PHP version
This is a server-level change, not a dashboard toggle, and it is the one most likely to take a site down if you rush it. Check your plugins’ and theme’s stated requirements first, then switch on staging. Checking and updating PHP for a WordPress website safely walks through it properly.
3. HTTPS or certificate problems
Inspect the certificate and your host’s SSL configuration, and confirm that WordPress Address and Site Address both use https://. Be careful here: a wrong URL value locks you out of wp-admin, so follow how to change your WordPress site URL safely rather than editing the fields and hoping.
4. REST API failures
The block editor, the site editor and most modern integrations go through the REST API, so a failed check here usually shows up as a second symptom you have already noticed. The usual causes are a security plugin blocking requests, a firewall rule, basic authentication on a staging site, or a plugin returning a PHP notice that corrupts the JSON response.
That last one is worth checking first because it is invisible otherwise: turn on debug logging and look for a warning emitted during the request. Enabling WordPress debugging and reading error logs safely shows how without exposing notices to visitors.
5. Missed scheduled events
WP-Cron fires on visitor page loads, so a quiet site has nothing to trigger it and a busy one has it competing with real traffic. Scheduled posts stop publishing, backups stop running, and order emails go out late. The missed schedule error in WordPress covers the fix, which is usually to disable the page-load trigger and run cron from the server instead.
The Info tab is the better half
Status tells you what WordPress thinks is wrong. Info tells you what you are actually running, and it is the fastest way to answer a support question without SSH access: PHP version and memory limit, database server and version, server architecture, upload size limits, whether a persistent object cache is in use, and the full active plugin list with versions.
Strip it before you paste it in a public forum
What not to do for a better score
A green dashboard is not worth a broken site. The changes that go wrong are reliably the same ones: switching PHP versions on production without testing, loosening filesystem permissions to clear a warning, disabling a security plugin because it is blocking a loopback request, and editing URL settings to silence an HTTPS notice.
Prioritise by consequence instead. An outdated plugin with a published vulnerability matters; a recommendation that you could be using a newer MariaDB point release generally does not.
Where Site Health stops, and what to check instead
Site Health does not know anything about your site specifically. It will not find a slow query, an unoptimised image library, a broken payment integration, or a plugin consuming 400 queries on a category page. Four things it will never flag, each with its own investigation:
When a visitor reports a problem Site Health does not explain, reproduce it, list what changed recently, and read the server log. That beats refreshing the Status tab.
A practical Site Health routine
- Open Site Health after every round of updates, not on a schedule of its own.
- Fix critical issues; triage recommendations rather than clearing them all.
- Treat PHP version changes as a staging exercise with a rollback plan.
- Investigate a REST API failure only when something real is also failing.
- Take missed scheduled events seriously — they break publishing and backups quietly.
- Keep a backup you have restored at least once, and change one thing at a time.
Frequently asked questions
Where is Site Health in the WordPress dashboard?
Under Tools → Site Health, with two tabs: Status for test results and Info for your environment details. You need administrator capabilities to see it, so on a multisite install it is a network-admin view rather than something editors can reach.
Do I need to fix every Site Health recommendation?
No, and trying to is how working sites break. Critical issues deserve attention within the week. Recommendations are a queue to triage against your hosting and your site’s purpose — some of them, such as a suggestion to install a newer database point release you do not control, are not actionable at all.
What does “your site could not complete a loopback request” mean?
WordPress could not make an HTTP request to itself, which it needs for WP-Cron, the plugin editor and the theme editor. Usual causes are a security plugin or firewall blocking self-requests, basic authentication on a staging site, or a server that cannot resolve its own hostname. Do not disable your security plugin to clear it — allowlist the loopback instead.
Is it safe to share my Site Health info?
With your host, in a support ticket, yes. In a public forum, trim it first — it contains absolute filesystem paths, your exact versions and a complete plugin inventory, which together make a convenient list of known vulnerabilities to try. Paste only the section relevant to the question.
Does a good Site Health score mean my site is fast and secure?
No. It means a fixed list of checks passed. It cannot see a slow query, an oversized image library, a broken integration, a plugin with an unpatched vulnerability that has no update available, or anything specific to your store’s configuration. Use it as a floor, not a report card.
Leave a Reply to This Post