How to Fix WordPress 500 Internal Server Error

A 500 Internal Server Error in WordPress is the catch-all HTTP status code that PHP and the web server throw when something goes wrong and they cannot — or will not — tell you exactly what. Unlike a 404 (page not found) or the WordPress database connection error, a 500 gives you no direct clue. The page simply reads "Internal Server Error" or, in many cases, shows nothing but a blank screen.

This generality is what makes the error so frustrating. The root cause could be a corrupted .htaccess file, an exhausted PHP memory limit, a misbehaving plugin, a theme with a PHP fatal error, corrupted core files, wrong file permissions, or a PHP version incompatibility. The good news is that WordPress 500 errors follow a predictable set of causes, and each one has a known fix.

This guide walks through the seven most common causes of the WordPress 500 Internal Server Error in the order you should check them. Enable debugging first so PHP tells you the real error, then work down the list — most site owners find the fix within the first three steps.

What Is a 500 Internal Server Error in WordPress?

A 500 Internal Server Error is a generic server-side error. The "500" status code means the server encountered an unexpected condition that prevented it from fulfilling the request, and it does not have a more specific status code to describe what happened.

In a WordPress context, a request travels from the browser to the web server (Apache or Nginx), which hands it to PHP. PHP then executes the WordPress application code — loading wp-config.php, the active theme, every active plugin, and the database connection. If anything in that chain throws a fatal error and PHP cannot recover, the server returns a 500 status code to the browser.

Because WordPress suppresses PHP errors by default in production (WP_DEBUG is false), you usually do not see the actual error message — only the generic 500 response. This is why the first step in every WordPress 500 fix is to enable WP_DEBUG so PHP reveals the underlying fatal error, whether it is an exhausted memory limit, an undefined function call, a syntax error, or a missing file.

Common Causes

The table below maps the seven root causes of the WordPress 500 error to how you identify each one and the fix that resolves it. Use it as a quick triage before diving into the step-by-step guide.

Cause	How to Identify	Fix
Corrupted .htaccess	500 appears site-wide after a permalink save or migration	Rename .htaccess and regenerate a fresh default file
Exhausted PHP memory limit	Debug log shows "Allowed memory size of ... exhausted"	Increase memory_limit to 256M or higher
Plugin conflict	500 appears right after installing or updating a plugin	Deactivate all plugins, then re-enable one by one
Theme error	500 only with the active theme; clears on a default theme	Switch to Twenty Twenty-Four and fix the theme
Corrupted core files	500 persists after ruling out plugins, theme, and DB	Reinstall WordPress core files
Wrong file permissions	Server logs show "Permission denied" on PHP files	Set directories to 755 and files to 644
PHP version incompatibility	Debug shows "Call to undefined function" or version warnings	Upgrade to a PHP version supported by your plugins

Step-by-Step Fix Guide

Work through these seven steps in order. Stop as soon as the 500 error is resolved — you rarely need all seven.

Step 1: Enable WP_DEBUG in wp-config.php

Before guessing, let PHP tell you what is wrong. Open wp-config.php in your WordPress root directory and add these lines above the /* That's all, stop editing! */ comment. Reload the site and read the PHP fatal error it now prints — it will name the exact file and line. If the 500 persists even with debug enabled, the error is happening before WordPress loads, so move on to Step 2.

Step 2: Check and rename .htaccess

A corrupted .htaccess is the single most common cause of a WordPress 500 error, especially after a migration or a permalink change. Temporarily disable it by renaming the file, then reload the site. If the 500 disappears, regenerate a clean .htaccess:

# Backup and disable the current .htaccess
mv /var/www/html/.htaccess /var/www/html/.htaccess.bak

# Reload the site. If it works, create a fresh default .htaccess

# Default WordPress .htaccess
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]

You can also regenerate .htaccess from the admin area at Settings > Permalinks — just click "Save Changes" without editing anything.

Step 3: Increase PHP memory limit

If the debug log shows Allowed memory size of ... bytes exhausted, PHP ran out of memory. This is common on sites with many plugins, large image processing jobs, or heavy page builders. Raise the limit to at least 256M. The dedicated PHP Memory Limit Fix section below shows all three methods (wp-config.php, php.ini, and .htaccess).

Step 4: Deactivate all plugins

Plugin conflicts are the second most common cause. The fastest way to test every plugin at once is to rename the plugins directory so WordPress cannot find any of them:

cd /var/www/html/wp-content
mv plugins plugins.disabled

Reload the site. If the 500 is gone, a plugin is the culprit. Rename the folder back and re-enable plugins one at a time — the last one you re-enable before the 500 returns is the offender. Update it, replace it, or contact the developer.

Step 5: Switch to a default theme (Twenty Twenty-Four)

If disabling plugins did not help, the active theme may have a PHP fatal error — a syntax mistake, an undefined function, or a call to a deprecated API. Rename the active theme folder so WordPress falls back to a bundled default theme such as Twenty Twenty-Four:

cd /var/www/html/wp-content/themes
mv your-theme your-theme.disabled

If the site loads with the default theme, inspect the original theme's functions.php for syntax errors or calls to functions that no longer exist. You can also force a default theme from wp-config.php:

define('WP_DEFAULT_THEME', 'twentytwentyfour');

Step 6: Reinstall WordPress core files

If the 500 persists after you have ruled out .htaccess, memory, plugins, and the theme, a core WordPress file may be corrupted or partially overwritten. If the admin dashboard is reachable, go to Dashboard > Updates and click Reinstall — this overwrites core files without touching your themes, plugins, or database. If the admin is unreachable, download a fresh WordPress package from wordpress.org, delete the wp-content folder and wp-config.php from the downloaded archive, and upload the remaining core files over your existing installation.

Step 7: Check file permissions

Incorrect ownership or permissions can stop PHP from reading or executing WordPress files, producing a 500. The web server user (usually www-data or nginx) must own the files, with directories at 755 and files at 644. Never use 777 — it is both a security risk and rarely the correct fix. See the commands in the dedicated sections below.

wp-config.php Debug Configuration

Enabling debug mode is the single most important diagnostic step. These constants belong in wp-config.php, placed above the /* That's all, stop editing! */ line. On a live production site, keep WP_DEBUG_DISPLAY set to false so errors are logged to wp-content/debug.log instead of being shown to visitors.

// Add to wp-config.php, ABOVE the "stop editing" line
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);      // writes errors to wp-content/debug.log
define('WP_DEBUG_DISPLAY', false); // keep false on production; set true to print on screen
define('SCRIPT_DEBUG', true);      // use unminified JS/CSS while debugging

After saving, reload the failing page and then inspect wp-content/debug.log. The fatal error entry will name the file and line number, turning a vague 500 into an actionable fix in seconds.

PHP Memory Limit Fix

When WordPress exhausts the PHP memory limit, PHP terminates the script with a fatal error and the server returns a 500. Increase the limit using any one of the three methods below — pick whichever your hosting environment allows. The wp-config.php method works on almost all hosts; php.ini gives the server-wide value; .htaccess applies only to Apache.

Method A: Increase via wp-config.php

// Add to wp-config.php, ABOVE the "stop editing" line
define('WP_MEMORY_LIMIT', '256M');
define('WP_MAX_MEMORY_LIMIT', '512M'); // higher limit for the admin dashboard

Method B: Increase via php.ini

# Find your php.ini location
php -i | grep "Loaded Configuration File"
# Typical paths:
# /etc/php/8.2/fpm/php.ini   (PHP-FPM)
# /etc/php/8.2/cli/php.ini   (CLI)

; In php.ini
memory_limit = 256M

# After editing the FPM ini, restart PHP-FPM
sudo systemctl restart php8.2-fpm

Method C: Increase via .htaccess

# Add to .htaccess (Apache only; Nginx ignores this)
php_value memory_limit 256M

Verify the new limit is in effect:

php -r "echo ini_get('memory_limit');"
# Should output: 256M

If increasing to 256M does not resolve the error, a plugin or theme is likely leaking memory. Use Step 4 to isolate it rather than endlessly raising the limit.

Quick Reference Table

WordPress 500 errors are easily confused with other server errors. This table distinguishes the five you are most likely to encounter so you apply the right fix.

Error	What It Means	First Thing to Check
500 Internal Server Error	Generic PHP/server error; the request failed unexpectedly	Enable WP_DEBUG and read the fatal error
502 Bad Gateway	The web server got an invalid response from the PHP upstream	Is PHP-FPM running and reachable on its socket/port?
503 Service Unavailable	The server is temporarily overloaded or in maintenance mode	Server load, .maintenance file, or PHP-FPM capacity
White Screen of Death (WSOD)	PHP fatal error with output suppressed; a blank page, no status hint	Enable WP_DEBUG; check memory limit and plugins
Parse Error	A PHP syntax error in a theme or plugin file	Read the file/line in the error; fix the syntax

Pro tip: The 500 and the WSOD are close cousins. A 500 returns an explicit status code; a WSOD returns a 200 with an empty body because PHP died before flushing any output. Both are PHP fatal errors — the diagnostic steps are identical.

FAQ

Conclusion

The WordPress 500 Internal Server Error is generic by design — it tells you that PHP failed, but not why. The fix is almost always to make PHP talk: enable WP_DEBUG and read the fatal error in wp-content/debug.log. From there, the seven causes in this guide cover virtually every real-world 500: a corrupted .htaccess, an exhausted memory limit, a plugin or theme conflict, corrupted core files, or wrong file permissions.

Work through the steps in order, stop as soon as the site recovers, and remember to turn WP_DEBUG_DISPLAY back to false on production so errors keep logging silently without exposing internals to visitors. With debug mode armed and this checklist in hand, a WordPress 500 error goes from a mystery to a five-minute fix.

Related Guides

• How to Fix 500 Internal Server Error: Complete Guide
• WordPress White Screen of Death: A Systematic Fix
• WordPress Database Connection Error: Complete Fix
• How to Fix 503 Service Unavailable Error