Quick answer: Site Health is a WordPress admin screen (introduced across 5.1 and expanded in 5.2 in 2019) that runs automated checks on your installation. Critical issues deserve prompt action: outdated WordPress, insecure PHP, missing HTTPS, or broken scheduled events. Recommended improvements are useful but prioritized after criticals. Treat the score as a guide, not a vanity metric.
If you recently updated WordPress and spotted a heartbeat-style Site Health widget or a Tools → Site Health screen, this guide translates the jargon into action.
Where to find it
In current 5.2-era installs: Tools → Site Health, plus a Status widget on the dashboard for some setups. You will see a status summary, Critical issues, Recommended improvements, and an Info tab with technical details useful for support tickets.
Critical vs recommended
Critical means something is wrong enough to risk security, reliability or basic function. Fix these first.
Recommended means best-practice improvements: inactive plugins to remove, better PHP version headroom, optional modules.
Do not chase a perfect score while checkout is broken. Do not ignore critical HTTPS failures because the homepage “looks fine.”
Checks you will see often
WordPress version
Running an old core version is a security problem. Update on staging first if you have heavy custom code, then production. Keep backups.
PHP version
WordPress runs on PHP. Older PHP versions stop getting security patches. Upgrading PHP often improves speed too (PHP versions and WordPress, PHP 7 performance). Confirm plugins support the target version before switching on the host panel.
HTTPS
Sites should be served over HTTPS. Mixed content and missing certificates show up here. See HTTPS migration.
Secure authentication keys / salts
If keys are default or missing, regenerate them (and be ready to re-login).
Scheduled events / WP-Cron
If cron is broken, delayed posts, subscription renewals and backup plugins misbehave. Hosts sometimes disable WP-Cron in favor of a real system cron; that can be fine if configured on purpose.
REST API availability
The REST API should respond. Security plugins that blanket-block it can break the block editor and many apps (WordPress REST API).
Loopback requests
WordPress calling itself. Failures often point at DNS, firewall or SSL problems on the server.
Disk space and file uploads (host dependent)
Enough space for updates and media.
Inactive plugins and themes
Inactive code still increases attack surface when left installed. Delete what you do not use. Part of any serious WordPress security routine.
Database and character set
Utf8mb4 is the modern expectation for full emoji and symbol support.
How to use the Info tab
When you open a support ticket with your host or agency, paste relevant Info lines: PHP version, server, image libraries, extensions. That saves three days of “what PHP are you on?”
What Site Health does not do
It does not replace a full SEO audit, a performance audit or a malware scan. You can score well and still have a slow theme or a spam user. Use it as one dashboard among several.
A sensible weekly habit
- Open Site Health after updates
- Resolve new criticals the same day
- Schedule recommended PHP or plugin cleanups
- Export a screenshot or note for your change log
Hosting cooperation
Some checks fail because the host blocks loopback or outdated TLS. Good hosts document the fix. If your host cannot run a supported PHP version, that is a hosting problem, not a Site Health quirk.
Change management
When Site Health demands a PHP bump, treat it like a mini project: staging upgrade, smoke test checkout and forms, then production. Record the change window. Site Health is the prompt; process is the fix.
Mapping checks to tickets
Turn each critical issue into a ticket with severity, owner and due date. “Improve PHP” is not a ticket; “Upgrade production PHP from 7.2 to 7.3 on staging by Friday, production Monday” is. Site Health is the detector; your tracker is the workflow.
Educating non-technical owners
Show them the difference between a red critical and a blue recommendation once. After that, send summaries instead of raw screenshots that look like the site is “failing Google.”
Security plugins and false positives
Some hardening plugins break loopback or REST checks on purpose. Whitelist what WordPress needs or adjust the hardening rules rather than living with permanent criticals you ignore.
Reading the passed checks too
Passed checks are useful confirmation after a host migration: HTTPS works, loopback works, REST works. Keep a note when everything is green after a big change so you can compare when something regresses.
PHP modules and image libraries
The Info tab lists extensions. Missing image libraries affects media handling. Missing internationalization extensions can affect some plugins. You do not need every module; you need the ones your stack expects. Ask your developer which are required before a PHP upgrade.
Debugging when Site Health itself errors
Occasionally the Site Health page fatals because a plugin hooks a check badly. Disable plugins briefly on staging to find the offender. Update or remove it. Sitting on an old WordPress version to avoid Site Health is the wrong trade.
Team roles
Administrators see Site Health. Editors usually do not need it. Do not send clients into critical issue screens without context; translate into tickets instead, such as scheduling a PHP upgrade this month.
Relating Site Health to performance plugins
A green Site Health score does not mean pages are fast. Pair it with caching discipline and front-end budgets. Site Health is hygiene; performance is a separate measuring stick.
After major WordPress releases
Open Site Health after each major update. New checks appear over time. Treat new criticals as part of the upgrade definition of done.
Multisite notes
Network-activated plugins affect all sites. A critical on one subsite may be local (that site’s HTTPS) or global (PHP version). Diagnose at the right layer.
Staging vs production scores
Staging may fail HTTPS or loopback checks that production passes. Interpret Site Health in context of the environment. Do not “fix” staging by weakening TLS checks that teach bad habits.
Hosting control panels and PHP selectors
Many hosts expose PHP version pickers per site. Change staging first, run Site Health, click through login, a form and a sample checkout if you sell, then repeat on production in a low-traffic window. Keep a rollback path to the previous PHP version for twenty-four hours.
FAQ
Does a lower Site Health score hurt SEO directly?
Not as a score Google reads. The underlying issues (HTTPS, hacking risk, downtime) can hurt visibility and users.
Can plugins add checks?
Yes. Some hosts and security plugins register extra tests. Read their docs so you know what is core vs added.
Should clients panic at “should be improved”?
No. Walk them through critical vs recommended. Panic helps nobody.
Is Site Health available on Multisite?
Yes with some nuances; network admins see broader context. Check your version’s docs for the exact UI.
Fix criticals, then improve
Site Health is WordPress telling you about hygiene. Act on critical issues quickly, plan recommended upgrades, and keep the Info tab handy for support. For ongoing WordPress care that includes updates, security and performance, see Turn visitors into customers.
