WordPress Site Health critical issues: what they mean and which ones to fix first

What do WordPress Site Health critical issues mean?

WordPress Site Health critical issues are the checks that WordPress believes put your site’s security or speed at risk today. They sit at the top of Tools, Site Health, above the recommended improvements.

The label sounds alarming, and sometimes it should. On 13 Oct 2026 we ran every Site Health test on a WordPress 7.1.3 test site and got five critical items. A fresh install showed only one; the other four appeared in a second run, with error logging on, the updater off and WooCommerce’s own checks running. Two were real risks. The rest came from the test server or from a plugin’s own checks.

Sorting those two kinds apart is most of the job. It is also one of the first screens we open on a site that joins our WordPress care plan, because Site Health is often the first place a hidden problem shows.

What did a fresh install show?

One critical item and eight recommended ones. We installed WordPress 7.1.3 on PHP 8.3 with WooCommerce and ran the tests from code. The debug log check did not run in that first pass, a bug in our script, and WooCommerce’s own checks only appeared from the second run.

The critical item was “Page cache is not detected and the server response time is slow”. Site Health made three requests to the home page and measured a median response of 3,750 milliseconds. Its threshold is 600.

That number belongs to our test server, which is slow by design. On a live site the same message is worth taking seriously: every visitor waits for PHP to build the page from scratch.

Which critical issues are real risks?

The ones that expose data or block security fixes. Two showed up on our second run, after we edited wp-config.php.

An error log anyone can download

Our test environment turns on WP_DEBUG_LOG by default, so PHP errors go to wp-content/debug.log, and we set the same constant in wp-config.php. Site Health flagged it as critical: “Your site is set to log errors to a potentially public file”.

We wrote one test line to the log, then asked for /wp-content/debug.log over plain HTTP, the way any visitor could. The server answered 200 and handed over the file, with our test line in it.

Site Health’s own description warns that debug output “may contain sensitive information which should not be available on a publicly available website”. The WordPress debugging guide sends the log to that exact spot when WP_DEBUG_LOG is true, so it is a common leftover after someone fixes a bug and forgets to turn logging off.

Background updates switched off

We added one line to wp-config.php: define( ‘AUTOMATIC_UPDATER_DISABLED’, true ). Site Health then reported “Background updates are not working as expected”, with the reason “All automatic updates are disabled”.

That line stops WordPress from installing security releases on its own. When we removed it and ran the tests again, the same check read “Background updates are working”.

If you want to know what does update on its own, we traced it in who turned on WordPress plugin auto-updates.

Which critical issues can wait?

The ones that describe the server or a plugin’s opinion. Read the description, then decide.

1. Page cache and response time. Real for speed, not a security hole. A caching plugin or the host’s cache fixes it.
2. Store checks from WooCommerce. Plugins can add their own tests through the site_status_tests filter. Two of our five critical items came from WooCommerce, including “WooCommerce store is not using a secure connection”, because our lab ran on http.
3. HTTPS on the whole site. Core rated “Your website does not use HTTPS” as recommended in our run, while WooCommerce rated the same gap critical for the store. Same cause, two ratings.

A “scheduled event is late” item also appeared in our recommended list. That one often means WP-Cron is waiting for visitors, which we tested in why WP-Cron waits for a visitor before it runs scheduled jobs.

How do you fix a critical issue safely?

Change one thing, then run Site Health again. That is how we confirmed the background updates fix in the lab.

1. Open Tools, Site Health and expand each critical item. Note the label and the “Type” badge (Security or Performance).
2. For a public debug log: set WP_DEBUG_LOG to false or to a path outside the web root, then delete wp-content/debug.log.
3. For background updates: search wp-config.php and any must-use plugins for AUTOMATIC_UPDATER_DISABLED and remove it unless someone can explain why it is there.
4. For speed: add a page cache, then check the median response time in the same test.
5. Take a backup before editing wp-config.php. A typo there takes the whole site down.

When we take on a site, we clear every critical Site Health item or write down why it stays, close public log files the same day, and check the list again after each round of updates.

Should you aim for zero recommended improvements?

No. Our fresh install had eight, and several were harmless, like “You should remove inactive themes” for the default themes WordPress ships.

Some are worth a look. “Inactive plugins are tempting targets for attackers” is the wording WordPress uses, and it is a fair reason to delete plugins you no longer use. Treat the list as a to-do, not a score.

What should you check today?

Open Tools, Site Health on your live site. Count the critical items and read the Type badge on each. Then try loading yoursite.com/wp-content/debug.log in a private window.

If that file opens, or a critical item makes no sense, send us the Site Health list and we will tell you which ones matter for your site.