The dashboard widget says your site health “Should be improved”, with an orange circle, and a list of things WordPress thinks are wrong. Some sound alarming: a failed scheduled event, a REST API error, a loopback request that could not complete. Others sound like homework: remove inactive plugins, use a persistent object cache, install a missing PHP module. It is hard to tell which ones are a real problem for your business and which ones you can calmly leave.
This post goes through the Site Health screen the way we read it on a client site: what each part is, which warnings tend to matter, which are often fine to ignore on a small site, and what to do about the ones that matter.
Where it lives and what it is
Site Health is built into WordPress. You find it under Tools > Site Health, and a summary widget usually sits on the main dashboard. It runs a set of checks against your installation and your server, and gives you two tabs:
- Status: the results of those checks, grouped into critical issues, recommended improvements and passed tests. Each item carries a label such as Security or Performance, and expands to explain itself.
- Info: a detailed description of your setup, including WordPress version, active theme, plugins, PHP version and settings, database, constants defined in
wp-config.php, and file permissions.
Two things are worth knowing up front. First, the overall score is a rough summary, not a grade of your website. A site can show “Good” and still have a broken checkout, and a perfectly healthy site can show “Should be improved” because of one recommendation that does not apply to it. Second, plugins can add their own checks. WooCommerce, security plugins and caching plugins sometimes add items, so not every line you see comes from WordPress itself.
Some checks also depend on the moment. A loopback or REST API test can fail once because the server was busy when you opened the page. Reload the screen before you start worrying about any single failure.
Warnings that usually matter
An outdated PHP version
If Site Health says your site is running an outdated or unsupported version of PHP, take that seriously. Old PHP versions stop getting security fixes, and new plugin versions gradually stop supporting them, so you end up stuck on old plugins too. The fix is changing the PHP version in your hosting panel, but do it carefully: a plugin or theme that was never updated may break on newer PHP. Our post on updating PHP on a WordPress site covers checking compatibility first, and if old custom code is the obstacle, we can take care of a PHP upgrade and repair what it breaks.
“The REST API encountered an error”
The REST API is how the block editor, many page builders and plenty of plugins talk to WordPress behind the scenes. When Site Health cannot reach it, you will often see related symptoms: the editor fails to save, shows “Updating failed”, or a plugin’s settings page will not load. The usual causes are a security plugin or firewall blocking requests, a plugin breaking the response, or a server rule. There is a full walkthrough in our REST API troubleshooting post.
“Your site could not complete a loopback request”
A loopback is your site making a request to itself. WordPress relies on this for scheduled tasks and for the safety check that runs when you edit theme or plugin files from the dashboard. When loopbacks fail, scheduled posts can be missed, backups may not run, and some background jobs pile up. The cause is often similar to the REST API one: a firewall, a plugin, basic authentication on a staging site, or a server that cannot resolve its own domain name. The error detail sometimes includes a cURL error code, and what those cURL codes mean is covered separately.
“A scheduled event has failed” or is late
WordPress has its own task scheduler, WP-Cron, which runs when someone visits the site. On a quiet site, or one with caching that serves pages without touching WordPress, tasks run late. If they fail outright, something is stopping them. This matters if you depend on scheduled posts, automatic backups, subscription renewals or regular emails. The longer explanation, and the usual fix of setting up a real server cron job, is in our post about WordPress cron problems.
No HTTPS, or HTTPS not fully set up
If Site Health says the site is not using HTTPS, or that your WordPress and site addresses are not set to https even though a certificate exists, fix it. Browsers flag non-https sites as not secure, and forms that send personal details over plain http are a genuine risk. Make sure the certificate is active first, then update the addresses, then check for leftover http links.
Background updates not working
If this test fails, WordPress may not be able to install security releases automatically. The detail usually says why: a version-control folder in the site, a constant in wp-config.php that disables updates, or file permissions that stop WordPress writing files. If you deliberately manage updates another way, this is fine. If you did not know, find out who turned it off and why.
Errors displayed to visitors
A warning that your site is set to display errors to site visitors means WP_DEBUG or a server setting is printing PHP errors on public pages. That can reveal file paths and look alarming to customers. Debugging belongs in a log file, not on screen; turn display off and use logging while you investigate.
Warnings that are often fine on a small site
“You should use a persistent object cache”
This recommends an object cache such as Redis or Memcached. On large, busy or complex sites it can make a real difference. On a typical brochure site or a small shop it often changes very little, and it needs server support that many shared hosting plans do not offer. Mention it to your host if you are curious; do not lose sleep over it.
Page cache not detected
WordPress tries to detect whether pages are cached by looking at response headers. Some hosts and caching setups do cache pages but do not send the headers WordPress looks for, so this can show even when caching is working. Check with your caching plugin or host before changing anything.
“You should remove inactive plugins” and inactive themes
Inactive plugins cannot run, but their files are still on the server, and an old vulnerable file can still be reached in some cases. Removing ones you do not need is good housekeeping. Keep one default WordPress theme installed even if you do not use it, because it is the fallback WordPress uses if your theme fails. Keep a parent theme if your active theme is a child of it.
“One or more recommended modules are missing”
This lists PHP extensions WordPress can use but does not strictly need, often imagick for image processing. If your images upload and resize fine, the site is usually working with an alternative, such as GD. It is worth raising with your host, but it is rarely urgent.
Using the Info tab when something goes wrong
The Info tab is the most underused part of the screen. When you report a problem, press Copy site info to clipboard and paste the result into your message. It gives a developer your exact versions and settings in one go. You can also use it yourself to check your PHP memory limit, maximum upload size, whether debug mode is on, and which constants are defined, without opening any files. There is more about writing a useful problem report in how to describe a website problem so it gets fixed.
What Site Health does not check
It helps to know the limits of the screen. Site Health does not test whether your contact form delivers email, whether checkout completes, whether your backups can actually be restored, or whether the site has been tampered with. It does not look at page speed the way a visitor experiences it, and it does not know whether a plugin you rely on has been abandoned by its developer. A green “Good” means the checks it runs passed. It says nothing about the parts of the site that make you money, so test those yourself after every round of updates.
A sensible routine
- Look at Site Health after updates and after any hosting change, not just when something breaks.
- Reload once before acting on a single failed test, to rule out a busy moment.
- Deal with critical items first, especially PHP version, REST API, loopback and HTTPS.
- Read the recommendations, decide which apply, and note the ones you have chosen to leave, so you do not re-investigate them every month.
- Before changing server settings, PHP versions or
wp-config.php, save a full copy of the site so you can step back.
Site Health is one of several ways WordPress tells you something is off. For the errors that show up on the site itself, rather than on this screen, our WordPress errors and fixes guide maps symptoms to causes.
Getting a second opinion
If the screen is full of warnings and you cannot tell whether your site is at risk or just being nagged, a person reading it alongside your actual setup can save you a lot of guesswork. Our website health check does exactly that: we look at Site Health together with your plugins, hosting and backups, and tell you plainly what is worth fixing and what can wait.
If Site Health flags something you are not sure about, our wordpress help and support team can look at it with you.
Next in this series: WordPress Parse Error (Syntax Error, Unexpected) Fix
