Error 500 in WordPress… what can I do?

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

What is a 500 error?

By definition, the syndrome of the blank page (not that of writers… that of the artisans of the web!), the partially loaded page or what is commonly called an “error 500” is caused by a problem coming from the server and it is not uncommon to read 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 500 errors are caused in 99% of cases by one of the following two cases:

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

How to identify the origin of the error?

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

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

Then, it is necessary to validate if the error comes from WordPress, the theme or an extension. For this purpose, it is necessary to activate the WordPress debug mode in order to obtain a clue. To do this, simply add the following lines to the wp-config file.php to 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, it is possible to specify the name of the debug file.log in order to change the name of the file or its 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 Just change the constant WP_DEBUG_LOG like this:

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

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

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

The only thing left to do is to check the debug file.log to confirm what is the cause of the problem. Then, we can fix the problem by correcting the code or removing the extension. But for a non expert, it’s still easier said than done.

If the debug.log file does not exist, is empty, or contains no recent errors, chances are that the problem is caused by the configuration of your web server.

Generally speaking, the majority of web hosting uses Apache as a web server. Apache uses an .htaccess file that contains certain rules that are needed for your site to function properly. Many extensions can modify this file and it is possible that one of them has corrupted .htaccess while trying to insert changes.

The most efficient way to validate everything is to check Apache logs. Unfortunately, the location of the file is different from one configuration 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 .htaccess-old file and create a new .htaccess file containing the bare minimum:

# BEGIN WordPress

RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]

# END WordPress

Afterwards, you can visit your site again and see if the problem still exists. Before making this change, be aware that security extensions such as iThemes Security, WordFence, All-in-One Security & Firewall, and several others (including caching extensions) frequently modify the .htaccess file. If you use such an extension, sometimes disabling and re-enabling the extension 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 extensions and reactivate them one by one” method is often suggested to identify the problem. However, blindly disabling everything and reactivating extensions 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 an extension causes a failure, it will be presumed to be the one to blame. However, it might be the combination of this extension with another component that causes the problem. This is why you have to be diligent and confirm using log files.


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

You can also ask your web host 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 like this on a daily basis and will do all that is necessary to restore your site as quickly as possible..

Similar Posts

Leave a Reply

Your email address will not be published.