A blank screen. No message. The admin area stops responding. The client calls in a panic because their site "doesn't work anymore." This is the daily reality of the WordPress 500 error, and it's probably what brought you here.
The good news: it's almost never serious. The bad news: WordPress tells you nothing useful. You have to go and find the information yourself. This article shows you exactly where to look, based on a real case we handled on OVH shared hosting with Elementor.
What you'll learn
- Diagnose the error in 3 steps without touching the code
- Identify the 5 real causes (ranked by frequency)
- Understand why Elementor, Divi and page builders are so often involved
What the 500 error tells you (and what it hides)
The 500 error means "Internal Server Error." In plain terms: PHP crashed and the server didn't know what to return. It's a generic message that gives no clue about the real cause.
WordPress is especially prone to it because it stacks layers: the WordPress core, the theme, the plugins, the page builder. Each layer consumes memory and server time. When the limit is reached, everything stops.
What you see
- A blank page or a "500 Internal Server Error" message
- The site works for reading but crashes when writing
- Saving in Elementor fails without explanation
What's actually happening
- PHP exceeds its memory limit (128M by default)
- The .htaccess contains an incompatible directive
- A plugin crashes silently in the background
Blank screen = 500 error
The famous "White Screen of Death" (WSOD) in WordPress is the same thing as a 500 error. PHP crashes before it can generate the page, so the browser displays a blank page. The diagnosis and the causes are identical.
Diagnosis in 3 steps: finding the real cause
No need to guess. WordPress has a built-in logging system, but it is disabled by default. That's the first thing to turn on.
1 Enable error logging
Open the wp-config.php file at the root of your site (via FTP or your host's file manager) and add these 3 lines before the "That's all" comment:
WP_DEBUG_DISPLAY set to false: errors are written to a file, not shown to visitors. Your site stays clean.
2 Read the debug.log file
Reproduce the error (reload the page, save in Elementor, etc.). Then download the wp-content/debug.log file via FTP. Look for the lines that contain Fatal error.
134,217,728 bytes = 128 MB. This line tells you that PHP hit its memory limit. It's the number one cause.
3 Check the .htaccess
If the debug.log shows nothing, the problem often comes from the .htaccess file at the root. Compare it with the default WordPress version:
Any line outside this block was added by a plugin (cache, SEO, security) or manually. That's where you should look.
The 5 real causes, ranked by frequency
After dozens of interventions on production WordPress sites, here are the causes we find, in order. The first one alone accounts for more than half the cases.
#1 Insufficient PHP memory
This is the most common and the most insidious cause. By default, PHP allocates 128 MB of memory to each request. That may seem like enough, but do the math:
- WordPress core: ~40 MB
- Premium theme (Avada, OceanWP, Divi): 20-50 MB
- 20 active plugins: 30-80 MB depending on the plugins
- Elementor in edit mode: an extra 60-120 MB
Total: 150 to 290 MB for a single request. With a limit of 128 MB, PHP crashes. The server returns a 500 error. Nothing in WordPress warns you.
Telltale symptom: the site works for reading (front-end pages) but crashes when you save in Elementor, edit an image or access certain back-office pages. That's the classic sign of a memory overflow.
#2 Corrupted .htaccess file
The .htaccess is an Apache configuration file that WordPress, cache plugins and SEO plugins modify constantly. One bad directive and you get an instant 500 error.
The classic trap: using php_value directives on hosting that runs PHP-FPM. These directives only work with mod_php, and most modern hosts (OVH, o2switch, Ionos) use PHP-FPM.
#3 Plugin conflict
The more active plugins there are, the higher the risk of conflict. On the last site we audited, there were 3 cookie-consent plugins active at the same time. Each one loaded its own JavaScript and PHP code. The result: conflict, crash, 500 error.
The most frequent cases:
- Several plugins doing the same job (SEO, cache, cookies, security)
- An image-optimization plugin (EWWW, ShortPixel) that consumes all the memory while processing batches
- Deactivated plugins that leave bloat in the database
Rule of thumb: beyond 20 active plugins, run an audit. Not to delete blindly, but to eliminate functional duplicates and plugins that haven't been updated in over a year.
#4 Incompatible theme
A poorly coded theme, or one that's incompatible with the PHP version, can cause 500 errors. Premium themes with lots of options (OceanWP, Avada, Divi) load more code and dependencies.
Quick test: temporarily switch to the default theme (Twenty Twenty-Four) via FTP by renaming the active theme's folder in wp-content/themes/. If the error disappears, the theme is to blame.
#5 Outdated PHP version
WordPress 6.x requires PHP 7.4 minimum and recommends PHP 8.1 or higher. We still see sites running on PHP 7.2, or even PHP 7.0. Deprecated functions trigger fatal errors that the server translates into a 500 error.
Check your PHP version from your host's panel (OVH Manager, cPanel). If you're below PHP 8.0, it's time to migrate.
Real case: Elementor 500 error on OVH shared hosting
A WordPress showcase site with Elementor Pro. OVH shared hosting. 30 active plugins. The 500 error appeared only when editing images in Elementor. The front-end worked perfectly.
What we found after enabling WP_DEBUG_LOG:
536,870,912 bytes = 512 MB. The site already had a high memory limit, and it still wasn't enough. Why?
- 58% of the Elementor data was bloat left behind by deactivated plugins (Happy Addons, Elementor Addon Elements)
- 3 cookie plugins active for the same job
- 7 OceanWP extensions enabled but unused on the site
- Orphaned PHP scripts at the root of the server
Result after the intervention
6,890 bloat parameters removed across 45 Elementor pages. Dropped from 30 to 24 active plugins. No more 500 errors. Elementor saves now work instantly.
This case illustrates the problem well: increasing the memory isn't enough if the root cause is a pile-up of unnecessary plugins and dead data that saturates PHP on every request. You have to audit, clean up, then adjust.
The habits to adopt right now
Even if your site isn't crashing yet, these points help you avoid most 500 errors before they happen:
- WP_DEBUG_LOG enabled permanently
- memory_limit at 256M minimum
- max_input_vars at 5000 (Elementor/Divi)
- Fewer than 20 active plugins
- No functional duplicates between plugins
- Regular updates (WP, plugins, theme)
- PHP 8.1+ on the host
- Automatic backups configured
Frequently asked questions
Why does my site show a 500 error only inside Elementor?
Elementor is heavy on PHP memory. In edit mode, it loads the entire page, the widgets, the dynamic CSS and the real-time previews. If your memory_limit is too low or too many plugins are active at the same time, PHP exceeds its limit and crashes. This is the number one cause of Elementor-related 500 errors.
Can the 500 error come from my hosting?
Yes. Shared hosting imposes strict limits on PHP memory, execution time and the number of requests. If you have optimized WordPress and the 500 errors persist, your hosting is probably the limiting factor. A VPS or managed WordPress hosting offers more headroom.
How many plugins can I have before risking a 500 error?
There is no magic number. The real problem isn't quantity but quality: 3 plugins doing the same job cause more trouble than 25 well-chosen plugins. Beyond 20 active plugins, an audit is in order to identify duplicates and unnecessary plugins.
My site works for reading but crashes when writing. Why?
Write operations (saving in Elementor, uploading media, editing content) consume far more memory than displaying a page. WordPress has to process the data, regenerate caches and update the database. That's where the memory limit is reached.
Is the WordPress white screen the same thing as the 500 error?
Yes. The White Screen of Death (WSOD) is the WordPress manifestation of the 500 error. PHP crashes before generating the HTML page, so the browser receives an empty response. The diagnosis and the causes are identical in both cases.
See also
Is your WordPress showing a 500 error?
Every site is different: the theme + plugins + hosting combination creates unique situations. A generic diagnosis isn't enough.
Get in touch so I can audit your WordPress and identify the exact cause.
Request a WordPress audit