Identify the failing request
The REST API supports editor and plugin workflows, but a generic Site Health warning does not reveal whether the failure is DNS, TLS, authentication, a redirect or a server error. Capture the exact URL, method, status, time and a request identifier when available. Do not share cookies, authorization headers or personal response data.
Open the public API index for the correct site URL and compare it with the failing operation. A public index may succeed while a signed-in editor request fails; the latter can involve a nonce, session, permission or plugin-specific route.
Follow the route
Check that the WordPress address and site address use the intended host and scheme. Review redirects for a loop or unexpected host change. Confirm that the web server supports the site's permalink configuration, then inspect the response body and application logs for the exact request.
If a CDN, WAF or security plugin is present, correlate the request with its event log. A rule blocking an editor request should be investigated by rule ID and path. Test a narrow, documented exception only after confirming that the request is legitimate; leaving the entire API unprotected can expose unrelated endpoints.
Check permissions and dependencies
A 401 or 403 may be intentional. Verify the logged-in account's capability, session and any application-specific authentication. A 404 can mean an unregistered route, while a 5xx usually requires origin-side investigation. These are leads, not a replacement for the response and logs.
After a targeted change, repeat the original editor or plugin operation, check an unauthorized request is still denied, and confirm Site Health no longer reports the same failure.
Further reading
Read the official documentation. For help applying these checks, explore Clouvenix services.