Fixing the 500 Internal Server Error in WordPress: 7 Causes

A 500 Internal Server Error means something went wrong on the server, but PHP isn’t telling you what. Unlike a plugin error that names a file and line number, a 500 gives you nothing in the browser — just a generic message. That’s what makes it frustrating to debug: the cause is almost always specific, but the error message isn’t. This guide covers the seven most common causes and how to isolate which one you’re dealing with.

First: Enable Debug Logging to See the Actual Error

Before touching plugins or files, turn on WordPress’s built-in error logging. This writes the real error message to a log file instead of hiding it behind a generic 500 page.

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

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

WP_DEBUG_LOG writes errors to wp-content/debug.log. WP_DEBUG_DISPLAY set to false keeps errors out of the browser (so visitors don’t see PHP traces) while still logging them. After saving, reload the page that’s showing the 500 error, then check wp-content/debug.log via FTP or your host’s file manager.

The log entry will tell you exactly which file and line number triggered the error. That information turns a frustrating “something went wrong” into a specific diagnosis. Most of the causes below become obvious once you know the failing file path.

Remember to remove these lines or set WP_DEBUG to false after fixing the issue. A production site should not run with debug mode active — it can expose error details to attackers and slow down page generation.

Cause 1: Plugin Conflict or Corrupted Plugin

This is the most common cause. A plugin that updated incompatibly with your PHP version or WordPress version, a plugin installed mid-migration, or two plugins with conflicting hooks can all trigger a 500 error that appears instantly or only on certain page types.

How to isolate it

1. Connect to your site via FTP or your host’s file manager
2. Navigate to wp-content/
3. Rename the plugins folder to plugins_disabled
4. Create a new empty folder called plugins
5. Reload your site — if the 500 error is gone, a plugin was the cause
6. Delete the empty plugins folder and rename plugins_disabled back to plugins
7. Now go to wp-admin → Plugins and reactivate plugins one at a time, reloading the site after each activation until the 500 returns — that last activated plugin is the culprit

If bulk-disabling plugins this way isn’t practical (large plugin count, can’t access wp-admin at all), the debug log from the previous step will usually name the offending plugin file directly.

For a systematic approach to plugin isolation and ongoing conflict prevention, see how to identify and fix WordPress plugin conflicts.

Cause 2: Corrupted or Misconfigured .htaccess File

WordPress uses .htaccess for permalink routing. A corrupted, hand-edited, or incorrectly generated .htaccess file is a common cause of sitewide 500 errors — particularly after a server migration, a WordPress update that regenerated it, or after manually adding redirect rules.

How to fix it

1. Connect via FTP and navigate to your web root
2. Rename .htaccess to .htaccess_backup
3. Reload your site — if the 500 is gone, the .htaccess was the cause
4. Go to WordPress admin → Settings → Permalinks
5. Click Save Changes without changing anything — WordPress will regenerate a fresh, correct .htaccess
6. If you had custom redirect rules in the old file, add them back carefully above the # BEGIN WordPress comment block

If the 500 persists after renaming .htaccess, the file wasn’t the cause — rename it back and move to the next section. For more on how .htaccess works on Apache and what goes in it, see the complete .htaccess redirect guide.

Cause 3: PHP Memory Exhaustion

When a PHP process runs out of allocated memory, it throws a fatal error. On some server configurations this renders as a blank white screen; on others it returns a 500 status. The debug log will contain a line like:

Fatal error: Allowed memory size of 67108864 bytes exhausted
(tried to allocate 2097152 bytes)

How to fix it

The quickest fix is to raise WP_MEMORY_LIMIT in wp-config.php:

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

However, WP_MEMORY_LIMIT cannot exceed the PHP-level memory ceiling set by your host. If this doesn’t fix it, you need to raise the PHP limit itself via php.ini or by contacting your host. The full four-method breakdown — including why the wp-config approach alone doesn’t always work — is in the guide to increasing the WordPress memory limit.

Cause 4: PHP Version Incompatibility

Plugins and themes declare minimum PHP version requirements. If your server runs a PHP version the plugin doesn’t support — or if you’ve recently upgraded PHP and a plugin uses deprecated or removed functions — you’ll get a 500 (or a fatal error in the debug log).

The debug log will typically show something like:

Fatal error: Call to undefined function some_function_name() in
/wp-content/plugins/some-plugin/some-file.php on line 142

Or for the reverse (PHP too old for the plugin):

Parse error: syntax error, unexpected token "match", expecting ";" in
/wp-content/plugins/some-plugin/some-file.php on line 67

How to fix it

• PHP too old: Upgrade PHP. Most shared hosts let you switch PHP versions in cPanel. See how to upgrade PHP on Ubuntu for server-level upgrades. The right target is PHP 8.2 or 8.4 — both are actively supported as of 2026.
• PHP upgraded and something broke: The error will name the plugin. Update that plugin (it may have a newer version with PHP compatibility fixes), or temporarily downgrade PHP while you find a replacement for the incompatible plugin.

Cause 5: Incorrect File or Folder Permissions

WordPress files need specific permission settings to be readable by the web server. If a migration, manual upload, or server configuration change left files with wrong permissions, PHP can’t read them and returns a 500.

Correct permissions for WordPress:

• Folders: 755 (rwxr-xr-x) — owner can write; web server can read and traverse
• Files: 644 (rw-r–r–) — owner can write; web server can read
• wp-config.php: 640 or 600 — more restrictive is fine here since only the owner (and PHP) needs to read it

If you have SSH access, fix permissions recursively with:

find /path/to/wordpress -type d -exec chmod 755 {} \;
find /path/to/wordpress -type f -exec chmod 644 {} \;

Replace /path/to/wordpress with your actual WordPress root path (e.g. /home/user/public_html). Via FTP, most clients let you right-click a folder and set permissions recursively.

Cause 6: Corrupted wp-config.php or WordPress Core Files

A 500 error that appeared immediately after a WordPress core update — or after a migration where files were transferred inconsistently — may indicate corrupted core files or a damaged wp-config.php.

Checking wp-config.php

Open wp-config.php via FTP or file manager and look for:

• Whitespace or characters before <?php at the very beginning of the file
• Whitespace or characters after the closing ?> tag (if it exists — it’s actually safe to remove ?> entirely)
• Encoding issues — the file must be saved as UTF-8 without BOM

Any content outside the PHP tags causes PHP to emit output before headers are sent, which can trigger a 500 or redirect loop.

Re-downloading WordPress core files

If the debug log points to a file in wp-admin/ or wp-includes/ (not a plugin or theme), the core files may be corrupted. You can re-upload WordPress core without touching your content:

1. Download the latest WordPress zip from wordpress.org
2. Extract it locally
3. Upload the wp-admin/ and wp-includes/ folders to your server, overwriting what’s there
4. Do not overwrite wp-content/ — that’s where your themes, plugins, and uploads live
5. Do not overwrite wp-config.php — that has your database credentials

Cause 7: Missing Files After Migration

A WordPress migration involves moving both the database and the file system. If the file transfer was interrupted, if certain files weren’t copied (media, plugin files, core files), or if the folder structure ended up in the wrong location, PHP will error on any reference to a file that doesn’t exist where it’s expected.

How to fix it

1. Check the debug log — it will name the specific missing file path
2. Verify wp-content/ transferred completely: plugins, themes, and uploads subdirectories should all be present
3. Check that the WordPress root contains index.php, wp-login.php, wp-config.php, wp-admin/, wp-includes/, and wp-content/ — if any are missing, re-upload from backup
4. Verify your database credentials in wp-config.php match the new server’s database — a mismatch here causes a different error (database connection failed) but is worth checking during any migration

If None of These Fix It

If you’ve worked through all seven causes, enabled debug logging, and still can’t reproduce or identify the error, the issue is likely at the server configuration level — Apache or Nginx config, PHP-FPM settings, or a server-side timeout. At that point, contact your host’s support with the debug log contents and the steps you’ve already tried. Most managed WordPress hosts (Kinsta, WP Engine, SiteGround) have the server-side context to diagnose this quickly.

Once the site is back up, check the WordPress post-launch checklist — it covers the configuration steps (error logging, security headers, backup verification) that make diagnosing and recovering from future issues significantly faster. And if the 500 error is accompanied by redirect loops rather than a blank response, see how to fix the WordPress too many redirects error — those are often related but have a different root cause. If the error shows as a blank white screen instead of a 500 status code, the WordPress white screen of death guide covers the additional diagnostic steps specific to that presentation.