2026年11月12日

2026年11月12日

Fixing Elementor Errors: Can’t Save, Editor Won’t Load, Broken Layout

This article is a localized edition of the Japanese original. Read the Japanese original

Elementor errors are easier to narrow down once you sort them into "can't save", "the editor won't open" and "the live page layout is broken". This article explains how to investigate and fix each symptom. Screen labels and commands match the free Elementor plugin as of October 2026.

Back up the site before you start. Where possible, try anything that stops plugins on a staging environment before doing it on the live site.

Symptoms and main causes

Symptom Main cause Section
Saving fails with "Server Error" or a similar message Not enough PHP memory, the server's WAF blocking the request, errors in other plugins Steps 1–4
The editor keeps loading or shows a white screen Not enough PHP memory, conflicts with the theme or other plugins Steps 2 and 4
The design is correct in the editor but broken on the live page Outdated CSS files, old files left in a page cache or CDN Step 5
Saving in an editor left open for a long time shows "Token Expired." The save token (nonce) has expired Step 6

Step 1: Check the request and the error log when saving fails

The Elementor editor sends saves and other operations as requests to wp-admin/admin-ajax.php (with the action elementor_ajax). When saving fails, start by checking the response to this request.

  1. With the editor open, open your browser's developer tools (F12 in Chrome) and go to the "Network" tab.
  2. Save again and select the admin-ajax.php row.
  3. Look at the status code and the response body.
Status Meaning and where to look next
500 A fatal PHP error. Check the debug log below (for memory exhaustion, see Step 2)
403 The server's WAF or a security plugin is blocking the request (Step 3)
200 with an error message in the body An error returned by Elementor. If it says "Token Expired.", see Step 6

PHP errors can be recorded in the WordPress debug log. If you can use WP-CLI, configure it as follows. Errors are not shown on screen and are written only to wp-content/debug.log.

wp config set WP_DEBUG true --raw --type=constant
wp config set WP_DEBUG_LOG true --raw --type=constant
wp config set WP_DEBUG_DISPLAY false --raw --type=constant

# After trying to save, look at the end of the log
tail -n 50 wp-content/debug.log

If you can't use WP-CLI, add the same three constants with define() in wp-config.php, before the comment saying editing ends here. Once you have found the cause, revert all three or set them to false (debug.log can end up readable from outside, so don't leave it in place).

The following command shows, in one place, the environment Elementor sees (PHP version, memory limit, active plugins and so on).

wp elementor system-info

Step 2: Match the PHP memory limit to Elementor’s requirements

Elementor's official system requirements (as of October 2026) call for a WordPress memory limit of at least 256MB, with 512MB recommended. Sites that also run other plugins such as WooCommerce may need 512MB. If the debug log says "Allowed memory size of … bytes exhausted", you are out of memory.

Add the following to wp-config.php, before the comment saying editing ends here.

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

This constant takes effect if the server allows PHP's memory_limit to be changed. If the value under "Server" on the Info tab of Tools > Site Health does not change after you add it, raise memory_limit in the server settings (php.ini, .user.ini, or your host's control panel). The following article explains how the limits work and where to set them.

Step 3: For 403 responses, check the WAF and security plugins

Every time you save, Elementor sends data describing the page structure, so a server WAF (ModSecurity and the like) can mistake it for an attack and return 403.

  • If your hosting control panel has WAF settings, check the WAF log for a blocked request to admin-ajax.php at the time you saved. If it was blocked, try excluding the matching rule or disabling the WAF temporarily to see whether saving works.
  • If you run ModSecurity on a VPS or similar, check the ModSecurity log (lines such as "Access denied with code 403") to see which rule was triggered. If you don't know where the log is or how to add an exclusion, give your hosting company the date, time and URL of the save and ask them to look into it.
  • The firewall feature of a security plugin can cause the same thing. Check the plugin's log, and use its learning mode if it has one, or disable it temporarily to see whether saving works.

Leaving the WAF disabled makes the site more vulnerable to attacks. Once you know which rule is responsible, exclude only that rule and turn the WAF back on.

Step 4: Use Safe Mode to isolate conflicts with the theme and plugins

If the editor won't open, or saving returns 500 even though there is enough memory, suspect a conflict with the theme or another plugin.

Elementor has a "Safe Mode". When it is on, the editor runs without loading the theme or other plugins, so you can check whether a conflict is the cause without changing what visitors see.

  1. In the admin, open Elementor > Tools, choose Enable for "Safe Mode" on the "General" tab, and save.
  2. Reopen the editor and check whether the problem still occurs.
  3. If the problem doesn't occur in Safe Mode, the cause is the theme or another plugin. Turn Safe Mode off again, then deactivate plugins one at a time on a staging environment or similar to find the culprit.

Safe Mode is available to users who have permission to install plugins. When you are done, turn it off on the same screen.

To isolate causes outside Elementor as well, you can also use the troubleshooting mode of the Health Check & Troubleshooting plugin. It switches plugins and the theme for your own login session only.

If you stop plugins temporarily with WP-CLI, save the list of active plugins first so you can restore them.

# Save the list of currently active plugins
wp plugin list --status=active --field=name > active-plugins.txt

# Deactivate everything except Elementor and Elementor Pro
wp plugin deactivate $(grep -v -x -e elementor -e elementor-pro active-plugins.txt)

# Activate one at a time and check each time whether the problem returns
wp plugin activate contact-form-7

# When you are done, restore the original state
wp plugin activate $(cat active-plugins.txt)

This method also affects what visitors see, so on a live site do it at a quiet time or use a staging environment.

Step 5: If the live page layout is broken, rebuild the CSS

Elementor writes each page's design out as CSS files (in wp-content/uploads/elementor/css/) and loads them on the live page. If these files are outdated or failed to write, the page looks right in the editor but broken on the live site.

Clear Elementor’s files and data

In the admin, go to Elementor > Tools > General tab and click "Clear Files & Data". This deletes the CSS files and the generated data stored in the database, and they are rebuilt the next time the page is viewed. The content of your posts and pages is not deleted.

With WP-CLI, the following command does the same. Adding --regenerate rebuilds the files immediately instead of waiting for the next page view.

wp elementor flush-css --regenerate

Clear the page cache and CDN too

Even after Elementor's CSS is rebuilt, the page still looks broken if old HTML or CSS remains in a caching plugin, the server cache, or a CDN such as Cloudflare. After clearing Elementor's files, clear each of those caches and check with a hard reload in the browser (Ctrl+F5 on Windows, Command+Shift+R on Mac). If you use an optimization plugin that combines or minifies CSS and JavaScript, also turn that feature off temporarily to see whether the layout recovers.

Change the CSS output method temporarily

"CSS Print Method" on the "Performance" tab of Elementor > Settings lets you choose between "External File" (the default) and "Internal Embedding". With Internal Embedding, the CSS is written directly into the page's <head>, which helps you tell whether writing or loading the CSS files is the problem. If Internal Embedding fixes it, check write permissions on wp-content/uploads/elementor/ and your cache and CDN settings. Once you know the cause, switch back to External File, which is recommended for performance.

Step 6: Elementor and Elementor Pro versions, and expired tokens

Keep the versions in step

If you use Elementor Pro and only one of the free Elementor plugin and Pro is out of date, the editor may not work correctly. Update both to the latest version. If problems appear after an update, you can also roll back to an earlier version from the "Version Control" tab under Elementor > Tools.

When you see “Token Expired.”

Save requests carry a WordPress nonce (a one-time token). If the editor stays open so long that it expires, saving fails with "Token Expired.". Make a note of what you were editing, then reload the page and reopen the editor.

You may see advice to extend nonce lifetime with the nonce_life filter, but that filter applies to every nonce on the site and weakens protection against CSRF (forged requests). Changing it just for this symptom is not recommended.

Summary

  • When saving fails, check the status of admin-ajax.php in the developer tools to tell 500 (PHP errors), 403 (WAF and the like) and Token Expired apart.
  • Record PHP errors with WP_DEBUG_LOG, and if memory runs out, raise the limit to meet Elementor's requirements (256MB minimum, 512MB recommended).
  • For 403, find the rule responsible in the WAF or security plugin log and exclude only that rule.
  • Isolate conflicts with Elementor's Safe Mode or Health Check & Troubleshooting without affecting visitors.
  • For broken layouts, rebuild the CSS with "Clear Files & Data" or wp elementor flush-css --regenerate, then clear the page cache and CDN and check again.

Questions about WordPress? The publisher of this site is based in Japan and replies in Japanese. Contact (Japanese)

お気軽にご相談ください

お見積りへ お問い合わせへ
▲