WordPress Site Health Warnings: What to Fix and What to Skip

Open Tools → Site Health in any WordPress dashboard and you'll usually get a mix of green checkmarks and a handful of warnings that sound alarming but rarely explain themselves. "Your site could not complete a loopback request." "The REST API encountered an error." Most site owners either panic and start deactivating plugins at random, or ignore the screen entirely and miss a real problem. Neither is the right move. Here's what each common warning actually means on a cPanel-hosted WordPress site, and how to fix the ones worth fixing.

What Site Health Is Actually Checking

Site Health runs a set of tests against your live install: can WordPress talk to itself over HTTP, is the REST API reachable, are scheduled events (wp-cron) firing, is your PHP version current, are there unused themes and plugins sitting around as an attack surface. It splits results into "Critical" and "Recommended" — the naming matters less than understanding why a test failed, because a few of these will show a warning on a perfectly healthy site.

Critical Issues You Should Actually Fix

"Your site could not complete a loopback request"

A loopback request is WordPress calling its own URL from the server side — it's how cron, plugin updates, and the block editor's preview work. When this fails, it's almost always one of three things:

• A security plugin or ModSecurity rule is blocking the server's own IP. Wordfence, Sucuri, and All In One WP Security all have a habit of firewalling localhost/127.0.0.1 or the server's own outbound requests when a rule is too aggressive. Check the plugin's firewall log for a blocked request to your own domain.
• DNS isn't resolving locally. If you've moved the site and the VPS or shared server still resolves the domain to an old IP internally, the loopback goes nowhere. Test it directly from cPanel Terminal or SSH:

curl -I https://yourdomain.com/wp-cron.php?doing_wp_cron

If that hangs or times out, the server can't reach itself over that hostname — check /etc/hosts on a VPS, or confirm the domain's A record actually points at this server.

• A wildcard .htaccess block or IP allowlist is too strict. Rules that whitelist only office or home IPs for wp-admin will also block the server's own loopback call if they cover wp-cron.php or REST routes. Scope those rules to /wp-admin/ only, not the whole site.

"The REST API encountered an error"

This one breaks the block editor, most contact forms, and some page builders. Test it directly:

curl https://yourdomain.com/wp-json/

If you get a 403, ModSecurity or a firewall rule is the usual culprit — check cPanel → Security → ModSecurity for a triggered rule ID against /wp-json/ and whitelist it for that path rather than disabling ModSecurity site-wide. If you get a 500 or a blank response, it's almost always a plugin hooking into rest_api_init and throwing a fatal error — deactivate plugins one at a time (or use wp plugin deactivate --all via WP-CLI, then reactivate individually) and re-test after each.

If the response is valid JSON but permalinks are set to "Plain," switch to any pretty permalink structure under Settings → Permalinks and re-save — the REST API needs rewrite rules to route correctly.

"Scheduled events have failed" / background updates not working

This means wp-cron isn't firing, which means scheduled posts, plugin update checks, and backup jobs silently stop running. On low-traffic sites this is common because WordPress's default cron only fires on a page visit. Check what's actually queued:

wp cron event list --fields=hook,next_run_relative,recurrence

If events are piling up with negative "next run" times, disable the request-triggered cron in wp-config.php and replace it with a real system cron job through cPanel:

define('DISABLE_WP_CRON', true);

Then add this in cPanel → Cron Jobs, running every 5 minutes:

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

This is more reliable than page-load-triggered cron and won't slow down visitor requests.

Recommended Warnings — Which Ones Actually Matter

When It's Safe to Ignore a Warning

Some Site Health notices are noise. A shared hosting environment you don't control the server config for will sometimes flag "recommended PHP modules" that your host has intentionally left off for security reasons, or a caching-plugin conflict that Site Health can't detect correctly. If a warning has stayed the same for months, the site performs fine, and there's no matching entry in your error log, it's reasonable to leave it. The ones to never ignore are the "Critical" tab and anything mentioning a security vulnerability by name.

Prevention: Keep the Screen Green

• Delete inactive themes and plugins as soon as you're sure you don't need them — don't just deactivate and forget.
• Scope IP-restriction and security-plugin firewall rules to specific paths (/wp-admin/, /wp-login.php) instead of the whole domain, so they don't catch loopback and REST calls.
• Move wp-cron to a real system cron job on any site that gets irregular traffic.
• Check Site Health after every major plugin or PHP version change — it catches breakage before visitors do.

Bottom Line

Site Health isn't a scorecard to chase 100% green on — it's a diagnostic tool. Treat the Critical tab as things to fix this week, treat plugin-vulnerability warnings as fix-today, and treat the rest as context you check against your actual error logs before acting on.