WordPress Block Editor Won't Load? Fix the Blank Gutenberg Screen

You click "Edit" on a post and instead of the block editor, you get a blank white panel, an endless spinner, or a message that says "The editor has encountered an unexpected error." The rest of wp-admin still works fine - it's just the editor that's dead. This is one of the more confusing WordPress issues because nothing in your error log necessarily points at the real cause. Here's how to actually find it and fix it.

Symptom: What a Broken Block Editor Looks Like

It usually shows up in one of these forms:

• The post edit screen loads the admin bar and sidebar, but the content area stays blank or white
• A permanent "Loading editor" spinner that never resolves
• "Editor has encountered an unexpected error" with an option to copy the error, or a Try Again button that does nothing
• Blocks render but toolbar buttons (Add Block, Preview, Update) are unresponsive
• Editor loads fine for some post types but not others (e.g. Pages work, Posts don't)

Note this is different from a site-wide White Screen of Death on the front end - here the public site is usually fine. The problem is isolated to wp-admin/post.php and post-new.php.

Cause: Why Gutenberg Breaks While the Rest of the Site Works

The block editor is a JavaScript application that talks to your site through the WordPress REST API. It fails differently than a normal PHP page, which is why the usual troubleshooting steps don't always apply. The common causes, roughly in order of frequency:

1. The REST API is blocked or returning errors

Gutenberg loads posts, saves revisions, and fetches block data through /wp-json/wp/v2/. If a security plugin, firewall rule, or .htaccess block is returning a 403 or 401 on those endpoints, the editor UI loads but can't fetch or save content, so it hangs or errors out.

2. A plugin or theme JavaScript conflict

One enqueued script throwing a JS error can stop every other script on the page from initializing - including the editor. This is extremely common after a plugin update, especially page builders, SEO plugins, and anything that hooks into enqueue_block_editor_assets.

3. Corrupted post autosave or revision data

If the last autosave for that specific post got corrupted (often from a timeout mid-save), the editor can crash while trying to load that revision, even though every other post opens fine.

4. Browser cache or a browser extension

Ad blockers and privacy extensions sometimes block requests to /wp-json/ paths, mistaking them for tracking calls. A stale cached copy of wp-admin JavaScript after a WordPress update can also cause version mismatches between the editor's PHP and JS halves.

5. PHP memory or execution limits inside wp-admin

The block editor loads considerably more data per request than the classic editor did. On tight shared hosting limits, this can hit memory_limit or max_execution_time specifically in the admin context, even if the front end never comes close.

Fix: Work Through It in This Order

Step 1 - Check the browser console first

Open the post editor, press F12, and look at the Console tab. A red JavaScript error naming a specific file (often a plugin slug in the path) tells you exactly what to deactivate next. Don't skip this step - it saves you from guessing.

Step 2 - Rule out the REST API directly

Test the API independently of the editor UI:

curl -I https://yourdomain.com/wp-json/wp/v2/posts

You want a 200 OK. If you get 403 Forbidden, check (in this order): a security plugin's firewall rules, ModSecurity in cPanel (look for blocked requests to wp-json in the AutoSSL/ModSec logs), and any .htaccess rule that blocks query strings or specific user agents.

Step 3 - Deactivate plugins without losing your work

Don't deactivate through the dashboard if the admin area is also flaky - use WP-CLI over SSH or cPanel Terminal instead:

wp plugin deactivate --all# then reactivate one at a time to isolate the conflictwp plugin activate akismetwp plugin activate your-seo-plugin

Reload the editor after each reactivation. When it breaks again, you've found the culprit.

Step 4 - Switch to a default theme temporarily

wp theme activate twentytwentyfour

If the editor loads fine on the default theme, the problem is in your theme's functions.php or its editor style enqueues, not a plugin.

Step 5 - Clear every cache layer

Clear, in order: your browser cache (or just test in an incognito window first), any WordPress caching plugin, LiteSpeed/object cache if enabled, and Cloudflare's cache if the domain is proxied through it. wp-admin should never be cached, but misconfigured cache rules occasionally catch it anyway.

Step 6 - Recover from a bad autosave

If only one specific post is affected, open it with ?classic-editor appended if the Classic Editor plugin is installed, or check Posts > Revisions and restore an earlier version. As a last resort, you can clear the stuck autosave directly:

wp post list --post_type=revision --post_status=inherit --posts_per_page=5

Identify the orphaned autosave revision tied to that post ID and delete it with wp post delete <id>.

Step 7 - Raise wp-admin's PHP limits

In cPanel, go to MultiPHP INI Editor and bump these for the domain:

memory_limit = 256Mmax_execution_time = 120

This is a common quiet fix on shared hosting plans running the editor at the default 128M limit.

Quick Reference Table

Prevention

• Update plugins one at a time on a staging copy before pushing to production, especially page builders and SEO plugins that hook into the editor
• Keep a default theme installed (not activated) so you always have a fast fallback to test against
• Set memory_limit to at least 256M for WordPress sites doing any serious editing
• Whitelist /wp-json/ in any firewall or security plugin rules that block by path pattern
• Enable WordPress's built-in Health Check & Troubleshooting plugin so you can isolate conflicts without affecting live visitors

If you've worked through all six steps and the editor still won't load, it's worth checking your PHP error log in cPanel (Metrics > Errors) for a fatal error timestamp matching your test - sometimes the real failure is a PHP fatal that never reaches the browser console at all.