The 500 Internal Server Error is the most unhelpful bane of WordPress users everywhere. It's a catch-all error message that means precisely: something somewhere went wrong. Even worse, your WordPress site may present no error at all and just show a blank white page.

So how can you figure out exactly what's wrong, and fix it?

First: don't panic, because it's usually an easy fix! Then: follow this debug process and your WordPress Internal Server Error will be fixed in no time.

Are WordPress Plugins Causing Error 500?

If you've just installed a new plugin or if your site is showing a 500 error after a core WordPress upgrade, the most likely cause is an incompatible plugin. There are many reasons a plugin can be broken:

• WordPress may have removed some core functions the plugin uses.
• It may have been coded for an old version of PHP, and not been updated in years.
• It could just be coded incorrectly, such as referring to default database names rather than using prefixes. We're all guilty of lazy coding sometimes!

Identifying the plugin is easy if you've just installed one and the error has just emerged. But how can you disable the plugin if the admin area is inaccessible? And what if you don't even know which plugin caused the error? You'll need FTP access in either case, but a web-based file manager from CPanel or Plesk will work fine too.

Solution:

Know precisely which plugin is broken? Find the plugin and delete it from within the wp-content/plugins/ folder. You should now be able to log in again. Find an alternative for whatever functionality you wanted.

If you're not sure which plugin caused the error, you should rename the entire wp-content/plugins/ folder itself. Place an underscore ("_") in front, so it's named _plugins.

By renaming the folder, you effectively de-activate every plugin at once. You should now be able to log in again, but will be greeted by a list of error messages from WordPress saying "The plugin something.php has been deactivated due to an error: Plugin file does not exist."

Don't worry, you haven't lost any settings. Plugin settings are stored in the database, and most plugins will find them again upon reactivation.

Next, rename the folder back again, by removing the underscore. They'll all be listed on your Plugins page, but in a deactivated state. You can now reactivate them one by one until you find the culprit.

When the site crashes again, repeat the process, but this time don't reactivate the broken plugin!

500 Internal Server Error: Incompatible Theme

Disabling plugins didn't help? It may be something to do with your theme then. Just like plugins, you can forcibly disable the active theme by simply renaming its folder, which you'll find in the wp-content/themes/ directory.

If you still can't access the admin area after trying to rename both the plugins and your current theme, you should continue to further steps. If you can log in, WordPress will alert you that it's reverted to a default theme. At this point, you can either find a new theme, contact the theme developer for help, or try to fix it yourself.

To fix it yourself, or to provide further explanation for the developer, see the section later on Enabling WordPress Debug Mode.

500 Internal Server Error: Bad .htaccess File

If de-activating your plugins and theme achieved nothing, it's possible that your .htaccess file became corrupted in some way. This is typically the case if you can still access the admin area of the site, but the front end doesn't work correctly.

The .htaccess file handles the conversion of permalinks (pretty versions of a URL like /my-blog-post), to WordPress' internal ugly URL scheme (the one you get by default, which looks like /?p=12345). It's a critical part of WordPress, but plugins can sometimes mess it up.

Solution:

Again, head over to your FTP client or file manager. Rename the .htaccess file in the root of your WordPress install directory to something like .htaccess_old. If you can't actually see the file there, you need to enable viewing of hidden files---the exact method of doing that will vary according to your FTP client.

The period at the start of the filename is a way of saying "hide this file" in Linux and other UNIX-like systems.

Once you've renamed the current .htaccess, go back to the WordPress admin area, then head over to Settings > Permalinks and, without making any changes, hit save. This will automatically generate a new working version of the file.

If you made any changes to the file manually, those will be lost (but you shouldn't be editing the file by hand anyway).

Enable WordPress Debug Mode to Trace Errors

We can enable a debug log from within WordPress config, which might give a clue as to the exact problem, but at this point you're on your own. You'll need to figure out how to fix it, which will require coding skills.

To enable the debug log, open up wp-config.php, which you'll find in the root directory of your WordPress install. Be very careful editing this file: it may be a good idea to make a copy first that you can revert in case any unintended changes.

Find the line that says:

        define('WP_DEBUG', false);

    

If your site isn't frequently visited and you don't mind the error messages being displayed to everyone, just change the word false to true. Error messages will now be shown when you load the site.

If you'd rather keep the error messages private, comment that line out by typing // at the start, then paste in the following beneath it:

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

    

This will start outputting errors to a file in wp-content folder called error.log. If you refresh the FTP client and see nothing after a minute or so, it's possible WordPress doesn't have permission to create the file. Manually create a new error.log file and give it permission 666.

Be warned: this file will continue to grow larger until you remove those lines from your config. Don't forget to uncomment the original line as well. Read the file in any text editor, and check for any critical PHP errors.

In the example, I see a lot of PHP Notices about deprecated code, but these won't actually break a site.

500 Internal Server Error: Server Misconfiguration

Running your own Virtual Private Server is not easy. I was once faced with a mysterious case of roughly half of all page loads showing a 500 error, but with no discernible pattern and no clues in the server error logs. Activating WordPress debug logs showed nothing obvious either: lots of PHP notices and deprecations, but nothing critical.

Finally, I realized I had installed APC caching onto the server the weekend before, to use with W3 Total Cache in order to speed up the site. Uninstalling that completely eradicated the 500 errors.

My point is that the 500 error could simply be a combination of server configs that present an incompatibility. This is unlikely if you're using managed services, but with your own Virtual Private Server (what is a virtual server, and why you might want one) you're responsible for making sure everything works together, and this is harder than it sounds.

Is Your Site Out of Memory?

On a shared host, you may find the PHP memory limit is being hit---WooCommerce, forums, or related posts plugins could cause this due to their complexity. If you're lucky you'll see an error message like "Fatal Error: Allowed memory size of xxx bytes exhausted" but not always.

You may be able to fix this by adding the following line to your wp-config.php:

        define('WP_MEMORY_LIMIT', '64M');
    

Most shared hosts won't actually let you increase the memory limit though---you get what you're given. It may be time to consider other forms of hosting.

500 Error Fixed? Now Make Backups Daily!

The best defense against any kind of critical WordPress error is to maintain daily backups as well as a manual backup before every significant action (like a core WordPress update). Also, keep plugins and themes updated: new versions of WordPress frequently break old code.

It can be scary when your site breaks---especially if it's a source of income for you and not just a hobby. By following this guide and being methodical, you should have it back up again soon.

Consider upgrading to a managed WordPress hosting service that handles backups and optimizations for you, making such errors non-existent. We recommend InMotion Hosting (use this link to get 38% off) and Bluehost (use this link to get 25% off).