The 500 Internal Server Error is the most unhelpful and nondescript bane of web developers everywhere. It’s a catch-all error message that can literally mean anything. Sometimes, your WordPress site gives no error at all and just shows a blank page. How on earth are you supposed to figure out what’s wrong?
It happens to the best of us, but no need to panic. Here’s my own debug process, in order of likelihood and with solutions.
If you’ve just installed a new plugin or if your site is showing 500 errors after a core WordPress upgrade, the most likely cause is an incompatible plugin. There are many reasons for a plugin being “broken”:
WordPress may have removed some core functions the plugin uses.
The plugin may have been coded for an old version of PHP, and not been updated.It could just be coded incorrectly, by referring to default database names rather than using prefixes, for example.
Identifying the plugin is easy if you’ve just installed one and the error has emerged, but how can you disable the plugin if it’s taken down the wp-admin area of your site too? You’ll need FTP access, is the short answer, though the web-based file manager from CPanel or Plesk will work fine too.
All you need to do is rename the wp-content/plugins/ folder. Place a _ in front of the plugins folder, so it’s named _plugins, and you should now be able to login again to your WordPress admin area. By renaming the folder, you effectively de-activated every plugin – you should get a bunch of error messages from WordPress saying “X plugin was deactivated because the file Y.php can’t be found”. Don’t worry, you won’t have lost any settings – those are stored in the database, and any decent plugin should find them again upon re-activation.
Rename the folder back again, removing the _. Refresh the WordPress plugins and they’ll all be listed again, but in a deactivated state. You can now re-activate them one by one until you find the culprit; then do it all again, obviously leaving out the bad plugin this time.
It’s unfortunate when this happens, but chances are there’s a better plugin out there that is compatible. Find it.
Disabling plugins didn’t help? It’s probably something in your theme, then. Just like plugins, you can force the active theme to break by simply renaming it. Go back to the WordPress admin area (if you can, of course – if you can’t, it’s probably nothing to do with your theme) and WordPress will alert you that it’s fallen back to the default theme. Check the site again. Of course, this doesn’t really help if you’re committed to a particular theme, so may want to re-enable it and head down to the section on Enabling PHP Debug; or just go and find a newer, compatible theme.
If de-activating your plugins achieved nothing and it’s also not your theme, it’s possible that your .htaccess file became corrupted in some way. Usually when this happens you can still access the admin area of the site. The .htaccess file handles rewrite rules and cache settings, but sometimes you’ll edit this file directly to manually code in things like 301 redirects.
Rename the .htaccess file in the root of your WordPress install folder 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 “.” at the start of the filename is a way of saying “hide this” in Linux and other UNIX-like systems.
Once you’ve renamed the current .htaccess, go back to 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, though any changes you made manually will be lost.
Enable PHP Debugging
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 in the root of your WordPress install. Find the line that says:
Comment it out using // at the start, then paste in the following:
This will start outputting errors to a file in wp-content folder called error.log. If you refresh your FTP and see nothing after a minute or so, it’s possible it 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 this example, I see a lot of PHP Notices about deprecated code, but these won’t actually break a site.
I recently had a case where roughly half of all page loads were coming up as 500, but with no set pattern and absolutely nothing helpful in the error logs. Activiting WordPress debug logs showed nothing obvious – lots of PHP notices and deprecations but nothing critical. Finally, I realised I had installed APC caching onto the server the weekend before, to use with W3 Total Cache. Uninstalling that completely eradicated the 500 errors.
My point: 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 (why should you use a VPS instead of shared hosting?) you’re responsible for making sure everything works together, and this is harder than it sounds.