WordPress Site Health and cron loopbacks can receive HTTP 200 while a CDN, WAF, login redirect, or wrong virtual host returns HTML instead of the expected REST JSON or cron response. Monitoring only the status code marks that route healthy even though the application contract failed. Content type is a fast signal, but it must be paired with route-specific body fields because some proxies label challenge pages incorrectly.
Use this when Site Health is inconsistent, scheduled actions remain late, REST requests return parse errors, or server-side requests behave differently from browser requests.
Quick answer
Alert on status, final URL, Content-Type, and a small route signature. A REST test should require application/json plus expected keys. A cron test should verify the expected side effect, not invent a generic body requirement. Run the same request through public DNS, server DNS, IPv4, IPv6, and direct origin with the intended Host and TLS name.
What to check first
- Record method, exact URL, query, Host header, scheme, cookies, timeout, redirect policy, and expected response contract.
- Capture every redirect with Location, status, Content-Type, cache headers, server headers, content length, and a sanitized body fingerprint.
- Compare public DNS, server resolver, IPv4, IPv6, and direct-origin routes while preserving Host and TLS identity.
- Assert required JSON keys or the expected cron side effect in addition to status and content type.
- Check CDN custom errors, WAF challenges, login protection, maintenance pages, and cache rules for dynamic WordPress paths.
Why this usually happens
- The server can resolve its own hostname to a different edge or virtual host than external clients.
- A cache behavior can ignore path, query, or cookies and serve generic HTML for a dynamic endpoint.
- Security middleware may return an interstitial with status 200 to avoid appearing unavailable.
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/
rg -i '^(HTTP|content-type|location|age|via|server):' headers.txt
file body.txt
jq 'has("namespaces")' body.txt
curl -sS --resolve example.com:443:203.0.113.24 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 response contract for each failing loopback route. | Record method, exact URL, query, Host header, scheme, cookies, timeout, redirect policy, and expected response contract. | REST loopbacks return JSON with expected route fields from the WordPress host. |
| Capture public, server-resolved, and direct-origin responses with redirects exposed. | Capture every redirect with Location, status, Content-Type, cache headers, server headers, content length, and a sanitized body fingerprint. | Cron loopbacks trigger the expected controlled action within its time budget. |
| Correct the DNS, virtual host, cache, WAF, or authentication rule that changes the response. | Compare public DNS, server resolver, IPv4, IPv6, and direct-origin routes while preserving Host and TLS identity. | Public and origin routes use the intended host and equivalent application response. |
| Purge only affected dynamic paths after fixing the policy. | Assert required JSON keys or the expected cron side effect in addition to status and content type. | Monitoring alerts on wrong content before queue delay or Site Health becomes the first symptom. |
Decision rule
Pass only when route, status, content type, body signature, and expected side effect agree. Treat a 200 homepage, login page, challenge, or stale object as a failed loopback.
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 |
|---|
| REST root | Server-side GET to /wp-json/ | 200, JSON content type, and expected namespaces key |
| Homepage substitution | Mis-keyed edge fixture | Alert fires when HTML replaces the REST response |
| Challenge response | Controlled WAF rule for server IP | Alert records challenge headers and body fingerprint even if status is 200 |
| Direct origin | Origin IP with correct Host and certificate name | Origin contract identifies whether the fault sits at edge or application |
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 response contract for each failing loopback route.
- Capture public, server-resolved, and direct-origin responses with redirects exposed.
- Correct the DNS, virtual host, cache, WAF, or authentication rule that changes the response.
- Purge only affected dynamic paths after fixing the policy.
- Rerun Site Health and a controlled cron action from the WordPress host.
Production verification checklist
- REST loopbacks return JSON with expected route fields from the WordPress host.
- Cron loopbacks trigger the expected controlled action within its time budget.
- Public and origin routes use the intended host and equivalent application response.
- Monitoring alerts on wrong content before queue delay or Site Health becomes the first symptom.
What to tell the client or owner
Give the owner the affected versions, exact fixture, stable IDs, UTC timeline, before and after evidence, decision, rollback point, unresolved risks, and next review date.
Mistakes to avoid
- Do not change several production layers at once. Preserve the failing evidence and isolate one variable per test.
- Do not use a successful status or screen message as the only proof. Verify the business outcome and the underlying record.
- Do not leave debug logging, broad credentials, test orders, or temporary exceptions active after the review.
- Do not close the incident without recording the fixture, timestamps, owner, result, and rollback point.
Questions teams ask during testing
Can this be tested on staging?
Start on staging with production-like versions, cache, data shape, and integrations. Finish with one controlled production fixture when the result depends on real routing, provider, or edge behavior.
What evidence should be retained?
Keep the smallest useful set: stable IDs, UTC timestamps, sanitized request or log excerpts, expected result, actual result, version inventory, and the final verification.
When should the change be rolled back?
Roll back when a core revenue, privacy, security, or publishing path fails and the cause cannot be isolated inside the approved maintenance window.
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.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references