How to Fix Elementor Errors: “The preview could not be loaded”, a Stuck Loading Screen and “Server Error 500”

You click Edit with Elementor and the logo spins forever. Or a box says “The preview could not be loaded” with a small link reading “Click here for preview debug”. Or the editor opens, but saving ends in “Server Error (500 Internal Server Error).” or “Connection Lost.” Meanwhile visitors may see a perfectly normal site.

The Elementor editor is really two pages working together: the editing panel, and a hidden copy of your real page loaded inside a frame. Each message tells you which half failed. This guide shows you how to read the message, prove the cause, and fix it with Elementor’s own tools: Safe Mode, Clear Files and Data, Version Control, Replace URL, System Info and the WP-CLI commands. If several builders or plugins broke after one round of updates, our general page builder update guide covers that case.

What is happening

The editor is an admin page at post.php?post=POST_ID&action=elementor. It draws the panel, then loads your front-end page in an iframe with a parameter that boots Elementor in preview mode. When the iframe finishes, the editor checks whether Elementor’s front-end script started inside it. Every later action (loading widgets, saving, templates) is an AJAX request to wp-admin/admin-ajax.php. Elementor’s source code maps each message to a failure:

What you see	What failed	Go to
“The preview could not be loaded” plus “Click here for preview debug”	The iframe loaded, but Elementor never started in it: a redirect, an error, or a page rendered without Elementor	Step 1
“Sorry, the content area was not found in your page.”	The page template never calls the_content()	Step 1
Endless spinner, then after about 30 seconds “Having problems loading Elementor? Please enable Safe Mode to troubleshoot.”	The editor never finished booting, usually a script error or a failing request	Step 2
“Server Error (500 Internal Server Error).” or “Server Error” plus a code	An AJAX request returned a non-200 status	Step 3
“Connection Lost.”	The request never completed: dropped by a firewall, a timeout, or the network	Advanced section

Before you start

You need a WordPress administrator account, plus your hosting control panel (PHP settings, error log, File Manager) or SSH. Back up the database before using Version Control, Replace URL or Features toggles, because they change stored data.

• Server commands run in an SSH terminal from the site folder that contains wp-config.php. WP-CLI is wp on most hosts and wp-cli on some. Elementor adds its own wp elementor commands.
• Browser checks use developer tools: F12, or Cmd+Option+I on a Mac.
• File edits mean editing wp-config.php in File Manager or over SFTP. Keep a copy of the original.

Step 1: Read the preview debug page

Do not start disabling plugins yet. Click the Click here for preview debug link. It opens the preview URL with &preview-debug added in a new tab, so you see exactly what the hidden iframe received:

• The address bar changed. Something redirected the preview: a redirect plugin, a www or HTTPS rule, a language or maintenance plugin. The iframe lands where Elementor is not in preview mode.
• A 404 page. Rewrite rules are broken or, on Apache, .htaccess is missing. Elementor checks for a missing .htaccess and names the path when it finds one.
• A critical error or blank page. PHP crashed. Go to Step 3.
• The login screen. Your cookie is not valid for this URL, usually because the Site Address and WordPress Address differ.
• A normal page. Elementor’s script did not run inside it, often because an optimization plugin delayed or combined scripts. That is a conflict: go to Step 2.

Fix redirects and routing

wp option get home
wp option get siteurl

These run over SSH and take no placeholders. Good output is the same URL twice, such as https://www.example.com. Any difference (www versus none, http:// versus https://, an extra path) is bad. Fix it under Settings, General, then log out and back in so your cookie is reissued.

Next, rebuild the rewrite rules (clicking Save Changes under Settings, Permalinks does the same):

wp rewrite flush --hard

This runs over SSH. --hard also rewrites .htaccess on Apache and LiteSpeed. Good output is “Success: Rewrite rules flushed.” A warning about .htaccess means the file is missing or not writable. On Nginx there is no .htaccess; routing depends on a try_files line your host controls.

Fix “the content area was not found”

Elementor injects its layout where the template calls the_content(). Switch the page’s Template setting to the theme default or “Elementor Full Width”. If that works, the old template needs a the_content(); call inside the loop.

Step 2: Use Elementor Safe Mode to test for conflicts

Go to Elementor, Tools, General, set Safe Mode to Enable and save. Elementor has reorganized its admin menu in recent versions; if you cannot find Tools, go to wp-admin/admin.php?page=elementor-tools.

Safe Mode writes a must-use plugin to wp-content/mu-plugins/elementor-safe-mode.php. For editor requests carrying elementor-mode=safe and your personal Safe Mode cookie, it loads only Elementor (and Pro) and no theme. Visitors still get the normal site.

• The editor loads in Safe Mode: the theme, another plugin or custom code is the cause.
• It still fails: look at the server, Elementor itself, or a host must-use plugin Safe Mode cannot switch off. Go to Step 3.
• “Please note! We couldn’t deactivate all of your plugins on Safe Mode.” The mu-plugins folder is missing or not writable, so the test is not clean.

To find the plugin, bisect on a staging copy:

wp plugin list --status=active --field=name
wp plugin deactivate PLUGIN_SLUG_ONE PLUGIN_SLUG_TWO

These run over SSH on staging. The first prints one active plugin folder name per line. PLUGIN_SLUG_ONE and PLUGIN_SLUG_TWO are names from that list: deactivate half, test the editor, and narrow down. Good output is “Success: Deactivated 2 of 2 plugins.” Never deactivate elementor or elementor-pro here. Set Safe Mode back to Disable when you finish.

Usual suspects: script optimization plugins (our speed plugin guide covers exclusions), security plugins blocking admin-ajax.php, and add-on packs built for an older Elementor. The Plugins screen shows an “Elementor tested up to” note for add-ons that declare it.

Step 3: Fix “Server Error 500” and memory limits

A 500 from admin-ajax.php means PHP died. Open the PHP error log (control panel, or wp-content/debug.log if debug logging is on) at the minute of the failure:

[DD-Mon-YYYY HH:MM:SS UTC] PHP Fatal error:  Allowed memory size of 268435456 bytes exhausted (tried to allocate 20480 bytes) in /PATH/TO/SITE/wp-content/plugins/PLUGIN_SLUG/FILE.php on line LINE_NUMBER

This is an example log line, not a command. Match the timestamp to your failed save. 268435456 bytes is the limit; divide by 1048576 to get 256M. The file path is just where memory ran out, not necessarily the culprit. A different fatal error (undefined function, type error) points at the named plugin; our critical error guide covers those.

What Elementor asks for

Elementor’s System Requirements page (as published in 2025) lists a WordPress memory limit of 256 MB minimum for Elementor and Elementor Pro, 512 MB recommended and 768 MB for best performance, with more for sites running extra plugins such as WooCommerce. Its System Info screen warns below 128M. Check what you actually have:

wp eval 'echo ini_get("memory_limit"), " / ", WP_MEMORY_LIMIT, " / ", WP_MAX_MEMORY_LIMIT, PHP_EOL;'

This runs over SSH with no placeholders. It prints the PHP limit, the WordPress front-end limit and the admin limit. Good: 512M / 512M / 512M. Bad: 128M / 40M / 256M. WP-CLI can use a different PHP configuration from the web server, so confirm in Elementor, System Info.

The preview iframe is a front-end request, so WP_MEMORY_LIMIT matters, not only the admin limit. Add these to wp-config.php above “That’s all, stop editing!”:

define( 'WP_MEMORY_LIMIT', '512M' );
define( 'WP_MAX_MEMORY_LIMIT', '512M' );

This is a file edit. These constants only ask PHP for memory; if your host locks memory_limit lower, raise it in the control panel or open a ticket. Reload System Info to confirm.

If saves fail only on your longest pages, raise post_max_size and max_execution_time too (System Info shows both). A 403 instead of 500 usually means a firewall block, and 502 or 504 are gateway timeouts; both have their own guides.

Step 4: Clear Files and Data and regenerate CSS

If the editor works but the live page looks unstyled or out of date, Elementor’s generated CSS is stale or missing. Elementor writes one file per page to wp-content/uploads/elementor/css/, named like post-POST_ID.css, plus global files for Site Settings.

Go to Elementor, Tools, General and click Clear Files & Data under “Elementor Cache” (older versions called it “Regenerate CSS & Data”). It deletes generated CSS and cached data, and Elementor rebuilds each file on the next visit. Sync Library beside it refreshes the template library. From the server:

wp elementor flush-css --regenerate

This runs over SSH. --regenerate rebuilds the files immediately instead of on the next page view; add --network on multisite. Good output: “Success: Flushed the Elementor CSS Cache”. Then purge page cache, server cache and CDN. If files never come back:

ls -ld wp-content/uploads/elementor/css

This runs over SSH. Good output shows the folder owned by the user PHP runs as, writable by that owner, such as drwxr-xr-x SITE_USER SITE_USER. Root ownership (common after migrations) or dr-xr-xr-x means Elementor cannot write; ask your host to fix it.

Step 5: Check the CSS Print Method

Under Elementor, Settings, Performance, CSS Print Method has two options. External File, the default and Elementor’s recommendation, writes CSS to the uploads folder and links it. Internal Embedding prints CSS in the page’s <head>; Elementor’s own description says it works well for troubleshooting.

That makes it a quick test: if the page looks right with Internal Embedding, your design is fine and the file path is the problem (permissions, caching, or an optimization plugin).

wp option get elementor_css_print_method
wp option update elementor_css_print_method internal

These run over SSH. The first prints external or internal; “does not exist” means the default, External File. The second switches to Internal Embedding; use external to switch back. Run wp elementor flush-css and purge caches after each change. Fix the file problem and return to External File rather than leaving the test setting on.

Step 6: Features toggles that change layouts

New behavior ships behind toggles under Elementor, Settings, Features (older versions: “Experiments”). Some change the markup Elementor outputs:

• Optimized Markup (e_optimized_markup) removes wrapper elements, so custom CSS aimed at them stops matching.
• Inline Font Icons (e_font_icon_svg) renders icons as inline SVG instead of Font Awesome.
• Additional Custom Breakpoints (additional_custom_breakpoints) changes responsive breakpoints.
• Container (container) is the Flexbox layout element; turning it off breaks pages built with containers.

wp elementor experiments status FEATURE_NAME
wp elementor experiments deactivate FEATURE_NAME

These run over SSH. FEATURE_NAME is the internal name in brackets above. The status command prints active or inactive. Only deactivate a feature you know was switched on recently; stable features are sometimes locked on, and the command then reports an error. Flush CSS and purge caches before judging the result.

Step 7: Fix Elementor and Elementor Pro version mismatches

Elementor Pro builds on the free core plugin and expects a recent enough core. Pro updates arrive through your license connection, so a disconnected or expired license silently stops them while core keeps updating. Symptoms: missing Pro widgets, Theme Builder headers or footers vanishing, an admin notice asking you to update, or editor errors from the day only one plugin updated.

wp plugin list --fields=name,status,version,update_version | grep elementor

This runs over SSH. --fields picks columns and grep elementor keeps the Elementor rows. Good output shows elementor and elementor-pro both active with an empty update_version. Bad output shows a pending update on one, or Pro missing or inactive. If Pro’s notice names a required core version, update core to at least that.

If an update caused the break, use Elementor, Tools, Version Control: choose a Rollback Version and click Reinstall. Pro adds its own rollback row there. Roll both back to versions released together, never just one, and back up first, because newer versions may have run database upgrades. Afterward, Elementor may ask you to update its database:

wp elementor update db

This runs over SSH. Good output ends in success or “no update needed”. --force runs it even when Elementor thinks an update is in progress; use it only when you are sure none is.

Step 8: Replace URL after a migration

If Elementor images and links still point at an old domain or http:// after a move, a plain search and replace probably missed them. Elementor stores layouts as JSON in the _elementor_data post meta field, with slashes escaped as https:\/\/example.com.

wp elementor replace-urls https://OLD_DOMAIN https://NEW_DOMAIN

This runs over SSH after a database backup (or use Elementor, Tools, Replace URL). OLD_DOMAIN and NEW_DOMAIN are bare addresses with no trailing slash. Elementor escapes the slashes, updates only _elementor_data, and clears its CSS cache. Good output reports the rows affected; zero rows means the old URL never appeared in that exact form (check www, HTTP, or a path). Other tables still need wp search-replace, as our migration redirect guide explains.

Advanced: trace the failing request in the browser

Open developer tools before loading the editor, choose the Network tab, check Preserve log, and reload. Filter for admin-ajax, click a red request, and open Response:

1. 500 with an empty body: a PHP fatal error. Match its time in the error log.
2. 403 with an HTML page naming a firewall, ModSecurity or a security plugin: a block. Copy any rule ID or reference number.
3. 200 whose body starts with PHP warning text before the JSON: errors are printed to screen and corrupt the reply. Set define( 'WP_DEBUG_DISPLAY', false ); and log to file.
4. (failed) or (canceled) with no status: the “Connection Lost.” case, a proxy timeout, a firewall reset, or the network.

Then filter for Doc and find the preview iframe request. A 301 or 302 there proves the redirect theory, and the Location header shows the destination. In the Console tab, a red “Uncaught TypeError” names the crashing script; a path such as /wp-content/plugins/PLUGIN_SLUG/ tells you which plugin to test first.

Save a System Info report now (Elementor, System Info, Download System Info) or run:

wp elementor system-info > elementor-system-info.txt

This runs over SSH and writes a plain text report (PHP version, limits, plugins, theme, Elementor settings) to the current folder. Download it, then delete it from the server. If WP-CLI says the command is not registered, Elementor is not loading at all, which points back to a fatal error in the log.

When to contact your host

Open a ticket when the log shows limits you cannot raise, the Network tab shows server firewall block pages, or requests drop with no status. Send:

• The exact failure times in UTC and the editor URL (post.php?post=POST_ID&action=elementor).
• The failing request URL, status code, and response body or block reference number.
• The full PHP error log lines for those minutes and your current memory values from System Info.
• What changed just before: a plugin or PHP update, a migration, a new security rule.

If the host finds the server healthy and Safe Mode still fails, send the same details and your System Info file to Elementor support. To check headers and redirects from outside your browser, use our diagnostic tools; if the whole site is down, start at the Emergency Room.