Blank Editor, Live Page Still Fine
If the page renders publicly but the editor is empty, your content is safe and the editor is what failed. That distinction decides the entire diagnosis, and it takes one browser tab to establish.
Quick fix: open the public URL of the page in another tab before you do anything else. If the content is still there, nothing has been lost and the editor is what failed — check the browser console next. If the public page is also empty, this is a content problem, and revisions are where you look.
The trap is the reflex to fix an empty editor by typing something in and pressing Update. That writes the empty state over content that was never actually gone, and it is the one action in this whole process that is genuinely destructive.
The editor is an application, not a page
The block editor loads as JavaScript in your browser, then fetches the post over the REST API and renders it. Three separate things must succeed: the editor scripts must load, the API request must return the content, and the blocks must parse. When any one fails, you get some flavour of empty canvas — and the flavour tells you which one.
That is why the live page can be perfect while the editor is blank. The frontend renders server-side from the database and never touches any of this machinery.
Read the symptom precisely
| What you see | Where it broke |
|---|---|
| Spinner that never resolves | Editor scripts blocked, or REST request hanging |
| Empty canvas, interface otherwise working | REST returned no content, or blocks failed to parse |
| "Invalid content" warnings in blocks | Saved markup no longer matches the block definition |
| A builder placeholder or "Edit with" button | The layout lives in a builder, not the content field |
| Raw shortcodes instead of rendered output | Normal, not a fault |
| Blank in editor and blank on the live page | Content genuinely changed — go to revisions |
Check the console and the network tab
This is the cheapest informative step and most people skip it.
- Console. A red JavaScript error naming a file inside
wp-content/plugins/or your theme is the answer outright. The editor stops rendering at the first uncaught error, so read the first one, not the last. - Network tab. Find the request to
/wp-json/wp/v2/pages/or/posts/. A 403 means something is blocking the REST API — commonly a security plugin, a firewall rule, or a hardening snippet that requires authentication for all API requests. A 500 means PHP failed while building the response. A request that never completes points at a timeout on a very large page. - Private window with extensions off. Ad blockers and privacy extensions do occasionally break editor requests. Thirty seconds to rule out, and it moves the fault off the server entirely.
If the REST API returns 403, confirm it directly by loading /wp-json/ in a browser. A working install returns a wall of JSON. The same dependency is behind the site editor failing to load, so a fix there usually fixes both.
Find out who owns the content
Page builders do not store layouts in the standard content field. They keep their own structure in post metadata and leave the content field with a fragment, a shortcode or nothing at all. Open the page in the builder and the layout appears — because that is where it lives.
This is not a fault to repair, it is a fact to know. Editing such a page in the block editor and saving can wipe the builder's output. If the builder itself will not open, that is a different diagnosis: an Elementor editor that will not load covers the equivalent checks for that stack.
Similarly, in a block theme the page's own content is only part of what visitors see. Headers, footers and surrounding layout come from template parts, so content you expected in the page editor may simply belong to a template — the same override logic that causes a site title that will not change.
Check revisions before assuming the worst
If the live page is empty too, open the revision history. Revisions are stored independently and survive most accidents: a bad paste, an autosave from a stale browser tab, a restore that landed on the wrong version, or two people editing simultaneously.
Restore the last good revision rather than retyping. If the revision list itself is empty, check whether revisions were disabled — some performance configurations switch them off, which is a decision worth revisiting after an incident like this.
Isolate, then prevent
If the console pointed at a plugin, confirm it by disabling that one plugin and reopening the page. If nothing was named, bisect rather than working one plugin at a time — finding plugin conflicts efficiently covers the halving method and why the culprit is usually a pair rather than a single plugin.
Two habits prevent nearly all repeat occurrences: update plugins in small batches so a broken editor has an obvious owner, and never save a page that opened empty. If the editor is unusable and you need to publish now, switching temporarily to the classic editor gets the content out safely while you diagnose properly.
Frequently asked
- Almost never. Load the public URL first: if the page still renders, the content is intact in the database and only the editor failed to display it. Do not save or publish over an empty editor, because that is what actually destroys the content.
- Builders store their layout in their own metadata and leave the standard content field largely empty, so the block editor has nothing meaningful to show. Open the page in the builder instead, and treat that builder as the only place the layout is editable.
- The saved markup no longer matches what the block expects, usually after a plugin or theme changed how it renders. The content is still there and recoverable; converting the block to HTML preserves it while you decide how to rebuild it.