WordPress Admin and Editor Problems: Diagnose REST API, Site Health and Block Editor Failures

WordPress admin problems often share the same background services. The Block Editor depends on the REST API, Site Health tests the REST API and other server-to-server functions, and plugins can add JavaScript or security rules that affect both. Treating each symptom as an unrelated problem can lead to unnecessary changes.

Quick diagnosis

Block Editor blank or endlessly loading: inspect browser JavaScript and REST requests first.
Site Health missing or stuck tests: check REST availability, loopback/HTTP requests, security rules, and server connectivity.
REST API error: identify the exact endpoint, status code, authentication state, and layer returning the response.

The REST API connects these symptoms

The WordPress REST API is a core interface used by modern WordPress features. WordPress’s own documentation describes it as a foundation of the Block Editor, and Site Health explicitly tests REST API availability because the editor relies on it.

If the editor and Site Health fail at the same time, do not immediately reinstall WordPress. First test the REST endpoint and determine whether a plugin, firewall, authentication layer, proxy, or server response is blocking it.

Start with the browser Network panel

Open the affected admin screen, then use Developer Tools → Network. Reproduce the problem and look for failed requests to /wp-json/, /wp-admin/admin-ajax.php, or other WordPress endpoints.

Record:

the request URL,
HTTP status code,
response body,
whether the request is authenticated,
and which script initiated it.

A 401, 403, 404, 429, 500, or timeout response points to a different layer and should not be treated as one generic “editor error.”

Check REST API availability separately

Open the public REST root at /wp-json/. A public response does not prove every authenticated editor request works, but it confirms whether the basic route is reachable.

If public routes work while authenticated editor requests fail, focus on cookies, nonces, authentication, security plugins, caching, proxies, and WAF rules. If even the REST root is blocked, check broader server and security configuration.

Site Health can reveal the layer that is failing

Site Health includes tests for REST availability and other WordPress communication paths. If only one test fails, follow that test rather than changing unrelated settings.

Security measures can intentionally block REST or outbound HTTP requests. WordPress core’s Site Health implementation recognizes those conditions, so review security constants, firewall rules, and hosting restrictions when a test reports blocked communication.

Block Editor failures also need JavaScript checks

The editor can fail even when the REST API is available if a plugin or theme loads broken JavaScript in wp-admin. Check the browser console for uncaught exceptions and test recently changed editor, SEO, security, analytics, or block plugins.

If the problem disappears after disabling one recently changed plugin, investigate that plugin before changing the server.

Safe troubleshooting order

Reproduce the problem once with Developer Tools open.
Record failed REST, AJAX, or JavaScript requests.
Test the REST root and the exact failing endpoint.
Check Site Health for REST or HTTP communication warnings.
Clear admin-related cache only after identifying a stale response.
Temporarily test recently changed plugins that affect the editor, REST, security, or caching.
Review WAF, CDN, hosting firewall, and authentication rules if requests are blocked before WordPress handles them.
Check PHP/server logs when the endpoint returns 5xx errors.

Official references

Bottom line: Block Editor, Site Health, and REST API symptoms often intersect. Start with the failing request and status code, then fix the responsible layer instead of applying the same eight generic changes to every admin problem.