Fix WordPress 500 Internal Server Error: Step-by-Step Guide

The Error

You open your WordPress site — or the admin panel — and see a blank page or a browser message like:

500 Internal Server Error

Sometimes the browser shows a generic page. Sometimes Apache or Nginx displays its own styled error screen. Either way, the server crashed before it could send a real response. It's a catch-all: the server knows something went wrong, but won't say what.

Almost every WordPress 500 error traces back to one of five causes — all fixable, no reinstall needed.

Root Causes

Corrupted or invalid .htaccess file
A broken or incompatible plugin
Wrong file/directory permissions
PHP fatal error (syntax mistake, incompatible extension)
Exhausted PHP memory limit (check error logs first)

Step 1: Check the PHP Error Log

Before touching anything else, get the actual error message. The 500 page tells you nothing — the log tells you everything.

Add these three lines to wp-config.php, above the /* That's all, stop editing! */ comment:

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

Reload the broken page, then check the log:

# WordPress debug log
cat /var/www/html/wp-content/debug.log

# Or server PHP error log (path varies by distro)
tail -50 /var/log/php/error.log
tail -50 /var/log/apache2/error.log

You'll typically see something like Fatal error: Uncaught Error: Call to undefined function... or Parse error: syntax error in /wp-content/plugins/some-plugin/file.php on line 42. That single line points directly at the culprit.

Step 2: Reset the .htaccess File

A corrupted .htaccess is the most common trigger for sudden 500 errors — particularly after a WordPress core update or any plugin that rewrites URL rules.

Connect via FTP or SSH, then rename the existing file:

cd /var/www/html
mv .htaccess .htaccess.bak

Create a fresh one with the default WordPress content:

cat > .htaccess <<'EOF'
# 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
EOF

Reload the site. If it comes back, the old .htaccess was the problem. Delete the backup and move on.

Later, you can regenerate a clean .htaccess directly from WordPress: go to Settings → Permalinks and click Save Changes without changing a thing.

Step 3: Disable All Plugins

Plugins are the second most likely culprit. The fastest diagnosis is to disable all of them at once — even if you can't get into the admin panel.

Via SSH or FTP, rename the plugins folder:

mv /var/www/html/wp-content/plugins /var/www/html/wp-content/plugins_disabled

Reload the site. Working again? A plugin is to blame. Restore the folder:

mv /var/www/html/wp-content/plugins_disabled /var/www/html/wp-content/plugins

Now go to Plugins → Installed Plugins in the admin panel. Deactivate them one at a time, reloading after each. When the error comes back, the plugin you just deactivated is the broken one.

Frequent offenders: caching plugins after a PHP upgrade, SEO plugins with complex rewrite rules, and anything that hooks into init or shutdown.

Step 4: Fix File and Directory Permissions

WordPress files need to be readable by the web server — but not writable by the entire world. Overly permissive settings like 777 on files will trigger 500 errors on any hardened server.

Correct permissions:

Directories: 755
Files: 644
wp-config.php: 600 (more secure)

Fix them in bulk:

# Fix directories
find /var/www/html -type d -exec chmod 755 {} \;

# Fix files
find /var/www/html -type f -exec chmod 644 {} \;

# Lock down wp-config.php
chmod 600 /var/www/html/wp-config.php

Also verify ownership. On Ubuntu/Debian the web server user is www-data; on CentOS/RHEL it's typically apache:

chown -R www-data:www-data /var/www/html

Step 5: Switch to the Default Theme

Themes are easy to overlook. A recently updated or hand-edited theme can crash the site just as hard as a broken plugin — especially if someone edited functions.php directly on the server.

Rename your active theme folder to force WordPress off it:

mv /var/www/html/wp-content/themes/your-theme /var/www/html/wp-content/themes/your-theme_bak

WordPress falls back automatically to the bundled default (Twenty Twenty-Four, or whichever is installed). Site works now? Check the theme's functions.php for PHP syntax errors — that's where these issues almost always hide.

Step 6: Check PHP Version Compatibility

Hosts upgrade PHP without much fanfare. If your server recently moved from PHP 7.4 to 8.1 or 8.2, plugins and themes built for older PHP can break hard — and silently.

Check your current version:

php -v

Scan the error log for Deprecated, Fatal error, or Call to undefined function. Any specific file path in that log is your target.

On shared hosting, look for a PHP Selector in cPanel or Plesk. Roll back to PHP 7.4 temporarily while you wait for the plugin author to push a fix — or switch to an actively maintained alternative.

Verification

After each fix attempt:

Open the site in a private/incognito window to bypass cached error pages
Test both the homepage (https://yoursite.com/) and the admin panel (https://yoursite.com/wp-admin/)
Check the PHP error log — no new entries means you're clean
Once fixed, turn off debug mode in wp-config.php by setting WP_DEBUG back to false

Prevention

Test on staging, not production. Run plugin, theme, and PHP updates on a staging copy first. Most 500 errors are avoidable with one hour of staging work.
Back up .htaccess before installing new plugins. Anything that claims to boost performance or cache pages may rewrite your URL rules without warning.
Leave debug logging on — quietly. Keep WP_DEBUG_LOG enabled but WP_DEBUG_DISPLAY off. You'll catch problems before visitors do.
Run a health check regularly. WordPress's built-in Site Health tool (Tools → Site Health) surfaces configuration problems before they become 500 errors.