A Site Health REST API alert needs its endpoint, status and full message to become useful. A timeout, authentication refusal and unexpected HTML response lead to different investigations.
Keep the diagnostic details and compare them with one harmless action that uses the affected feature.
Guide reviewed: October 8, 2026. Interface labels may vary by version, account and device.
Quick diagnosis
| Response | Investigation | Check |
|---|---|---|
| 401 or access prompt | Expected authentication | Endpoint method and session. |
| 403 or security page | Permission or firewall refusal | Matching request event. |
| 404 | Endpoint discovery and routing | Correct URL and server rules. |
| Timeout | Server connectivity or delayed processing | Destination and logs. |
| PHP session warning | Session handling in identified code | Developer review of the reported warning. |
Read the complete Site Health message
Record separately: endpoint, response code, response text and test time. Keep any loopback warning as a distinct result. The Info screen displays configuration; changes belong in the appropriate settings or hosting controls.
WordPress’s Site Health screen has a Status tab for checks and an Info tab for configuration details. Expand the reported issue and preserve the endpoint, status, and message it shows. The Info tab is a report; it is not a place where a displayed setting can be changed directly.
A response such as 401, 403, or 404 suggests a different investigation from a connection timeout. If the message names a PHP warning or shows an unexpected page, that is another useful distinction. Do not replace all of those details with “API broken” when contacting support.
For example, an authentication prompt returned where the test expects an API response points toward that request’s access path. A request that never connects points elsewhere. The same top-level alert can cover both situations.
Check which normal activity fails
Compare the alert with the website’s behavior. Can you save a harmless draft, load the relevant editor feature, or use the integration that reported the failure? Record one failing action and one working comparison.
Do not test important live transactions merely to gather evidence. Use an appropriate test workflow for shop or membership features. Preserve unsaved text before refreshing an editor.
If Site Health reports a loopback problem as well, keep it as a separate result. A loopback concerns the website contacting itself, while the REST API label concerns a particular interface. Related configuration may affect both, but one message should not be assumed to explain the other.
Follow the response rather than a generic checklist
If the request is rejected for authentication, have the developer review the authentication expected by that endpoint. If it is blocked, ask the host to compare the request time with the relevant access or security logs. If it times out, ask which connection or service failed to respond.
For an unexpected response body, the developer should inspect what the server returned. An error page or warning inserted before the expected data can be important evidence. Hiding the warning without correcting its cause does not establish that the feature works.
WordPress’s Site Health documentation also notes that an active PHP session can interfere with REST API and loopback requests. If that warning is actually present, give it to the developer for review. It is a specific lead, not a setting every site owner should change blindly.
Review recent changes safely
- Preserve the failed response privately.
- Choose one harmless action that reproduces the issue.
- Compare the suspected change on staging.
- Repeat both the diagnostic check and the action after the correction.
If a plugin, server, or security configuration changed just before the failure, compare that change in a staging copy or controlled troubleshooting setup. Preserve a backup and change one relevant component at a time.
A host may need to identify the component returning the response before WordPress receives the request. A developer may need to inspect a custom endpoint. Knowing the boundary prevents unrelated theme changes from becoming part of the investigation.
Do not make protected API data public as a workaround. Some endpoints intentionally require an authorized request. A successful repair should let the intended feature work with its intended access controls.
Verify both the check and the feature
After the correction, rerun the relevant Site Health check and repeat the original harmless action. Confirm that the expected result is saved or returned. A cleared alert and a working feature together provide more useful evidence than either alone.
When asking support for help, include the endpoint, exact message, time with its time zone, recent changes, and the affected feature. Redact credentials, cookies, and private data from copied responses.
Keep the confirmed cause in a short maintenance note. “The API check received an access prompt from the staging protection” is a clearer record than “fixed after clearing caches.” That specificity will make the next incident easier to interpret.
References: WordPress’s Site Health guide and REST API frequently asked questions.
Confirm the check and the actual feature
Rerun the relevant Site Health test and inspect the expected saved or returned result. Keep protected endpoints restricted. Document the responding component and confirmed cause so later diagnosis begins with the actual boundary that failed.