Elementor

Elementor Server Error 500 (How to Fix It)

Reviewed Difficulty: Intermediate Risk: Low

This guide has been written and checked for accuracy but not yet re-verified in a single named environment. The steps are standard and safe; where a step carries risk it is flagged inline.

Quick answer: A 500 server error in Elementor is almost always the server hitting a limit, not a bug in your page. The editor is memory-hungry and saves a lot of data at once. Raising three server limits — PHP memory, max_input_vars, and max execution time — clears the large majority of these. If it started right after adding one widget or plugin, that addon is the cause instead.

Why Elementor throws a 500 when nothing else does

A 500 error means the server tried to handle the request and gave up partway. Elementor triggers it more than most plugins for one reason: it is heavy. Loading the editor, and especially saving a page, sends a large bundle of data to the server in a single request. If the server’s limits are set for a light brochure site, that bundle overflows them and the server returns a 500 instead of finishing.

This is why the same page can load on the front end but 500 in the editor, or save fine when small and 500 once it grows. You are not looking at corruption — you are looking at a ceiling that is set too low. The fix is to raise the ceiling.

Before changing anything, note when it started. If the 500 appeared the moment you added a specific third-party widget, activated a plugin, or updated one, skip to the addon section first — that is a different cause with a different fix.

Back up before you edit server files

You are about to edit files that can take the whole site down if mistyped. Back up wp-config.php, .htaccess, and php.ini before touching them — copy each to your computer. A single wrong character in these files causes its own 500 error, so keep the originals to restore.

Step 1: See the real error first

Elementor has a built-in report that often names the exact limit you are hitting. In the WordPress admin, go to Elementor → System Info. It lists your PHP memory limit, max_input_vars, post max size, and execution time. If any look low against the recommendations below, you have found your problem without guessing.

Also turn on the WordPress debug log — add these to wp-config.php above the “stop editing” line, reload the page that 500s, then read wp-content/debug.log:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

A memory error names memory. A max_input_vars overflow silently drops data rather than logging loudly, so if the log is empty but saves fail on big pages, suspect that one.

Step 2: Raise the three limits Elementor needs

Elementor’s own recommended minimums for a real site are higher than most hosts ship by default:

  • PHP memory limit: 256M or more (many hosts default to 128M or less)
  • max_input_vars: 10000 (default is often 1000, which large pages blow straight past)
  • max_execution_time: 300
  • post_max_size: 64M

Where you set these depends on your host. The cleanest place is php.ini in your site root (create it if it does not exist):

memory_limit = 256M
max_input_vars = 10000
max_execution_time = 300
post_max_size = 64M
upload_max_filesize = 64M

Many managed hosts ignore a php.ini file and instead expose these settings in the hosting panel — look for a “PHP Configuration” or “PHP Options” screen. On Hostinger, hPanel has this under the PHP configuration page; on cPanel it is “Select PHP Version → Options.” Setting them there is more reliable than a file the server may not read.

Also raise WordPress’s own memory limit in wp-config.php:

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

Reload the Elementor editor after applying these. For the large majority of 500 errors, this is where the site comes back.

Step 3: If it started with a specific addon

If raising the limits did not help, or the 500 clearly began when you added a third-party widget, test that directly. Deactivate the Elementor addon plugin you most recently added or updated, then reload the editor. If it comes back, that addon is the cause — check for its update, or report the 500 to its developer with your debug log.

If you are not sure which addon, deactivate all Elementor addon plugins (keep Elementor and Elementor Pro active), confirm the editor loads, then reactivate them one at a time until the 500 returns. The last one you switched on is the culprit.

Step 4: If saving specifically fails

A 500 only when you click Update, while the editor itself loads fine, points squarely at max_input_vars or a server security rule. Confirm max_input_vars is at 10000 as above. If it is and saves still fail, your host’s firewall (mod_security) may be rejecting the save as if it were an attack — a false positive on legitimate Elementor data. This one you cannot fix yourself: ask your host to check their mod_security log for your save request and whitelist the rule it is tripping.

Step 5: If it broke after a PHP version change

If your host moved you to a newer PHP version, an older Elementor addon can fatal on it and surface as a 500. Switch PHP back to the previous version in your hosting panel to confirm — if that fixes it, update Elementor, Elementor Pro, and every addon to their current versions, then move PHP forward again. Do not stay on an end-of-life PHP version as a permanent fix.

Rollback

Once the editor is stable, remove the three debug lines from wp-config.php and delete wp-content/debug.log. Leave the raised limits in place — they are correct values for a real Elementor site, not a temporary patch. If any file edit caused a new error, restore the backup copy you made in the first step.

Stopping it coming back

  • Keep the raised limits. They are the environment Elementor actually needs.
  • Update Elementor, Pro, and addons together on staging, so a bad addon update never hits the live editor.
  • Keep pages reasonable in size — a single page with hundreds of widgets pushes every limit at once. Split very large pages into templates.

Frequently asked questions

Is a 500 error the same as the “critical error” message?

Not quite. A 500 is the server refusing to complete the request, often from a limit or server rule. The “there has been a critical error” message is WordPress catching a PHP fatal error and hiding the detail. They overlap, but a 500 points more often at server limits and a critical error points more often at broken PHP in a plugin or theme. The debug log tells them apart.

Will raising the memory limit slow my site down?

No. The memory limit is a ceiling, not an allocation — raising it lets heavy requests finish instead of failing, but a page only uses what it needs. It has no effect on front-end speed for visitors.

My host will not let me change these settings. What now?

On genuinely locked-down shared hosting, the settings live only in the hosting panel or with support. Open a ticket asking them to set memory_limit to 256M and max_input_vars to 10000 for your site, and mention it is for Elementor — it is a common request and they will know it.