WordPress 500 internal server error: what it means and how to fix it

A 500 internal server error in WordPress means something went wrong on the server while processing the request, but the server cannot tell you what. It is the least helpful error message in web development – the equivalent of a check engine light with no diagnostic code.

The 500 error itself is not the problem. It is a symptom. Something underneath – a PHP fatal error, a misconfigured file, a memory limit, a corrupted plugin – caused PHP to fail, and the web server translated that failure into a generic 500 response. Finding the actual cause requires looking past the error page and into the server logs.

What a 500 error means in WordPress#

When you visit a WordPress page, the web server hands the request to PHP, which executes the WordPress code, queries the database, and returns the finished HTML. If PHP encounters a fatal error during that process – a syntax error, a missing function, an out-of-memory condition – it cannot return any useful output. The web server receives nothing usable from PHP and returns a 500 status code to the browser.

The browser shows one of several messages depending on your server configuration:

• “500 Internal Server Error”
• “HTTP Error 500”
• A blank white page (the “white screen of death”)
• The server’s default error page

All of these mean the same thing: PHP crashed before it could produce output.

A 500 error can affect the entire site or only specific pages. If the error happens in a plugin that only runs on certain pages, those pages return 500 while the rest of the site works. If the error is in a core file, a theme’s functions.php , or during WordPress initialization, the entire site goes down – including the admin dashboard.

Step 1: Enable debugging to find the real error#

The single most useful thing you can do is turn on WordPress debugging. Without it, you are guessing.

Edit wp-config.php via SSH or SFTP and add (or update) these lines before the “That’s all, stop editing!” comment:

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

This configuration writes PHP errors to wp-content/debug.log without displaying them on the frontend. Setting WP_DEBUG_DISPLAY to false is important – you do not want PHP error details visible to your site visitors.

For a deeper explanation of PHP error display settings and the difference between logging and displaying errors, see How to display PHP errors and enable error reporting.

After enabling debug logging, reproduce the 500 error by visiting the page that triggers it. Then check the log:

# Via SSH
tail -50 /path/to/wordpress/wp-content/debug.log

Or download wp-content/debug.log via SFTP and open it in a text editor.

The log will contain the actual PHP error – the file path, line number, and error message. This is the real cause of the 500 error. Everything else in this guide helps you narrow down the cause if you cannot enable debugging, but the debug log is always the fastest path to a fix.

For detailed guidance on configuring PHP error logging including log rotation and custom log paths, see PHP error logging: how to log errors to a file.

If you cannot access wp-config.php

If SFTP access is not available, some hosting control panels let you access the file manager. If you have SSH access, edit the file directly:

nano /path/to/wordpress/wp-config.php

If you have no file access at all, contact your hosting provider – they can check the server’s PHP error log for you, which contains the same information.

Cause 1: Plugin conflict or fatal error#

Plugins are the most common cause of 500 errors in WordPress. A plugin update that introduces a PHP fatal error, a conflict between two plugins, or a plugin that is incompatible with the current PHP version will crash WordPress.

How to diagnose

The debug log will show something like:

PHP Fatal error: Uncaught Error: Call to undefined function some_function()
in /path/to/wordpress/wp-content/plugins/plugin-name/file.php on line 42

The file path tells you exactly which plugin caused the error.

How to fix when you can access wp-admin

Go to Plugins, deactivate the plugin named in the error, and verify the site works. Then either update the plugin, replace it, or contact the plugin author.

How to fix when you cannot access wp-admin

If the 500 error affects the admin dashboard too, you need to deactivate the plugin from the filesystem.

Via SSH:

cd /path/to/wordpress/wp-content/plugins/
mv plugin-name plugin-name.disabled

Renaming the plugin’s directory forces WordPress to deactivate it on the next page load.

Via SFTP:

Connect to your site, navigate to wp-content/plugins/ , and rename the offending plugin’s folder (add .disabled to the end).

If you do not know which plugin is the cause:

Rename the entire plugins directory to deactivate all plugins at once:

mv plugins plugins.disabled
mkdir plugins

If the site loads after this, one of the plugins was the cause. Create a fresh plugins directory, then move plugins back one at a time, loading the site after each one, until you find the one that triggers the 500 error:

mv plugins.disabled/plugin-name plugins/plugin-name

Via WP-CLI (if accessible):

wp plugin deactivate --all

Then reactivate one at a time:

wp plugin activate plugin-name

Prevention

Keep plugins updated, but do not update all plugins simultaneously on a production site. Update one at a time so you can identify which update caused a problem. Remove plugins you are not using – deactivated plugins can still cause issues if their files contain syntax errors that PHP parses during certain operations.

For more context on why WordPress plugins are such a common source of fatal errors and security vulnerabilities, see Why WordPress plugin vulnerabilities are out of control.

Cause 2: PHP memory limit exhausted#

When a PHP script exceeds the allowed memory limit, PHP kills the process and returns a fatal error. WordPress and its plugins can be memory-hungry, especially on pages with complex layouts, large WooCommerce product catalogs, or plugins that process images.

How to diagnose

The debug log will say:

PHP Fatal error: Allowed memory size of 67108864 bytes exhausted
(tried to allocate 12345 bytes) in /path/to/file.php on line XX

The “67108864 bytes” number is 64 MB. Convert the bytes to megabytes by dividing by 1048576 to see the current limit.

How to fix

Increase the memory limit in wp-config.php:

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

WP_MEMORY_LIMIT applies to frontend requests. WP_MAX_MEMORY_LIMIT applies to admin dashboard requests (which typically need more memory for things like plugin updates and media processing).

Via php.ini or .user.ini:

If your hosting allows PHP configuration overrides:

memory_limit = 256M

Important: Increasing the memory limit is a bandage, not a cure. If your site needs 256 MB of memory per request, something is wrong – a plugin is loading too much data, an unoptimized query is fetching thousands of rows, or an image processing operation is working on files that are too large. The memory increase buys you time, but investigate the underlying cause.

If you are regularly hitting memory limits even at 256 MB, check which plugins are consuming the most memory. The Query Monitor plugin can profile memory usage per component.

Cause 3: Corrupted .htaccess file (Apache servers)#

On Apache-based hosting, WordPress uses the .htaccess file for URL rewriting (pretty permalinks), redirects, and various server-level directives. If this file becomes corrupted – a plugin wrote invalid rules, a manual edit introduced a syntax error, or the file contains conflicting directives – Apache cannot process requests and returns a 500 error.

Note: This cause only applies to servers running Apache. If your server runs Nginx, there is no .htaccess file – Nginx uses server block configuration files instead, and URL rewriting is handled at the server level. Nginx misconfigurations produce different error codes (usually 502 or 503 rather than 500).

How to diagnose

If the 500 error is site-wide and started after a plugin change, permalink change, or manual .htaccess edit, this is a likely cause.

How to fix

Rename the current .htaccess file:

mv .htaccess .htaccess.backup

Visit the site. If it loads (but permalinks show 404 errors on every page except the homepage), the .htaccess file was the problem.

Regenerate the file:

Log into wp-admin, go to Settings > Permalinks, and click Save without changing anything. WordPress will write a fresh .htaccess file with the default rewrite rules.

Or via WP-CLI:

wp rewrite flush --hard

Standard WordPress .htaccess content for reference:

# 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

If your .htaccess contains custom rules added by plugins or manually, do not blindly regenerate it – you will lose those rules. Instead, compare the backup with the fresh version to find what was added.

Cause 4: Corrupted WordPress core files#

WordPress core files can become corrupted during a failed update (the update process was interrupted), a disk error, or a security compromise where an attacker modified core files. If a core file contains invalid PHP, WordPress crashes with a 500 error.

How to diagnose

The debug log will reference a file in wp-admin/ or wp-includes/ rather than a plugin or theme file:

PHP Fatal error: ... in /path/to/wordpress/wp-includes/class-wp-query.php on line XX

How to fix

Using WP-CLI (the cleanest method):

wp core download --force --skip-content

This downloads a fresh copy of WordPress core, overwriting wp-admin/ and wp-includes/ , while leaving wp-content/ (your themes, plugins, and uploads) untouched.

Manually:

1. Download the exact WordPress version your site is running from wordpress.org
2. Extract it
3. Upload the  wp-admin/  and  wp-includes/  directories to your server, overwriting the existing ones
4. Upload the root files ( wp-login.php ,  wp-cron.php ,  index.php , etc.) but do not overwrite  wp-config.php

If the corruption was caused by a failed update, run the update again after reinstalling core:

wp core update
wp core update-db

If you suspect the corruption was from a security compromise rather than a failed update, see My WordPress site was hacked: what to do right now before reinstalling – you need to clean up the compromise first, or the attacker’s code will still be present in wp-content/ .

Cause 5: Theme fatal error#

A theme’s functions.php file runs on every page load. If it contains a fatal error – a syntax mistake after manual editing, a theme update that breaks on the current PHP version, or a function conflict with a plugin – the entire site returns 500.

How to diagnose

The debug log will reference a file in wp-content/themes/your-theme/ :

PHP Fatal error: ... in /path/to/wordpress/wp-content/themes/theme-name/functions.php on line XX

How to fix

Switch to a default theme via SSH or SFTP:

Rename the broken theme’s directory:

cd wp-content/themes/
mv broken-theme broken-theme.disabled

WordPress will fall back to its default theme (Twenty Twenty-Five, or whatever default theme is installed). If no default theme is present, WordPress will show a “Theme directory does not exist” error – install a default theme first.

Via WP-CLI:

wp theme activate twentytwentyfive

Via the database (last resort):

If you cannot use WP-CLI and the admin dashboard is down, you can switch themes directly in the database:

wp db query "UPDATE wp_options SET option_value='twentytwentyfive' WHERE option_name='template';"
wp db query "UPDATE wp_options SET option_value='twentytwentyfive' WHERE option_name='stylesheet';"

Replace twentytwentyfive with whatever default theme you have installed, and adjust the table prefix if yours is not wp_ .

Cause 6: PHP version incompatibility#

WordPress core and most well-maintained plugins support PHP 7.4 through 8.3. But older plugins, custom code, or themes may use functions or syntax that was removed in newer PHP versions.

How to diagnose

The debug log will show errors related to deprecated or removed PHP features:

PHP Fatal error: Uncaught TypeError: count(): Argument #1 ($var) must be
of type Countable|array, null given

Or:

PHP Fatal error: ... cannot use string offset as an array

These errors often appear after a PHP version upgrade rather than a WordPress change.

How to fix

Downgrade PHP temporarily to the version that was working. Most hosting control panels allow PHP version switching per site.

Then update the offending code. Common PHP 8.x breaking changes that affect WordPress sites:

• count()  on non-countable types (null, strings) now throws a TypeError
• each()  was removed in PHP 8.0
• Named arguments can break functions that do not expect them
• Null values passed to internal string functions ( strlen(null) ,  str_contains(null, ...) ) produce deprecation warnings in 8.1 and errors in later versions

If the error is in a plugin, check whether a newer version of the plugin supports your PHP version. If the error is in custom code, fix the code. If the error is in a theme, contact the theme author or switch themes.

See End-of-life PHP: the risks of running an unsupported version for a full discussion of PHP version lifecycle and why staying current matters.

Cause 7: File permission issues#

If PHP cannot read WordPress files due to incorrect file permissions, it fails with a 500 error. This typically happens after a migration, a manual file transfer where permissions were not preserved, or a security hardening attempt that was too aggressive.

How to diagnose

The PHP error log (not the WordPress debug log, since WordPress may not load far enough to write to it) will show permission-related errors:

PHP Warning: require(/path/to/wordpress/wp-includes/load.php): failed to open stream:
Permission denied

How to fix

Set the correct WordPress permissions:

# Directories: 755 (owner can write, everyone can read and execute)
find /path/to/wordpress -type d -exec chmod 755 {} \;

# Files: 644 (owner can write, everyone can read)
find /path/to/wordpress -type f -exec chmod 644 {} \;

# wp-config.php: more restrictive
chmod 640 wp-config.php

Ensure the file owner matches the user PHP runs as:

# Check which user PHP runs as
ps aux | grep php-fpm

Then set ownership accordingly. For a detailed explanation of the WordPress permission model, see The uploaded file could not be moved to wp-content/uploads, which covers the same permission principles in the context of upload failures.

Intermittent 500 errors#

If the error comes and goes rather than being constant, the cause is different from a hard fatal error.

Resource exhaustion under load. During traffic spikes, PHP may run out of available workers or memory. Requests that arrive when no PHP worker is available time out and return a 500 (or 502/503, depending on the server configuration). This is a capacity issue, not a code issue.

Cron or background process conflicts. WordPress cron ( wp-cron.php ) runs background tasks on page loads. If a cron job consumes a lot of memory or runs for a long time, it can cause intermittent 500 errors for visitors whose requests trigger the cron execution.

Database connection issues. If PHP can load but the database connection fails intermittently, some requests succeed and others return 500. See Error establishing a database connection in WordPress: how to fix it for the full diagnostic process.

OPcache corruption. PHP’s OPcache stores compiled bytecode. If the cache becomes corrupted (usually after deploying new code while requests are in flight), PHP serves stale or broken bytecode until the cache is cleared. Restarting PHP-FPM clears the OPcache.

How Hostney handles 500 errors differently#

The container isolation model changes how 500 errors behave and how quickly they are resolved.

Per-site error logs. Each website has its own PHP error log at a predictable location inside the account’s home directory. There is no digging through a shared server log trying to find your site’s errors among thousands of other sites’ messages. When a 500 error occurs, the cause is in your site’s error log and only your site’s error log.

Container auto-recovery. Each WordPress site runs in its own PHP container managed by systemd. If a PHP process crashes, the container restarts automatically within seconds. On traditional shared hosting, a PHP-FPM crash can affect every site on the server and require a manual restart by the hosting provider. With per-site containers, the blast radius is limited to the single site that crashed.

PHP version per site. Each site can run a different PHP version, switchable through the control panel under Hosting > PHP Manager. If a plugin breaks on PHP 8.2, you can switch that specific site to 8.1 without affecting other sites on the same server. No support ticket, no waiting.

Memory limits via PHP Manager. PHP memory limits and other runtime settings (max execution time, upload size, post size, input variables) are configurable per site through the control panel. The default memory limit is generous enough that most WordPress sites never hit it, and if you need to adjust it for a specific site, the change takes effect immediately without a server restart.

No .htaccess issues. Hostney uses Nginx, not Apache. The entire category of .htaccess-related 500 errors does not exist. URL rewriting is handled at the server level, and WordPress permalink settings write to the database rather than to a file that can become corrupted.

Summary#

A 500 error in WordPress means PHP crashed during execution. The error message itself tells you nothing – the real cause is in the PHP error log. Enable WP_DEBUG_LOG to capture the actual error, then work through the causes: plugin conflicts, memory limits, corrupted .htaccess (Apache only), corrupted core files, theme errors, PHP version incompatibility, or file permissions.

If you cannot access the admin dashboard, all of these can be diagnosed and fixed via SSH or SFTP. The most common fix is deactivating a recently updated plugin by renaming its directory. The most common mistake is guessing instead of reading the error log.

For 500 errors that happen intermittently rather than consistently, look at resource limits and caching rather than code errors. And for the related but distinct issue of your entire site going down with a database error, see Error establishing a database connection in WordPress: how to fix it. For a quick reference covering this error and 50+ other common WordPress errors, see How to fix the most common WordPress errors.