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.

"WordPress.com requests to your site are being blocked"

This warning doesn't come from WordPress itself. It's Jetpack's, and the admin notice reads in full: "WordPress.com requests to your site are being blocked, usually by a firewall or security rule. See Site Health for details and next steps." Next to it is a Visit Site Health button.

Jetpack's connection runs both ways: your site calls WordPress.com, and WordPress.com calls back to your site's xmlrpc.php file. This notice means the call back was refused — WordPress.com reached your server and something turned it away. Site Health's Jetpack test shows the status code your site sent back, for example "WordPress.com reached your site but the request was blocked (HTTP 403)".

Two things follow. The connection itself can be perfectly fine, and reconnecting Jetpack won't fix it, because the same rule blocks the reconnect — Jetpack's own Site Health text says so. What needs fixing is whatever blocks xmlrpc.php. On cPanel hosting it is almost always one of these:

• An XML-RPC block you added deliberately. An .htaccess rule, a "disable XML-RPC" plugin, or a security plugin's XML-RPC toggle — the standard defence against XML-RPC brute-force attacks. It shuts out WordPress.com along with the attackers.
• A firewall in front of the site. A Cloudflare WAF, rate-limiting or bot-protection rule, or a ModSecurity rule on the server, answering WordPress.com with a 403.
• A server firewall on a VPS. CSF or another IP firewall that has blocked one of WordPress.com's addresses.

Start by checking what xmlrpc.php returns from outside the server:

curl -i https://yourdomain.com/xmlrpc.php

A reachable file answers a plain GET with 405 Method Not Allowed and the line "XML-RPC server accepts POST requests only." That is the healthy result. A 403, a Cloudflare challenge page or a redirect means something in front of WordPress is refusing it. To send a real XML-RPC call:

curl -s -X POST -H 'Content-Type: text/xml' \
  --data '<?xml version="1.0"?><methodCall><methodName>demo.sayHello</methodName></methodCall>' \
  https://yourdomain.com/xmlrpc.php

A working endpoint replies with Hello! inside an XML response. If both tests pass from your computer but the warning stays, the block is aimed at WordPress.com in particular, by IP address or as a bot. Look for refused requests to /xmlrpc.php in the firewall's own log: Cloudflare's security events, the ModSecurity hits in WHM (or ask your host), or your security plugin's log.

Don't fix it by opening xmlrpc.php to everyone again. Either let only Jetpack's IP ranges through the rule — Jetpack publishes them on its "Add Jetpack IPs to an Allowlist" support page, with a plain-text copy at jetpack.com/ips-v4.txt — or keep XML-RPC on and block only the system.multicall method that brute-force tools lean on. Once WordPress.com gets through, the notice clears on its own: Jetpack re-runs the check whenever you open Site Health, and once a day in the background.

"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.