WordPress Site Health uses REST API and loopback checks to verify that WordPress can talk to itself and run scheduled tasks. Failures can affect cron, editors, plugin updates, form actions, and background processing.
Use this when Site Health reports REST API errors, loopback request failures, failed scheduled events, or cURL errors after a hosting, SSL, DNS, WAF, or plugin change.
Quick answer
WordPress Site Health REST API and Loopback Fix should be handled with a narrow evidence-first workflow: record message, compare fetches, check network layers, then verify the result before making broader changes.
What to check first
- Record the exact Site Health message, endpoint, status code, and error text.
- Fetch the REST endpoint and loopback URL from the server and from outside the server.
- Check SSL certificate, DNS, redirects, basic auth, WAF rules, and host firewall rules.
- Review cron, object cache, page cache, and security plugin settings.
- Retest after disabling only the suspected layer, not every plugin at once.
Diagnostic table
Use this table to keep the work practical. It connects the symptom to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|
| Record message | Record the exact Site Health message, endpoint, status code, and error text. | Site Health no longer reports REST API or loopback critical errors. |
| Compare fetches | Fetch the REST endpoint and loopback URL from the server and from outside the server. | Scheduled events run without repeated missed schedule warnings. |
| Check network layers | Check SSL certificate, DNS, redirects, basic auth, WAF rules, and host firewall rules. | The block editor, plugin updates, and form submissions still work. |
| Review cron and cache | Review cron, object cache, page cache, and security plugin settings. | Any WAF or cache exception is documented with the exact path and reason. |
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
wp cron event list
curl -sS -I --max-time 15 https://example.com/wp-json/
curl -sS -I --max-time 15 https://example.com/wp-cron.php?doing_wp_cron
wp option get home
wp option get siteurl
Safe fix order
Do the work in a sequence that makes each result easy to prove. Stop if a step produces new evidence that changes the incident scope.
- Record message
- Compare fetches
- Check network layers
- Review cron and cache
- Retest narrowly
Production verification checklist
- Site Health no longer reports REST API or loopback critical errors.
- Scheduled events run without repeated missed schedule warnings.
- The block editor, plugin updates, and form submissions still work.
- Any WAF or cache exception is documented with the exact path and reason.
Mistakes to avoid
- Do not judge the fix by one browser or the homepage only.
- Do not delete evidence before recording usernames, file paths, timestamps, and response headers.
- Do not add a cache, security, or tracking plugin while the original problem is still unclear.
- Do not leave test users, temporary debug logs, or broad API keys active after verification.
When HandL WP should help
Bring in help when this affects leads, checkout, search visibility, malware risk, paid media reporting, or a client production site. HandL WP can trace the issue through WordPress, hosting, cache, tracking, and Search Console, then verify the workflow after the technical fix.
If this is active on a production site, fix WordPress Site Health critical errors.
Loopback 401 and 403 access decisions
When the loopback response is an authentication or authorization denial, use the WordPress loopback 401 and 403 authentication matrix to separate Basic Auth, CDN, WAF, maintenance, security-plugin, and WordPress permission layers.
Compare browser and server-self request context
When a page works in the browser but Site Health still reports a loopback failure, use the loopback cookie, authentication, and nonce context diff to compare external, origin, and WordPress HTTP requests before changing the firewall or application.
Compare the IPv4 and IPv6 loopback routes
Run the WordPress IPv6 AAAA and origin mismatch test when Site Health works over IPv4 but the server can resolve its own hostname to another IPv6 route.
Assert the loopback response body, not only status
Use the WordPress loopback HTTP 200 wrong-body detector when a proxy, cache, challenge, or default virtual host returns successful status with the wrong payload.
Alert when a loopback returns the wrong content type
Add the WordPress loopback content-type mismatch alert when a CDN, WAF, login page, or wrong host returns HTTP 200 without the expected REST or cron contract.
Helpful references
Check Basic Auth and staging locks
If the loopback works externally but fails from the server, use the WordPress loopback Basic Auth debug guide to compare self-requests, DNS, access rules, WAF logs, and cron recovery.
Compare IPv4, IPv6, DNS, and TLS
When the loopback fails only from the server, use the WordPress IPv6 and DNS mismatch guide to compare A and AAAA records, proxy routes, certificates, and cron recovery.
Check TLS SNI and the origin virtual host
If a self-request reaches the expected IP but receives the wrong certificate or site, use the WordPress loopback TLS and SNI guide to compare DNS, certificate SANs, proxy routing, IPv4, IPv6, and origin virtual hosts.