Error 500 in WordPress… what can I do?

You’ve just done an update to your WordPress website and now you’re getting an error 500, or a blank page, or a page that partially loaded. Disaster! What happened? How can we fix the situation and get the site back to a fully functional state?

What is an error 500?

By definition, Blank Page Syndrome (not that of writers… that of web artisans), the partially loaded page or what is commonly called an “error 500” is caused by a problem coming from the web hosting server and it is not uncommon to see the message “Internal Server Error”. The error is quite vague by definition, but it is usually not difficult to identify.

In all our investigations, we estimate that error 500s are caused in 99% of cases by one of the following two cases:

• A PHP error (usually from the theme or a plugin);
• An error from the web server (Apache via the .htaccess file or Nginx via its configuration file).

How to determine the error’s cause?

First of all, make a backup copy of the website.

Note that this operation can be more difficult since the chances are that if your site sends an error 500… your backup plugin will not be functional either. If this is the case, the files and the database will have to be manually copied. Otherwise, your favorite backup plugin could do the trick!

We will then attempt to confirm if the error comes from WordPress itself, the theme or a plugin. For this purpose, we have to activate WordPress’ DEBUG mode in order to obtain some clues. To do this, simply add the following lines to the wp-config.php file located at the root of the site:

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

Since WordPress 5.1, with regards to the debug file, it’s possible to change its name and location. Changing the location is a wise choice as it prevents a third party from accessing it and getting information that could be compromising about your installation. Simply change the WP_DEBUG_LOG constant in wp-config.php like this:

define( 'WP_DEBUG_LOG', '/home/satellitewp/errors.log');

Note: The value of the WP_DEBUG constant must also be set to true for the location change to be considered.

Then, we can visit the website again in order to cause the error. If a debug file is created in the /wp-content directory, it’s good news as it means that the error comes from the website’s code and not from the web hosting server.

The only thing left to do is to check the debug file to confirm what’s the origin of the problem. We can then fix the problem by correcting the code or removing the guilty plugin. But for a neophyte, this can be easier said than done.

If the debug file doesn’t exist, if it’s is empty or if it contains no recent errors, then chances are that the problem is caused by the configuration of your web server.

Generally speaking, the majority of web hosting providers use Apache as a web server. Apache uses an .htaccess file that contains certain rules which are needed for your site to function properly. Many plugins can modify this file and it’s possible that one of them may have corrupted .htaccess while trying to insert changes.

The most efficient way to validate everything is to check Apache logs. Unfortunately, the location of these files is different from one hosting provider to another and you may need to contact your host to get the contents.

A simple way to do the test would be to rename the existing file to .htaccess-old and create a new .htaccess file containing the the defaults following a new WordPress installation:

# BEGIN WordPress

RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]

# END WordPress

Afterwards, you may visit your site again and see if the problem still exists. Before making this change, be aware that security plugins such as iThemes Security, WordFence, All-in-One Security & Firewall and several others (including caching plugins) frequently modify the .htaccess file. If you use such a plugin, sometimes disabling and re-enabling the plugin may fix the problem.

You can also configure them so that they do not modify the .htaccess file, forcing you to copy & paste the new rules manually, but allowing you to manage the changes to this file more carefully.

Should I disable all my plugins?

No, no and no!

The “Disable all plugins and reactivate them one by one” method is often suggested to identify the problem. However, blindly disabling everything and reactivating plugins one by one shows a misunderstanding of the situation and an attempt to find the problem by deduction rather than understanding the cause. When the activation of a plugin causes a failure, it will be presumed to be the one to blame. However, it might be the combination of this plugin with another component that causes the problem. This is why you have to be diligent and confirm using log files.

Conclusion

At this point, you will either have solved your problem or be completely baffled as to where to start to make things right.

You may also ask your web hosting provider for help in the first place to see if they can help you at no cost. Some, such as Kinsta include this service and have also written articles to help you diagnose the problem yourself. Otherwise, you can get help from WordPress experts by contacting us. We solve problems such as this on a daily basis and we’ll do everything that’s necessary to restore your website as quickly as possible..