How to Fix “500 Internal Server Error” on WordPress Sites

The HTTP 500 Internal Server Error is one of the most frustrating errors in web hosting. It is an umbrella HTTP status code indicating that the web server (Apache, Nginx, or LiteSpeed) encountered an unexpected condition that prevented it from fulfilling the request, without specifying the exact cause on the screen.

In WordPress, over 90% of 500 errors stem from three specific problems: a corrupted .htaccess directive, an exhausted PHP memory limit, or a fatal PHP error triggered by a recently updated plugin or theme.

Quick Answer

Check your server error log immediately to read the actual error description:

tail -n 30 /var/log/apache2/error.log || tail -n 30 /var/www/html/error_log

Test if the error is caused by a corrupted .htaccess file by temporarily renaming it:
```
mv /var/www/html/.htaccess /var/www/html/.htaccess.bak
```
If the site starts working, regenerate a clean .htaccess file.
If the log shows Allowed memory size of ... bytes exhausted, increase your PHP memory limit in wp-config.php:
```
define( 'WP_MEMORY_LIMIT', '256M' );
```
If a plugin caused a PHP fatal error, rename the plugin folder or deactivate it via WP-CLI: wp plugin deactivate --all.

Symptoms

The browser shows a blank white page or a generic message: “500 Internal Server Error” or “The site is experiencing technical difficulties.”
The frontend may load while /wp-admin/ returns a 500 error, or vice versa.
The error appears immediately following a WordPress core, plugin, or theme update.
In Nginx reverse-proxy setups, the browser displays 502 Bad Gateway while upstream Apache or PHP-FPM logs report internal 500 status codes.

Common Causes

Corrupted .htaccess Directives: Malformed rewrite rules inserted by caching, redirect, or security plugins.
Exhausted PHP Memory Limit: Heavy plugins (WooCommerce, Elementor, WPML) consuming more RAM than allocated in php.ini or wp-config.php.
PHP Fatal Errors (Syntax / Incompatibility): A plugin using modern PHP 8.2+ functions on an outdated PHP 7.4 runtime, or calling deprecated functions that trigger fatal exceptions.
File Permission Misconfigurations: Folders set to 777 (triggering Apache suexec security rejections) or files owned by root instead of the web user.
Corrupted WordPress Core Files: Incomplete automated background core updates leaving partial PHP files in /wp-includes/ or /wp-admin/.

Before You Start

Always back up your current .htaccess and wp-config.php files before modifying them.
Have SSH or SFTP credentials ready so you can access files even when /wp-admin/ is inaccessible.
If you manage an enterprise e-commerce platform, consult our WordPress server support specialists before mass-deactivating plugins.

Step 1 — Check the Web Server and PHP Error Logs

Do not guess. Web servers log the exact filename and line number that triggered the 500 error.

Run these commands to inspect the logs:

# On Apache (Ubuntu/Debian):
tail -n 40 /var/log/apache2/error.log

# On Apache / cPanel (AlmaLinux/Rocky):
tail -n 40 /etc/apache2/logs/error_log || tail -n 40 /home/*/public_html/error_log

# On Nginx:
tail -n 40 /var/log/nginx/error.log

# On PHP-FPM:
tail -n 40 /var/log/php*-fpm.log

Reading the Log

If you see: Invalid command 'RewriteRule', perhaps misspelled...
Cause: Apache mod_rewrite is not enabled, or syntax inside .htaccess is malformed.
If you see: Fatal error: Allowed memory size of 134217728 bytes exhausted...
Cause: The site hit its 128MB PHP memory limit. Proceed to Step 3.
If you see: PHP Fatal error: Uncaught Error: Call to undefined function... in /wp-content/plugins/bad-plugin/file.php:42
Cause: bad-plugin has crashed the site. Proceed to Step 4.

Step 2 — Diagnose and Replace Corrupted .htaccess

A broken or invalid directive inside .htaccess is the single most common cause of sudden 500 errors on Apache and LiteSpeed servers.

Temporarily Rename .htaccess

Log into your server and rename the file:

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

Refresh your website in an incognito browser window.

If the 500 error disappears: Your .htaccess file was the problem!
If the 500 error persists: Rename it back (mv .htaccess.disabled .htaccess) and proceed to Step 3.

Generate a Clean Default WordPress .htaccess

If renaming solved the error, create a brand-new, clean .htaccess file:

cat << 'EOF' > /var/www/html/.htaccess
# BEGIN WordPress
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
# END WordPress
EOF

Set proper permissions:

chmod 644 /var/www/html/.htaccess
chown www-data:www-data /var/www/html/.htaccess

Step 3 — Increase the PHP Memory Limit

Modern WordPress setups with page builders and e-commerce plugins routinely require 256MB to 512MB of RAM. If your limit is set to the default 64MB or 128MB, memory exhaustion triggers an immediate 500 error.

1. Update wp-config.php

Edit wp-config.php and add these two definitions just above the /* That's all, stop editing! */ line:

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

2. Update php.ini

Edit your active php.ini file (e.g., /etc/php/8.2/fpm/php.ini or /etc/php.ini):

memory_limit = 512M
upload_max_filesize = 64M
post_max_size = 64M
max_execution_time = 300

Reload your web server and PHP-FPM:

# Ubuntu/Debian:
sudo systemctl reload php8.2-fpm && sudo systemctl reload nginx

# RHEL/AlmaLinux:
sudo systemctl reload php-fpm && sudo systemctl reload httpd

Step 4 — Isolate Faulty Plugins and Themes

If memory and .htaccess did not resolve the error, an active plugin or theme has thrown an unhandled fatal PHP exception.

Method A: Deactivate Plugins via WP-CLI (Fastest)

If you have SSH access, use WP-CLI to deactivate all plugins at once:

wp plugin deactivate --all --path=/var/www/html --allow-root

Refresh your site:

If the error is gone, activate plugins one by one (wp plugin activate <name>) until the error returns to pinpoint the culprit.

Method B: Rename the Plugins Directory via Shell / SFTP

If you do not have WP-CLI:

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

Check your website. If it loads, your theme and core are healthy. Rename the folder back (rmdir plugins && mv plugins_disabled plugins) and rename individual plugin folders inside /wp-content/plugins/ one by one to find the broken extension.

Step 5 — Enable WP_DEBUG to Reveal Hidden PHP Errors

If the screen is still blank or returning 500, configure WordPress to write detailed error traces to a private log file.

Open wp-config.php and update the debugging section:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

Save the file and refresh your website.

Now inspect the debug log generated inside /wp-content/:

cat /var/www/html/wp-content/debug.log | tail -n 25

This log will state the exact file, class, or function that failed. Once resolved, set WP_DEBUG back to false for security.

Step 6 — Verify File Permissions

Incorrect file permissions or ownership can cause Apache/Nginx to reject requests with an internal server error:

Run these standard permission corrections:

# Correct directory permissions to 755
find /var/www/html -type d -exec chmod 755 {} \;

# Correct file permissions to 644
find /var/www/html -type f -exec chmod 644 {} \;

# Ensure proper web server ownership (Ubuntu/Debian)
chown -R www-data:www-data /var/www/html

# (On RHEL/AlmaLinux/cPanel, replace www-data with user:user)

Common Mistakes

Leaving WP_DEBUG_DISPLAY enabled in production: Displaying fatal PHP errors on the screen reveals database paths, server usernames, and library versions to public visitors. Always use WP_DEBUG_LOG instead.
Setting permissions to 777: Running chmod -R 777 is a major security vulnerability. Furthermore, modern hosting panels configured with suexec or suPHP automatically block scripts with 777 permissions with a 500 error.
Upgrading PHP versions without testing plugin compatibility: Jumping from PHP 7.4 directly to PHP 8.3 on an older WordPress site will cause fatal errors if legacy plugins use removed functions.

Prevention Checklist

Set memory_limit to at least 256M for WooCommerce or page-builder websites.
Always test plugin, theme, and PHP updates on a staging copy before deploying to production.
Maintain automated, off-site daily backups with our server backup management service.
Use PHP 8.2 or 8.3 with modern, actively maintained plugins.

Quick Reference Commands

Operation	Command
Tail Apache error log	`tail -f /var/log/apache2/error.log`
Tail Nginx error log	`tail -f /var/log/nginx/error.log`
Disable all WP plugins	`wp plugin deactivate --all --allow-root`
Fix folder permissions	`find . -type d -exec chmod 755 {} \;`
Fix file permissions	`find . -type f -exec chmod 644 {} \;`
Check WP debug log	`tail -f wp-content/debug.log`

Frequently Asked Questions

Can a corrupted WordPress core update cause a 500 error?

Yes. If an automated background core update is interrupted by a network timeout or memory limit, essential PHP files in /wp-admin/ or /wp-includes/ can be left half-written. You can re-install core files safely via WP-CLI with wp core download --skip-content --force --allow-root.

Why does the 500 error only appear when uploading large images?

If the error occurs only during file uploads, your server is hitting the PHP upload_max_filesize or post_max_size limit, or the image processing library (GD or Imagick) is exhausting its memory allocation while creating image thumbnails.

What is the difference between a 500 error and a 502 error?

A 500 error is generated directly by the web application or local server processing the code. A 502 Bad Gateway occurs when a reverse proxy (like Nginx or Cloudflare) connects to an upstream application backend (like PHP-FPM or Apache), and the backend crashes or closes the connection prematurely.

How does ServerCare360 assist with recurring WordPress outages?

Our WordPress server support and emergency server support teams analyze server log dumps, isolate conflicting plugins, configure Redis object caching, tune PHP-FPM worker pools, and provide 24/7 rapid incident resolution.