“Site Health” is a feature first introduced in WordPress 5.2 in 2019. It provides a mildly-useful tool for monitoring the overall well-being of a given WordPress site. Some of what it checks is critically important and should be paid close attention to (but is rarely a problem), other things it checks really aren’t all that important. While what it checks can be extended by plugins, this guide provides an overview of what WP Core looks at and what to care about. But first….
Disabling Site Health
A lot of the information provided by this tool is not actionable. It may just be easiest to completely disable the whole site health system rather than dealing with whatever false positive(s) are causing anxiety. There are two ways to do this:
Install and activate the WP Disable Site Health plugin, or
Add this code snippet to Crate (or wherever the most appropriate place for custom code is)
Critical Tests
If a site doesn’t pass these, then a developer should be involved to ensure things to work reliably and securely
PHP default timezone is valid
Website is using HTTPS
Can communicate with other services
HTTP requests work as expected
Files can be uploaded
Can communicate with WordPress.org
Site can perform loopback requests
Potentially Problematic Tests
These tests, if not passed, could be signs of major issues, but also might be things to not worry about; it just depends on the situation.
Background updates are working: If this is just complaining about git, it’s likely okay. If WordPress files aren’t writable, it could be a major concern (unless on Pantheon)
Site set to log errors: Normally production sites shouldn’t be logging errors, for performance and security reasons, but sometimes they are temporarily while something is being debugged.
Required and recommended modules installed: Just depends on what’s missing. All required and some recommended are very, very important. Others aren’t a big deal.
SQL Server is up-to-date: Depends on how far out-of-date it is
Plugin/theme auto-updates appear properly configured: This depends on what the desired auto-updating approach actually is, which varies by client/site/host
The REST API is available: Usually it needs to be, esp. for Gutenberg, but there may be reasons to turn it off.
Running current PHP: It’s good to be running at least PHP 7.2, so anything older than that is cause for a bit of concern. If it’s running PHP 5.x, it’s definitely an issue. PHP 7.3? Not so bad.
Probably Okay
While not great to fail these tests, they’re (usually) not a reason for major concern.
Scheduled event is late: Happens sometimes on low-traffic sites and may indicate that cron isn’t running properly; also might just mean the site hasn’t had a visit in a while and really is okay but just running a little behind schedule
Core is not up-to-date: It’s best to keep WordPress updated, but if it’s not, there may be a good reason.
Plugins are not up-to-date: It’s best to keep all plugins updated, but if they’re not, there may be a good reason.
Themes are not up-to-date: It’s best to keep all themes updated, but if they’re not, there may be a good reason.
PHP sessions detected: This can be for any number of reasons, such as a plugin that uses sessions, and it likely an error that comes and goes. If this test ALWAYS fails, there might be some bad code. But most of the time it’s a fleeting issue.
UTF8MB4 is supported: This is esoteric and generally not relevant to clients with sites only in English. As long as UTF8 is supported everything’s fine. If the site also has something like Arabic or Chinese, though, this can be critical.