Divi Builder Blank Page in WordPress: Causes and the Fix

You click "Build on the Front End" and instead of the Divi editor you get a blank white page, an endless spinner, or a page that loads but none of your modules render. It's one of the most common support tickets we get from Divi users, and the good news is it's almost never Divi itself that's broken — it's usually something fighting with it. Here's how to actually find the cause instead of guessing.

What "Divi won't load" usually looks like

There are a few different failure patterns, and they point to different causes:

• Pure white screen when you click into the Visual Builder — usually a PHP fatal error or memory exhaustion.
• The builder frame loads but content never appears, spinner runs forever — usually a blocked AJAX or REST API call.
• The page loads in the backend (wp-admin) but the front-end builder never activates — usually a JavaScript conflict or a security plugin blocking a script.
• It worked yesterday, broke after an update — usually a stale cache or a version mismatch between Divi and WordPress core.

Match your symptom to the table below, then jump to the matching fix.

Fix 1: Check for a PHP fatal error first

A true blank white page with nothing in the browser's dev console (Network/Console tabs) almost always means PHP died silently. Turn on debug logging so you can actually see it instead of guessing:

// In wp-config.php, above "That's all, stop editing!"
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Reload the builder, then check wp-content/debug.log through cPanel's File Manager. If you see "Allowed memory size exhausted," that's your answer — jump to Fix 2. If you see a fatal error naming a specific plugin, deactivate that plugin and retest.

Fix 2: Raise the PHP memory limit for Divi specifically

Divi's Visual Builder loads a lot of JS and layout data at once, and the default 128M PHP memory limit on many shared plans just isn't enough once you've got a handful of other plugins active. In cPanel, go to Software → MultiPHP INI Editor, select your domain, and bump memory_limit to at least 256M:

memory_limit = 256M
max_execution_time = 120

If you don't have access to MultiPHP INI Editor, add this to wp-config.php instead (near the top, before the memory_limit line if one already exists):

define( 'WP_MEMORY_LIMIT', '256M' );

Divi's own dashboard (Divi → Theme Options → General) also has a "Static CSS File Generation" toggle — leave it on, it actually reduces the load per page.

Fix 3: Clear Divi's own cache, not just your caching plugin

Divi keeps its own compiled CSS/JS cache separate from whatever caching plugin you're running, in wp-content/et-cache/. If you recently updated Divi, changed a theme option, or edited custom CSS and the builder is showing stale or broken layouts, this folder is usually why.

1. Go to Divi → Theme Options → General and click Clear Divi Cache if you see the button (available in recent Divi versions).
2. If there's no button, connect via cPanel File Manager or FTP, navigate to public_html/wp-content/et-cache/, and delete everything inside it. Divi rebuilds it automatically.
3. Then clear your separate caching plugin (WP Rocket, LiteSpeed Cache, W3 Total Cache) and any CDN cache (Cloudflare included) so you're not looking at an old cached version of the broken page.

If permissions on that folder got mangled by a bad restore or migration, reset them to 755 for the directory so WordPress can write to it again.

Fix 4: Check for blocked AJAX or REST API calls

Divi's front-end builder talks to WordPress constantly through admin-ajax.php and the REST API to save your changes and load module data. If a firewall or security plugin is blocking those requests, the builder frame loads but nothing ever populates — the classic "stuck spinner."

Open your browser's dev tools (F12), go to the Network tab, reload the builder, and filter for admin-ajax or wp-json. If you see requests failing with 403 or 406:

• In Wordfence, check Firewall → Rate Limiting and whitelist your own IP, or temporarily set the firewall to Learning Mode while you test.
• In Imunify360/ModSecurity (common on cPanel servers), check Security → ModSecurity in cPanel for a rule that's blocking the request, and note the rule ID so support can whitelist it for your domain.
• If you're behind Cloudflare, make sure Cloudflare's Bot Fight Mode or a WAF rule isn't challenging AJAX requests from your own admin session.

Fix 5: Rule out a JavaScript conflict

If the backend loads fine but the front-end Visual Builder never activates, check the browser console for red errors mentioning jQuery, et_pb, or a script from another plugin. The usual suspects are other page builders (Elementor, WPBakery) left active alongside Divi, aggressive JS-minification/combination settings in a caching plugin, and third-party "speed" plugins that defer or async-load scripts Divi needs to load in order.

Fast way to isolate it: deactivate all plugins except Divi/Divi Builder itself, retest the builder, then reactivate plugins one at a time until it breaks again. Switching to a default theme isn't useful here since Divi is the theme/builder itself, but disabling any child theme customizations temporarily can help rule those out too.

Fix 6: Confirm Divi and WordPress core versions actually match

After a WordPress core auto-update, an outdated Divi version can throw compatibility errors that only show up inside the builder, not on the front end of your site. Check Divi → Support Center → System Status for the installed Divi version against Elegant Themes' changelog, and update Divi from Divi → Theme Builder → Updates (or manually via FTP/File Manager if the dashboard update fails).

Prevention checklist

• Keep PHP memory at 256M or higher on any site running Divi with more than a few plugins.
• Clear et-cache after every Divi update or major theme option change, before reporting a bug.
• Whitelist your own admin IP in any security plugin or ModSecurity ruleset so builder AJAX calls never get challenged.
• Avoid running two page builders (e.g. Divi and Elementor) active on the same install — even inactive ones can leave stray shortcodes or scripts behind.
• Take a snapshot or full backup before major Divi version jumps, especially between major releases.

Still stuck?

If you've gone through all six fixes and the builder still won't load, the debug log from Fix 1 is the fastest way to get real help — paste the exact PHP error into a support ticket rather than describing the symptom, and whoever's helping you can usually spot the cause in under a minute.