The WordPress editor may stay blank, spin forever or appear to save without keeping the change. Those symptoms feel similar, but they point to different failures. A page that cannot load is not the same as a save request that reaches the server and gets rejected.
Before changing plugins or restoring a backup, note exactly when the problem appears. Your existing content may still be safe even when the editor cannot display it, and the failed browser request often tells you which layer needs attention.
Use a harmless draft for checks, and keep the exact error. A login problem, a firewall block and a PHP failure can look similar on the screen but need different repairs.
Guide reviewed: October 8, 2026. Menu labels use English WordPress; provider-specific controls may differ.
Separate a loading failure from a saving failure
| Symptom | First comparison | Next evidence |
|---|---|---|
| Blank editor on every post | Signed-in private browser session | Console error or failed script |
| Editor opens, save fails | Save a harmless draft | Failed request status and response |
| Only one complex post fails | Ordinary post versus affected post | Blocks or plugins unique to the affected page |
| Site Health reports REST problem | Read the full failed test | Endpoint, response and host log |
| Public REST root works, saving does not | Authenticated write request | Session, nonce, capabilities or specific rule |
What happens when you open the editor?
- Copy unsaved text to a safe private note.
- Try a new harmless draft without extra blocks.
- Sign in through a private browser session and compare that draft.
- Record whether opening, editing or saving is the failing action.
Notice whether the screen is completely blank, keeps loading, or opens but refuses to save. Also note whether every post is affected or only a post containing a particular block. If an ordinary post works while one complex page does not, the blocks or plugins used on that page deserve a closer look.
A private browser window can provide a useful comparison after you sign in there. If the editor works in that window, an extension, stale browser data or the original session may be involved. This test narrows the search; it does not prove that the server is healthy in every respect.
The failed request usually gives a clearer clue
- Open browser Developer Tools → Network.
- Attempt one save on the test draft.
- Select the failed request and record its endpoint, status and response type.
- Compare the response with the editor message before contacting support.
Example: a request expecting JSON receives an HTML security-block page. That is a clue to inspect the blocking rule; it does not justify disabling authentication on every REST route.
With the browser’s developer tools open, reload the affected screen and look in the Network panel. The editor may contact REST routes under /wp-json/, AJAX endpoints or other plugin-specific services. A failed request’s address, status and response are more informative than the general message displayed by the editor.
A 401 response often relates to authentication. A 403 can involve permissions, an expired nonce or a security rule. A 404 may mean the route is unavailable, while a 429 points toward rate limiting. For a 5xx response, the server or PHP logs usually become important. These are clues rather than complete diagnoses: the text returned with the response helps identify who generated it.
For example, an HTML firewall page returned to a request expecting JSON is different from a WordPress permission error. Record the endpoint and the time of the failure before contacting the host or plugin developer. Remove session cookies, authorization headers and private content from anything you share.
A working REST root is only part of the picture
Opening the site’s public REST root, usually /wp-json/, shows whether that route is reachable. It does not establish that a logged-in editor can save a post. Public reads and authenticated editing requests use different permissions and session information.
If the public route works but saving fails, compare the authenticated request. Cookies, nonces, user capabilities, cache behavior and security rules are all relevant. Making every REST endpoint public would not be an appropriate way to repair an authenticated request.
If the REST root itself returns a missing-page response, rewrite or routing behavior may be involved. If it returns a block page, the security service that produced the page is the more useful place to investigate.
Site Health helps explain communication problems
- Open Tools → Site Health.
- Expand the failing test and copy its non-sensitive details.
- Distinguish REST availability from loopback or outbound HTTP failures.
- Give the host the endpoint and timestamp for the relevant request.
Under Tools → Site Health, WordPress reports tests involving REST availability and other communication paths. Read the detail of the failed test rather than treating every warning as the same problem. A loopback request, an outbound HTTP connection and an authenticated editor request are related but not interchangeable.
A hosting restriction or security rule may intentionally limit communication. When that restriction interrupts a required feature, the remedy should address the specific request and retain the protection elsewhere. The host can often interpret a request timestamp together with the relevant logs.
Sometimes the API works, but the editor script does not
The Console panel can reveal a JavaScript error even when REST responses look normal. A recently changed block, SEO, analytics or editor plugin may load code into the administration screen. An error there can prevent part of the interface from finishing its work.
A test copy of the site makes it easier to compare behavior with the suspected plugin disabled. If the editor recovers, restore the plugin and repeat the test so you can be confident about the connection. Disabling several plugins together may restore access, but it leaves more work to discover which one mattered.
A practical recovery test
Once the affected request or script is corrected, reopen the editor and save a harmless change to a draft. That checks the write operation as well as the screen itself. Then run the relevant Site Health test again and look for remaining Console errors.
Finally, repeat the original task with the plugins and protections you intend to keep enabled. A short record of the failed endpoint, the responsible component and the setting changed is valuable when the same symptoms return after a future update.
WordPress references and the next useful guide
- WordPress REST API Handbook
- WordPress Developer Reference: Site Health REST availability test
- WordPress REST API: Site Health Tests
- WordPress 404 errors and rewrite troubleshooting
- WordPress content not showing by output layer
Verify a real save, not just a loaded editor
After the correction, save a harmless draft, close it and reopen it. Confirm the change persisted. Repeat the original affected task with intended plugins and protections enabled, then rerun the relevant Site Health test. A public API read alone does not verify editor write access.