HTTP Error 500 in WordPress: The Four Causes, in Order of Likelihood

A 500 error means the server failed while processing the request and could not say why. In WordPress it is almost always one of four things: a plugin fatal, a corrupted .htaccess, an exhausted PHP memory limit, or a PHP version mismatch. Enable error logging first — the log turns a guessing game into a five-minute fix.

The reason 500 errors feel intractable is that the page tells you nothing on purpose. The server is deliberately withholding the detail from visitors, and it is written down somewhere you have not looked yet. Finding that file is the whole job.

Get the real error first
Cause 1: a plugin or theme fatal
Cause 2: a corrupted .htaccess
Cause 3: PHP memory exhaustion
Cause 4: PHP version mismatch
When it is none of the four
How this fits the rest of the stack
FAQ

Get the real error first

Do not start disabling things. Start by making WordPress tell you what happened.

// wp-config.php, above /* That's all, stop editing! */
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

Reload the failing page, then read wp-content/debug.log. A fatal error names the file and line, which usually names the plugin.

If debug.log does not exist or stays empty, the failure happened before PHP got far enough to write it. Check the web server’s own error log:

# Apache
tail -50 /var/log/apache2/error.log

# Nginx with PHP-FPM
tail -50 /var/log/nginx/error.log
tail -50 /var/log/php8.2-fpm.log

A 500 with an empty PHP log usually means a server-level problem, most often .htaccess. That is the next section, and it is the one to check when the logs are silent.

Cause 1: a plugin or theme fatal

The most common cause by a wide margin, and usually traceable to something that changed — an update, a new plugin, or a PHP version bump that a plugin did not survive.

If you can still reach the admin, use the Health Check plugin’s Troubleshooting Mode, which deactivates plugins for your session only so visitors keep seeing a working site.

If the admin is also 500-ing, work from the filesystem:

# Deactivate everything by renaming the directory
mv wp-content/plugins wp-content/plugins.off
mkdir wp-content/plugins

# Site loads? It was a plugin. Restore and bisect.
mv wp-content/plugins.off/* wp-content/plugins/

# WP-CLI works even when the admin does not
wp plugin deactivate --all
wp plugin activate plugin-one plugin-two   # re-enable in halves

Bisect rather than going one at a time — halving finds the culprit among twenty plugins in about five steps.

For a theme fatal, switch to a default theme the same way: rename the active theme’s directory and WordPress falls back automatically.

Cause 2: a corrupted .htaccess

This is the one that produces a 500 with nothing in the PHP log, because Apache rejects the request before PHP is involved. Plugins that write rewrite rules — caching, security, redirect managers — are the usual authors.

# Rename rather than delete, so you can compare later
mv .htaccess .htaccess.broken

# Site loads? Regenerate a clean one.
# Admin: Settings -> Permalinks -> Save Changes
# Or:
wp rewrite flush --hard

The default WordPress block is small. Anything else in the file was added by a plugin or by hand:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

A common trigger is a directive for a module the server does not have. A plugin writes an <IfModule>-less rule for mod_deflate or mod_headers, the server lacks it, and every request 500s. Nginx installs ignore .htaccess entirely, so if you are on Nginx this cause is off the table.

Cause 3: PHP memory exhaustion

Recognisable in the log as Allowed memory size of N bytes exhausted. Typical triggers: an import, a page builder editing a long page, an image-heavy media library, or a backup plugin running inside a web request.

// wp-config.php
define( 'WP_MEMORY_LIMIT', '256M' );
define( 'WP_MAX_MEMORY_LIMIT', '512M' );  // admin-side operations

WordPress cannot raise the limit above what PHP itself allows, so if the constant has no effect, the ceiling is in php.ini or your host’s configuration.

php -i | grep memory_limit
wp eval 'echo ini_get("memory_limit");'

Raising the limit is a workaround, not a diagnosis. A blog does not need 512MB to render a post. If a normal page load exhausts memory, something is loading the entire media library or running an unbounded query, and the honest fix is finding it — Query Monitor will show you which.

The exception is genuinely heavy admin work: imports, migrations, and bulk regeneration legitimately need more. Run those through WP-CLI where possible, since the CLI is not constrained by the web request’s limits.

Cause 4: PHP version mismatch

A host upgrades PHP, or you move to a new server, and a plugin written for PHP 7 hits a removed function. Increasingly common as hosts push to PHP 8.2 and beyond.

php -v
wp core version
wp plugin list --fields=name,version,update

# Look for the giveaway in the log
grep -iE 'deprecated|fatal|undefined function' wp-content/debug.log | tail -20

Typical signatures: Call to undefined function create_function() (removed in PHP 8), Uncaught TypeError from stricter type handling, or a parse error on syntax the older interpreter accepted.

The correct fix is updating the plugin. The temporary fix is stepping the PHP version back while you do. Do not leave it stepped back — running an unsupported PHP version means unpatched vulnerabilities in the layer handling every request.

This is where treating the PHP version as configuration rather than as a property of the server pays off. On RunxBuild’s managed WordPress the runtime is part of the deployment rather than something you migrate between, and the dashboard’s file manager and database browser mean the diagnostic steps above do not require hunting for SFTP credentials first — see the WordPress files documentation.

When it is none of the four

A smaller set of causes worth checking once the common ones are excluded.

File permissions — directories should be 755, files 644. A wp-config.php at 600 that the web server user cannot read produces a 500.
Corrupted core files — a failed update. wp core download --force replaces core without touching your content.
Database connection failure — usually shows as Error establishing a database connection, but a plugin catching that badly can turn it into a 500.
Disk full — no space for sessions or temp files. df -h takes two seconds and is embarrassing to discover late.
opcache serving stale bytecode after a deploy. Restarting PHP-FPM clears it.

Check the disk first among these. It is the fastest to rule out and the most annoying to discover after an hour of plugin bisection.

How this fits the rest of the stack

Turn on the log, read it, and the four common causes identify themselves. A silent PHP log points at .htaccess; a memory message points at an unbounded query rather than a limit that needs raising; a fatal names its own plugin. Keep a staging copy so bisecting does not mean experimenting on production. If you are looking at WordPress hosting where logs, files, and the database are reachable from one dashboard, the RunxBuild hosting calculator shows the plan and database as separate line items.

Useful related references:

FAQ

What causes HTTP error 500 in WordPress?

Most often a plugin or theme fatal error, a corrupted .htaccess file, an exhausted PHP memory limit, or a PHP version a plugin does not support. Enabling WP_DEBUG_LOG identifies which within a few minutes.

Why is my debug.log empty during a 500 error?

The failure happened before PHP ran far enough to write it, which usually points at .htaccess or the web server configuration. Check the Apache or Nginx error log instead.

How do I fix a 500 error when I cannot access wp-admin?

Work from the filesystem. Rename wp-content/plugins to disable everything, or run wp plugin deactivate —all with WP-CLI, which works even when the admin is unreachable.

Does raising WP_MEMORY_LIMIT fix a 500 error?

It can, but treat it as a symptom. A normal page load should not exhaust memory — if it does, something is running an unbounded query or loading the whole media library, and raising the ceiling only delays the failure.

Can .htaccess cause a 500 error on Nginx?

No. Nginx ignores .htaccess entirely, so on an Nginx server that cause is off the table and you should look at the plugin, memory, and PHP version causes instead.