WordPress 500 Internal Server Error: Causes and Solutions

A 500 error gives you almost nothing. The server failed, but the browser doesn't say why. In WordPress, it's usually a plugin, a theme, a PHP fatal error, a broken .htaccess rule, a memory limit, or a half-finished update. The log tells you which one. Guessing doesn't.

Don't reinstall WordPress or start disabling things at random. That turns a small problem into a long night. Work from evidence. Protect the last working version of the site. And change one thing at a time.

Before You Change Anything

Create a backup if the hosting panel still allows it. If the dashboard is down, use the host's file manager or SFTP to download a copy of wp-content and the database. Write down the time the error started, the last update or edit, and whether it affects the whole site, only /wp-admin/, or one specific page.

Check the hosting status page too. If several unrelated sites are failing, the problem may not be WordPress.

First Five Minutes: Triage the 500

Don't read all ten sections first. Do this instead:

1. Open the error log. Look for the timestamp of the failed request.
2. If the 500 started right after an update or plugin install, roll that back.
3. If only /wp-admin/ is broken, suspect a plugin.
4. If the whole site is broken, suspect .htaccess, PHP, or core files.
5. If the log says "memory exhausted," raise the limit temporarily and find the culprit.

That order solves most 500 errors faster than a full conflict test.

1. Read the Server Error Log

The error log is the most valuable clue. In cPanel, look under Metrics → Errors or Logs → Error Log. On managed hosts, search for PHP Error Log or Server Logs. Match the timestamp to the exact moment the 500 happened.

Look for lines like:

PHP Fatal error: Allowed memory size of 268435456 bytes exhausted (tried to allocate 20480 bytes)
PHP Fatal error: Cannot redeclare function_name() (previously declared in /home/user/public_html/wp-content/plugins/example/example.php:42)
PHP Parse error: syntax error, unexpected '}' in /home/user/public_html/wp-content/themes/my-theme/functions.php on line 120
AH01071: Got error 'PHP message: PHP Warning: ...'

That line usually names the file and plugin. Don't skip it. If the log is empty, enable WP_DEBUG and WP_DEBUG_LOG in wp-config.php, then retry the failing page. The official WordPress debugging guide explains how. Just remember to turn debugging off when you're done.

2. Reverse the Most Recent Change

If the error started immediately after installing or updating something, that change is the prime suspect. Restore the previous version from a known-good backup. Or use the plugin's rollback feature if it has one.

Don't keep five untested changes active while troubleshooting. One clean reversal answers more than an hour of random settings changes.

3. Test for a Plugin Conflict

Plugin conflicts cause most 500 errors. If the dashboard works, deactivate recently changed plugins first. If the dashboard is down, use the hosting file manager or SFTP to rename the suspected plugin folder. For example, rename /wp-content/plugins/suspected-plugin to /wp-content/plugins/suspected-plugin.disabled. WordPress will deactivate it automatically.

When the source is unclear, test with all ordinary plugins disabled on staging, then reactivate them one at a time. Remember that must-use plugins live in /wp-content/mu-plugins/ and cannot be deactivated from the dashboard. You have to rename the folder or file.

4. Test the Active Theme

A PHP error in a theme or child theme can trigger a 500. Temporarily switch to a default theme like Twenty Twenty-Four. If the dashboard is inaccessible, rename the active theme folder via SFTP. WordPress will fall back to a default theme if one is available.

Preserve the original folder and customizations. Don't delete anything during diagnosis.

5. Check .htaccess and Rewrite Rules

On Apache servers, a broken or unsupported .htaccess directive can cause an internal server error. Rename the file to .htaccess.bak and test the site. If WordPress loads, go to Settings → Permalinks and click Save Changes to regenerate standard rules. Then restore any custom rules one at a time.

This doesn't apply to Nginx. Don't create an .htaccess file on Nginx. Ask the host to review the Nginx configuration instead.

6. Check PHP Version and Extensions

An older plugin may fail on a newer PHP version. Modern software may require a newer release. Compare the requirements for WordPress, the theme, and important plugins.

If the host recently changed PHP, temporarily switching back to the last compatible version confirms the cause. The long-term fix is to update or replace incompatible code—not to stay on unsupported software forever.

7. Investigate Memory Exhaustion

If the log says Allowed memory size exhausted, a plugin or theme is using too much memory. Raise the limit temporarily by editing wp-config.php:

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

Also check the host's PHP memory limit. Ask support to confirm the server limit. Raising the limit can confirm the problem, but it doesn't fix the cause. Find out why memory use increased. It's usually a plugin that loads too much on every request, or a poorly written query.

8. Repair an Incomplete WordPress Update

If the error appeared during a failed core update, replace the WordPress core files manually. Download a fresh copy from WordPress.org, delete the old wp-admin and wp-includes folders, and upload the new ones. Keep wp-content and wp-config.php untouched. Back up first.

Never download core files from an unofficial website.

9. Review File Permissions and Ownership

Wrong permissions or ownership can stop PHP from reading required files. This often happens after a manual upload or server move. Directories should usually be 755, files 644. Ownership should match the web server user.

Don't solve the problem by making everything writable. That's a security risk. Ask the host for the correct values for its environment.

10. Contact the Host With Useful Evidence

If the error remains, send support the failing URL, exact time, steps to reproduce, recent changes, and the relevant log line. Ask whether a firewall rule, PHP worker limit, disk limit, or server configuration rejected the request.

Specific evidence helps the host investigate faster than "my site is down."

If the Site Is Still Down

Most 500 errors come down to one of these: a plugin conflict, a theme error, a broken .htaccess, a PHP version mismatch, or memory exhaustion. Work through them in order. Change one variable at a time. Restore production only after the same request works consistently.

A calm diagnosis is faster than reinstalling WordPress repeatedly—and far less likely to overwrite the last working copy.