WordPress Loopback Request Failed: Why Site Health Cannot Call the Site

What matters first: WordPress uses loopback requests for scheduled tasks, the editor and background operations. Failure means the server’s own HTTP client cannot complete a request to the site’s public URL.

What this symptom actually tells you

The front end can work for visitors while loopbacks fail internally because server-side DNS, IPv6, TLS, basic authentication or a WAF follows a different path.

Capture evidence before changing anything

• Copy the exact loopback URL and error from Site Health.
• Request that URL from the WordPress host and inspect DNS, redirects and TLS.
• Check whether staging protection, basic auth or maintenance rules block internal calls.
• Compare IPv4 and IPv6 resolution if the domain publishes both.

Most common causes

• Self-DNS problem: The server resolves the domain to an unreachable or outdated address.
• Authentication boundary: Basic auth, SSO or a maintenance gate blocks the internal request.
• TLS validation failure: The host cannot validate its own certificate chain.
• Firewall or CDN rule: The server’s outgoing IP is challenged or blocked when returning through the public edge.

Safe diagnostic and repair sequence

1. Make the site’s canonical URL reachable from the host without weakening public security.
2. Correct split DNS or hosts configuration only when it reflects the real production route.
3. Allow the server’s authenticated loopback path through the specific protection layer.
4. Re-test Site Health and a real cron or editor operation that depends on loopbacks.

How to choose between the likely causes

Do not treat Self-DNS problem and Authentication boundary as interchangeable. The server resolves the domain to an unreachable or outdated address. By contrast, basic auth, SSO or a maintenance gate blocks the internal request. Use two checks to separate them: Copy the exact loopback URL and error from Site Health; and request that URL from the WordPress host and inspect DNS, redirects and TLS. Those observations usually show whether the next safe move is to make the site’s canonical URL reachable from the host without weakening public security or to preserve the current state and widen the investigation.

On a production WordPress site, repeat the failing request while checking a known-good page and the admin area. A fault isolated to one route calls for a narrower rollback than a failure affecting PHP, the database or every request. Record the exact timestamp, affected URL or transaction, last known good state and every change made during diagnosis. That handover is often what separates a repeatable repair from a temporary disappearance of the symptom.

What not to do

Do not disable loopback tests or cron as a workaround. The hidden failure will surface later as missed tasks, stalled updates or editor errors.

How to verify the repair

• Site Health reports a successful loopback request.
• A scheduled single event runs without an external cron trigger.
• The block editor and background update checks complete normally.

A visible symptom disappearing is not enough. Close the incident only when the original failing action, the surrounding business journey and the relevant logs all agree that the fault is gone.