WordPress Site Health Critical Issues: What to Fix First (and What to Ignore)

You open Tools > Site Health and WordPress greets you with a red badge: “Should be improved” and two or three critical issues you never asked about. Some of those warnings are real problems. Others are WordPress being cautious about a setup that works perfectly well.

WordPress Site Health critical issues are the tests WordPress flags as potential security holes or serious performance problems. The trick is knowing which ones to fix today, which ones to hand to your host, and which ones you can safely ignore. This guide walks through the most common messages, what actually causes each one, and the fix that makes it go away for good.

What Does “Critical Issues” Mean in WordPress Site Health?

A critical issue in WordPress Site Health is a test result that WordPress considers a potential security vulnerability or a serious performance problem. Critical issues are more urgent than “Recommended improvements,” which are nice-to-have changes. Neither type means your site is broken right now; both mean something in your configuration deserves attention.

The Site Health screen lives under Tools > Site Health and has two tabs. The Status tab runs the tests and groups results into critical issues, recommended improvements, and passed tests. The Info tab is a read-only report of your server, PHP version, database, constants, and file permissions. According to the official WordPress documentation, you cannot change any settings from the Info tab. It only shows you what is going on.

One thing worth knowing up front: the Site Health score is a nudge, not a grade. A site with one “critical” issue about an inactive theme is in better shape than a site with a perfect score running a plugin with a known vulnerability that Site Health does not check for. Use Site Health as a checklist, not a verdict.

The Most Common Site Health Warnings at a Glance

The most common WordPress Site Health warnings are a failed loopback request, a failed scheduled event, an outdated PHP version, debug output visible to visitors, an active PHP session, missing page cache, and the persistent object cache suggestion. The table below shows how serious each one is and where to start.

Site Health message	How serious?	Usual cause	First fix
Could not complete a loopback request	High	Security plugin, firewall, or password protection blocking the server from calling itself	Test with security plugins and HTTP auth disabled, then ask your host
A scheduled event has failed	Medium to high	Broken loopback, low traffic, or DISABLE_WP_CRON set with no real cron job	Set up a real server cron job
Outdated PHP version	High (security)	Hosting account still on an old PHP release	Switch PHP version in hosting panel, test on staging first
Site is set to display errors to visitors	High (security)	WP_DEBUG left on after troubleshooting	Turn off WP_DEBUG_DISPLAY in wp-config.php
An active PHP session was detected	Medium	A plugin calling session_start() without closing it	Find the plugin with a conflict test
Page cache is not detected	Performance	No caching plugin or server cache, or WP_CACHE is false	Enable server or plugin page caching
You should use a persistent object cache	Performance (recommendation)	Site passed WordPress’s size thresholds without Redis or Memcached	Enable Redis if your host supports it, otherwise ignore

How to Fix “Your Site Could Not Complete a Loopback Request”

To fix the WordPress loopback request error, find whatever is stopping your server from making an HTTP request to its own URL. The usual culprits are a security or firewall plugin, password protection (HTTP basic auth) on the site, a coming-soon or maintenance plugin, or a host-level firewall that blocks self-requests. Fix the loopback first, because several other Site Health warnings depend on it.

A loopback request is your WordPress site calling itself over HTTP. WordPress uses loopback requests to run scheduled events (WP-Cron) and to check that the built-in theme and plugin file editors did not just break the site. When loopback requests fail, background tasks stop running, and the page cache test can report false results too.

Work through these in order:

1. Read the error code. Expand the Site Health item. A 401 means password protection is blocking the request. A 403 usually means a security plugin, Cloudflare rule, or ModSecurity is blocking it. A timeout or cURL error usually means the server cannot resolve or reach its own domain.
2. Remove HTTP basic auth temporarily. Staging sites behind a password prompt fail the loopback test almost every time. That is expected on staging and not worth fixing there.
3. Disable security and maintenance plugins one at a time and re-run Site Health after each one. If you need a structured way to do this, the process in how to find which WordPress plugin is causing a problem applies directly.
4. Check firewall rules. If you use Cloudflare or a server firewall, make sure requests from your own server IP are not being challenged or blocked.
5. Ask your host. If the error is a timeout or “could not resolve host,” the server likely cannot reach its own domain. That is a server or DNS configuration issue that only your hosting provider can fix.

Why Does Site Health Say “A Scheduled Event Has Failed”?

Site Health says a scheduled event has failed when a WP-Cron task missed its run time or threw an error. WP-Cron is not a real cron system: it only runs when someone visits the site and the loopback request succeeds. Low-traffic sites and sites with a broken loopback are the most common victims.

The durable fix is to stop relying on visitor traffic and run WP-Cron from a real server cron job. First, add this line to wp-config.php, above the “That’s all, stop editing!” comment:

define( 'DISABLE_WP_CRON', true );

Then create a cron job in your hosting control panel (cPanel, DirectAdmin, or similar) that hits wp-cron.php every five minutes. Replace the domain with your own:

*/5 * * * * wget -q -O - https://example.com/wp-cron.php?doing_wp_cron >/dev/null 2>&1

Never set DISABLE_WP_CRON without adding the server cron job. Doing only the first half stops every scheduled task on the site, including scheduled posts, backups, and update checks. The full walkthrough is in WordPress scheduled posts not publishing.

Security Warnings: Outdated PHP, Visible Errors, and Pending Updates

The security-type Site Health critical issues are the ones to fix first: an outdated PHP version, debug errors displayed to visitors, and plugins or themes waiting for updates. Each one either exposes information an attacker can use or leaves known vulnerabilities unpatched.

Outdated PHP version

An outdated PHP version is flagged because old PHP releases stop receiving security patches and run slower than current ones. The fix is usually a dropdown in your hosting panel, but plugin and theme compatibility can break, so test it on a staging copy first. The step-by-step process is in how to update the PHP version in WordPress.

“Your site is set to display errors to site visitors”

This Site Health warning means WP_DEBUG_DISPLAY is on, so PHP errors, including file paths on your server, are printed on public pages. It is almost always left over from a troubleshooting session. If you still want to log errors, keep logging on and display off in wp-config.php:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', '/home/youruser/logs/wp-errors.log' );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

Pointing WP_DEBUG_LOG to a path outside the public web root also clears the related warning, “Your site is set to log errors to a potentially public file.” The default debug.log sits inside wp-content, where anyone who guesses the URL can read it. When you are done debugging, set WP_DEBUG back to false.

Plugins and themes waiting to be updated

Pending updates show up as a Site Health issue because outdated plugins are one of the most common ways WordPress sites get compromised. Update them, or decide on a policy for which ones update automatically. Should you turn on WordPress auto updates covers how to make that call without breaking a live site.

“An Active PHP Session Was Detected”: How to Find the Plugin

The “active PHP session was detected” warning means a plugin or theme called session_start() and did not close the session before WordPress made HTTP requests. Open PHP sessions lock the session file, which interferes with the REST API and loopback requests. The fix is to find the plugin responsible and update, replace, or report it.

Common sources are older form plugins, membership plugins, and custom code that stores data in $_SESSION. If you are comfortable searching files, run a search for session_start across wp-content/plugins and wp-content/themes. Otherwise, a standard plugin conflict test will find it. If the culprit is your own custom code, the correct pattern is to call session_write_close() as soon as you have read or written what you need.

Can You Ignore the Persistent Object Cache and Page Cache Warnings?

You can ignore the persistent object cache recommendation if your host does not offer Redis or Memcached, because it is a performance suggestion, not a security issue. The “page cache is not detected” warning is worth fixing on almost every site, because page caching is one of the cheapest speed wins in WordPress.

Both checks came from the WordPress Performance Team and landed in core with WordPress 6.1. According to the team’s original proposal on Make WordPress Core, the object cache suggestion only appears once a site crosses certain size thresholds, such as more than 1,000 posts, comments, terms, or users, or more than 500 autoloaded options. The page cache check treats a server response time under 600 milliseconds as good.

For page cache, WordPress looks for caching headers in the response. If you already use a caching plugin and still see the warning, check that WP_CACHE is not set to false in wp-config.php, and remember that a failed loopback can also make this test misfire. If you are not sure which cache layer is doing what, how to find and clear the cache hiding your WordPress changes breaks down every layer.

For persistent object cache, the choice is simple: if your hosting panel has a Redis or Memcached toggle, turn it on and install the matching object cache plugin. If it does not, leave it. Installing an object cache plugin on a server without Redis does nothing useful.

Recommendations That Are Safe to Leave Alone

Some Site Health recommendations are safe to ignore once you understand them. “You should remove inactive themes” is good housekeeping, but keep one default WordPress theme installed as a fallback for troubleshooting. “Background updates are not working as expected” is often triggered on purpose by sites that are under version control or managed by a host that handles core updates itself.

Loopback and REST API warnings on a password-protected staging site also fall into this bucket. The staging site is supposed to block outside requests. Fix those warnings on production, where they matter, and set up staging the way it is described in how to create a WordPress staging site.

The Takeaway

Treat WordPress Site Health critical issues in this order: security warnings first (PHP version, visible errors, pending updates), then the loopback request, then scheduled events, then caching. Most red badges trace back to two or three root causes, and fixing the loopback alone often clears more than one warning at a time. After 10+ years building WordPress sites and 950+ Fiverr client projects, the pattern is consistent: a clean Site Health screen is less about chasing a perfect score and more about understanding why each warning exists.

Frequently Asked Questions