WordPress loopback diagnostics can receive HTTP 200 even when a proxy, cache, login redirect handler, bot challenge, or wrong virtual host returns the homepage instead of the expected REST or cron response. A status-only test says reachable while the application contract is broken.
Use this when Site Health reports inconsistent loopback behavior, scheduled events remain late, REST checks fail intermittently, or curl receives 200 but the response content looks like a generic site page.
Quick answer
Test the exact loopback URL from the origin host, send the intended Host header and scheme, and assert content type plus a small expected body signature. Record redirects, response headers, cache status, and a body hash. A 200 response that lacks the expected REST fields or cron behavior is a failed contract, not a successful loopback.
What to check first
- Capture the exact URL, method, query string, Host header, scheme, cookies, timeout, and expected content type used by WordPress.
- Follow and separately record redirects so a login, canonical, or challenge hop cannot hide behind a final 200.
- Compare public DNS, server DNS, IPv4, IPv6, and direct-origin routing with the same Host and TLS name.
- Assert expected JSON keys, REST route identity, or cron side effect instead of checking only the status code.
- Record CDN cache, Age, Via, Server, Set-Cookie, content length, and a body fingerprint for each route.
Why this usually happens
- A proxy can route the server's own hostname to a default virtual host while browsers reach the correct edge.
- Cache rules may ignore query strings or cookies and serve a generic HTML object for a dynamic route.
- Security middleware can return a branded challenge page with status 200 so simple uptime checks remain green.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
curl -sS -D headers.txt --max-time 20 -o body.txt 'https://example.com/wp-json/'
file body.txt
head -c 240 body.txt
shasum -a 256 body.txt
curl -sS --resolve example.com:443:203.0.113.24 -H 'Host: example.com' 'https://example.com/wp-json/' | jq 'has("namespaces")'
Diagnostic table
Use this table to connect the observed behavior to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|
| Define the expected loopback response contract for the failing route. | Capture the exact URL, method, query string, Host header, scheme, cookies, timeout, and expected content type used by WordPress. | The exact loopback route returns the expected content type and required body fields from the application host. |
| Capture public, server-resolved, and direct-origin responses with complete redirect headers. | Follow and separately record redirects so a login, canonical, or challenge hop cannot hide behind a final 200. | Public and direct-origin requests use the same intended virtual host and produce equivalent route identity. |
| Correct DNS, virtual-host, cache, authentication, or challenge rules at the layer that changes the body. | Compare public DNS, server DNS, IPv4, IPv6, and direct-origin routing with the same Host and TLS name. | No redirect, challenge, or cache rule substitutes generic HTML for the dynamic response. |
| Purge only the affected dynamic route if stale cache participated. | Assert expected JSON keys, REST route identity, or cron side effect instead of checking only the status code. | Site Health and a controlled scheduled event pass after the routing fix. |
Decision rule
Pass the loopback only when status, content type, route identity, body signature, and expected side effect all agree. Escalate any 200 response that belongs to a homepage, login, challenge, another tenant, or stale cache object.
Test scenarios to run
Run the same controlled fixture across these branches. Write down the expected result before testing so a surprising response is easy to identify.
| Scenario | Fixture | Expected result |
|---|
| Expected REST response | Exact route with application/json expectation | 200 plus required JSON keys and route-specific values |
| Homepage substitution | Same route through CDN | Detector fails when HTML title or homepage hash replaces JSON |
| Login substitution | Loopback without required cookie or nonce | Authentication response is identified even if final status is 200 |
| Origin routing | Resolve hostname to origin IP with correct Host and TLS name | Origin and public route return equivalent contract content |
Safe fix order
Use a sequence that makes each result easy to prove. Stop when new evidence changes the scope or owner of the problem.
- Define the expected loopback response contract for the failing route.
- Capture public, server-resolved, and direct-origin responses with complete redirect headers.
- Correct DNS, virtual-host, cache, authentication, or challenge rules at the layer that changes the body.
- Purge only the affected dynamic route if stale cache participated.
- Rerun Site Health, cron, and the content assertion from the application host.
Production verification checklist
- The exact loopback route returns the expected content type and required body fields from the application host.
- Public and direct-origin requests use the same intended virtual host and produce equivalent route identity.
- No redirect, challenge, or cache rule substitutes generic HTML for the dynamic response.
- Site Health and a controlled scheduled event pass after the routing fix.
What to tell the client or owner
Provide exact route, request method, expected contract, DNS answers, tested IPs, redirect chain, response headers, sanitized fingerprints, failing layer, configuration change, and retest result.
Mistakes to avoid
- Do not call every HTTP 200 a successful loopback.
- Do not test only from a laptop when the failure occurs on the WordPress host.
- Do not bypass TLS name and Host routing during the direct-origin comparison.
- Do not paste full authenticated response bodies into public tickets.
Questions teams ask during testing
Why would a challenge page return 200?
Some security products serve an interstitial as normal HTML. The body and headers reveal that it is not the application response.
Should REST root always return JSON?
The expected contract depends on the exact route and authentication, but a known REST route should not silently become homepage HTML.
Can a cache purge fix it?
Only when evidence proves a stale or mis-keyed cache object. Fix the cache policy before relying on repeated purges.
When HandL WP should help
Bring in help when this affects leads, checkout, search visibility, security, 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, debug a WordPress loopback response.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references