WordPress Site Health: What Every Check Means and How to Fix It

Open Tools > Site Health in any WordPress site and you get a grade, a list of problems and a lot of jargon: loopback requests, persistent object cache, autoloaded options. Some of it matters a lot. Some of it you can safely ignore.

This guide explains what WordPress Site Health actually checks, what each common message means in plain English, how to fix it, and the one big thing Site Health was never designed to tell you.

What is WordPress Site Health?#

Site Health is a diagnostics screen built into WordPress core since version 5.2. It runs a set of tests against your server and your WordPress setup, then shows the results on two tabs:

• Status groups every test into critical issues, recommended improvements and passed tests, and shows an overall rating such as "Good" or "Should be improved".
• Info lists the technical details of your install: WordPress version, active theme and plugins, PHP settings, database server, directory sizes, file permissions and WordPress constants.

There is also a Site Health Status widget on the main Dashboard, so most admins see the rating every time they log in.

Two things are worth knowing up front:

1. Site Health tests your configuration, not your pages. It checks whether WordPress can update itself, reach WordPress.org, run scheduled tasks and so on. It never loads your home page the way a visitor would.
2. It only runs when someone looks. Most tests run when you open the screen (a few also run in the background through WP-Cron). Nothing emails you when the rating drops.

Keep both in mind. We will come back to them.

How to check your site health#

1. In wp-admin, go to Tools > Site Health.
2. Wait for the tests to finish. Some of them make HTTP requests, so it can take a few seconds.
3. Open each item under critical issues first, then recommended improvements. Every item expands into an explanation and usually a link with next steps.
4. Switch to the Info tab when you need to send details to your host or a plugin developer. The Copy site info to clipboard button copies everything in one go, ready to paste into a support ticket.

Only administrators can see the screen. On multisite, the network admin sees it.

Critical issues: what they mean and how to fix them#

Critical issues are things that can make your site insecure, slow or unable to update. These are the ones you will meet most often.

Recommended improvements worth your time#

Recommended improvements are not emergencies, but several of them have a real effect on speed or security:

• You should remove inactive plugins and themes. Inactive code still sits on the server and can still contain vulnerabilities. Delete what you do not use, but keep one default theme (such as Twenty Twenty-Five) as a fallback.
• Your site does not use HTTPS, or HTTPS is not set up correctly. Fix this first. Since WordPress 5.7 you can switch the site address to HTTPS from Site Health once your certificate works.
• A scheduled event has failed or is late. WP-Cron jobs (backups, publishing scheduled posts, plugin tasks) are not running on time. Low-traffic sites often benefit from a real server cron job that calls wp-cron.php, with DISABLE_WP_CRON set to true.
• The REST API encountered an error. The block editor and many plugins depend on the REST API. Security plugins and firewall rules are the usual cause.
• You should use a persistent object cache. WordPress suggests this on bigger sites. If your host offers Redis or Memcached, enabling it can speed up the admin and dynamic pages.
• Page cache is not detected. A page cache serves stored HTML instead of rebuilding each page. Many hosts include one; otherwise use a caching plugin.
• Autoloaded options could affect performance. Too much data in the options table loads on every request. Old plugins often leave large autoloaded options behind. Clean them up with care, on staging, with a backup.

Items you can usually leave alone: messages about Imagick or other optional modules, and anything your host has confirmed it manages for you.

How to raise your Site Health score#

The rating is driven by the number and type of failing tests. To improve it, work through the list in this order:

1. Update PHP to a supported version.
2. Apply pending updates, one plugin at a time.
3. Make automatic background updates work so security releases install on their own.
4. Turn off debug output on the live site.
5. Remove inactive plugins and themes.
6. Fix HTTPS, loopback and REST API errors, which are usually one misbehaving plugin or firewall rule.
7. Add caching (page cache, then a persistent object cache if your host supports it).

You do not need a perfect score. A site with "Good" status and nothing critical is in good shape from Site Health's point of view.

When a plugin is the cause: use troubleshooting mode#

Loopback failures, REST API errors and PHP session warnings are almost always caused by one plugin. The free Health Check & Troubleshooting plugin from the WordPress community adds a troubleshooting mode: it disables all plugins and switches to a default theme only for your browser session, while visitors keep seeing the normal site. Re-enable plugins one at a time until the Site Health warning comes back, and you have your culprit.

For a full walkthrough, see our guide to finding a WordPress plugin conflict.

What Site Health does not tell you#

Here is the gap. A site can show Good in Site Health while visitors see something broken, because Site Health never looks at your pages:

• A theme or page builder update shifts the layout or hides a section.
• A WooCommerce extension update removes the Place order button. See WooCommerce checkout not working.
• An SEO plugin update changes titles or adds noindex to key pages.
• A caching or optimization plugin drops your Google Analytics or Meta Pixel script.
• "Discourage search engines" gets switched on after a staging push.
• A plugin update causes a PHP fatal error, and the site shows there has been a critical error on this website.

Site Health also has no memory and no alerts. It cannot tell you that the score was fine yesterday and dropped overnight after an automatic update, or which update did it.

That is the job of monitoring: checking your important pages from the outside on a schedule and right after every update, comparing them with how they looked when they were working, and alerting you when something important changes.

Add continuous checks with the free MyKavo plugin#

The free MyKavo WordPress plugin fills exactly that gap, and it works alongside Site Health rather than replacing it:

• It appears in Site Health. MyKavo's status shows up under Tools > Site Health, and its details are included in the Info tab you copy for support.
• Every update is recorded and checked. Plugin, theme, core and translation updates, plus plugins being switched on or off. After each one, MyKavo checks your key pages and names the update behind any change: "Appeared after: Updated WooCommerce 8.1.0 to 8.2.0".
• "Did it crash?" check (free). About ten seconds after an update, the site loads its own home page and up to three monitored pages and looks for a server error, the critical error page, a PHP fatal error or an empty page, with a Roll back now button if it finds one.
• Silent-disaster alerts (free). A notice on every wp-admin screen when "Discourage search engines" is switched on, the site address or permalinks change, the admin email changes or a new administrator appears.
• One-click rollback (free). Put a plugin back to the version you had before, straight from the update history.

The check of your pages after each update (Safe Updates) is included in every paid plan, from Starter, and in the 14-day Pro trial. The plugin itself, update history, the crash check, alerts and rollback are free.

Site Health checklist#

• Check Tools > Site Health once a month and after major changes.
• Fix every critical issue, starting with PHP version and updates.
• Keep debug output off on the live site.
• Remove inactive plugins and themes.
• Use troubleshooting mode to find plugins behind loopback, REST API and session warnings.
• Copy the Info tab into support tickets.
• Add continuous monitoring for the things Site Health cannot see: your pages, after every update.

For the rest of your routine, use our WordPress maintenance checklist.