500 Internal server error WordPress.

500 Internal server error WordPress. In this post I’ll be talking about what causes a server 500 error, and how to address this when you’re using WordPress.

The main thing to bear in mind with a server 500 error is that this is an error generated by the web server itself, what this means in web server error language is:

The server encountered an unexpected condition that prevented it from fulfilling the request.

That’s nice and vague isn’t it? The purpose of this guide is to help you resolve this error, despite the vagueity of the error message that’s generated.

500 Internal server error, what you’ll see.

You’ll see a message that looks like this, when the server 500 error is in effect:

As I’ve mentioned above, what this means is that the web server has encountered an unexpected condition that prevented it from fulfilling the request.

This might not seem like it helps you work out what the cause is in any way, but it does tell you something:

That something unexpected is taking place!

When looking in to this issue, it’s possible that you won’t see any error logs in your hosting being written to that might help you identify the issue, even if you have debugging enabled in your WordPress.

This is because it’s the web server generating the error, not your WordPress. Although the error could be a product of what your WordPress is trying to serve as site pages, and what it’s doing to acheive that, it’s the web server that’s having the issue trying to serve your site.

You might have read the above and thought “problem with hosting, phone hosting provider” but it’s entirely possible that it’s not their issue, and it’s an issue with what’s in your hosting account.

If your WordPress is trying to do something that the web server effectively can’t this can cause a server 500 error.

It might seem a bit contradictory to say that a problem displayed by a web server can be caused by what you’re running in your hosting, and possibly your WordPress, but this can indeed be the case.

It will probably help to understand the chain of events when a page of your site is requested.

Understading the chain of events specific to serving your site.

When someone requests a page of your site, the chain of events to serve the site’s page is as follows:

Someone types the address of your website in to their browser’s address bar and presses return.
The request for the site is sent to the web server by the browser.
The request for the site reaches the web server.
The web server establishes the file location where your site exists (document root) by checking it’s configuration file (httpd.conf in the context of apache).
If an .htaccess file is found in the directory that your site is held in, the server processes the directives within this file.
The WordPress rewrite rules (these are defined in the .htaccess file) cause the index.php in the document root of your site to be called.
The index.php file starts calling other WordPress files to excute WordPress as a whole, although there are a lot of these the key files are:
- wp-load.php: This file is responsible for loading the core WordPress files and initialising essential functions.
- wp-config.php: WordPress configuration file is loaded, which contains settings such as database connection details and other configuration constants.
WordPress connects to the database (as defined in the wp-config.php file).
The main WordPress query is then executed to determine which content (post, page, category, etc.) is being requested based on the page that was requested by the browser.
Depending on the query results, WordPress determines which template files to load. This involves searching for theme files that match the template hierarchy (i.e. the them you’ve activated in your WordPress).
WordPress then loads the appropriate theme files, such as header.php, footer.php, and the specific template file for the requested content.
The content is rendered within the theme templates, and additional functionalities provided by plugins and themes may be applied.
The final HTML output is generated based on the loaded templates and content.
The generated HTML is sent back to the user’s web browser, which renders the page.

Problems with any of the above can cause a server 500 error. This is a bit of a list to work through, so let’s start at the top!

Syntax errors in .htaccess.

If the “language” in the .htaccess file isn’t correct, this could potentially cause a server 500 error.

To check if this is the case, your best course of action is to:

Rename the .htaccess file in the document root of your site to something like old.htaccess.
Create a new .htaccess file (in the document root of your site).
Add the WordPress rewrite rules (the bare minimum required for WordPress to run).
Save your changes.
Check your site

The WordPress rerwrite rules you’ll need when carrying out the above are as follows:

# BEGIN WordPress
# The directives (lines) between "BEGIN WordPress" and "END WordPress" are
# dynamically generated, and should only be modified via WordPress filters.
# Any changes to the directives between these markers will be overwritten.
<IfModule mod_rewrite.c>
	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]
</IfModule>
# END WordPress.

If you carry out the above, but are still seeing a server 500 error when acessing your site, it’s unlikely the server 500 error is being caused by the .htaccess file, so it would be a good idea to revert your changes (delete the .htaccess file, and then rename old.htaccess back to .htaccess). This is because there’s likely to be other things in the .htaccess file (such as directives added by caching and security plugins).

If you carry out the above and it does fix your site, you may need to resave the config of any plugins that have added directives to the .htaccess file (it’s primarily caching and security plugins that you’d need to action in this manner). This is because sometimes plugins need to have added things to the .htaccess file for them to be fully in effect on your site.

Syntax errors in index.php.

Unless you’ve undertaken some kind of config change such as operating your WordPress in a subdirectory, an out of the box, default, index.php file should contain this code:

<?php
/**
 * Front to the WordPress application. This file doesn't do anything, but loads
 * wp-blog-header.php which does and tells WordPress to load the theme.
 *
 * @package WordPress
 */

/**
 * Tells WordPress to load the WordPress theme and output it.
 *
 * @var bool
 */
define( 'WP_USE_THEMES', true );

/** Loads the WordPress Environment and Template */
require __DIR__ . '/wp-blog-header.php';

if your index.php file differs from the above, you could:

rename index.php to old.index.php.
Create a new index.php file.
Copy the code above in to the new index.php file.
Save your changes.

If the above does fix the server 500 error on your site, while that’s good, it’s definitely worth considering checking the contents of old.index.php against the new index.php file to see what’s different.

Generally speaking not much changes in the index.php file, so for this to change and it to cause an issue with your site, you might be looking at a bigger issue here, such as hacking, or something in your WordPress writign to index.php and causing the server 500 error. If it’s the latter, you’ll need to work out what this is and how to stop it doing that, otherwise the issue is likely to return.

Syntax errors in wp-load.php.

This one isn’t that common, but it’s worth checking for. Unless you’ve undertaken some kind of config change such as operating your WordPress in a subdirectory, an out of the box, default, wp-load.php file should contain this code:

<?php
/**
 * Bootstrap file for setting the ABSPATH constant
 * and loading the wp-config.php file. The wp-config.php
 * file will then load the wp-settings.php file, which
 * will then set up the WordPress environment.
 *
 * If the wp-config.php file is not found then an error
 * will be displayed asking the visitor to set up the
 * wp-config.php file.
 *
 * Will also search for wp-config.php in WordPress' parent
 * directory to allow the WordPress directory to remain
 * untouched.
 *
 * @package WordPress
 */

/** Define ABSPATH as this file's directory */
if ( ! defined( 'ABSPATH' ) ) {
	define( 'ABSPATH', __DIR__ . '/' );
}

/*
 * The error_reporting() function can be disabled in php.ini. On systems where that is the case,
 * it's best to add a dummy function to the wp-config.php file, but as this call to the function
 * is run prior to wp-config.php loading, it is wrapped in a function_exists() check.
 */
if ( function_exists( 'error_reporting' ) ) {
	/*
	 * Initialize error reporting to a known set of levels.
	 *
	 * This will be adapted in wp_debug_mode() located in wp-includes/load.php based on WP_DEBUG.
	 * @see https://www.php.net/manual/en/errorfunc.constants.php List of known error levels.
	 */
	error_reporting( E_CORE_ERROR | E_CORE_WARNING | E_COMPILE_ERROR | E_ERROR | E_WARNING | E_PARSE | E_USER_ERROR | E_USER_WARNING | E_RECOVERABLE_ERROR );
}

/*
 * If wp-config.php exists in the WordPress root, or if it exists in the root and wp-settings.php
 * doesn't, load wp-config.php. The secondary check for wp-settings.php has the added benefit
 * of avoiding cases where the current directory is a nested installation, e.g. / is WordPress(a)
 * and /blog/ is WordPress(b).
 *
 * If neither set of conditions is true, initiate loading the setup process.
 */
if ( file_exists( ABSPATH . 'wp-config.php' ) ) {

	/** The config file resides in ABSPATH */
	require_once ABSPATH . 'wp-config.php';

} elseif ( @file_exists( dirname( ABSPATH ) . '/wp-config.php' ) && ! @file_exists( dirname( ABSPATH ) . '/wp-settings.php' ) ) {

	/** The config file resides one level above ABSPATH but is not part of another installation */
	require_once dirname( ABSPATH ) . '/wp-config.php';

} else {

	// A config file doesn't exist.

	define( 'WPINC', 'wp-includes' );
	require_once ABSPATH . WPINC . '/version.php';
	require_once ABSPATH . WPINC . '/compat.php';
	require_once ABSPATH . WPINC . '/load.php';

	// Check for the required PHP version and for the MySQL extension or a database drop-in.
	wp_check_php_mysql_versions();

	// Standardize $_SERVER variables across setups.
	wp_fix_server_vars();

	define( 'WP_CONTENT_DIR', ABSPATH . 'wp-content' );
	require_once ABSPATH . WPINC . '/functions.php';

	$path = wp_guess_url() . '/wp-admin/setup-config.php';

	// Redirect to setup-config.php.
	if ( ! str_contains( $_SERVER['REQUEST_URI'], 'setup-config' ) ) {
		header( 'Location: ' . $path );
		exit;
	}

	wp_load_translations_early();

	// Die with an error message.
	$die = '<p>' . sprintf(
		/* translators: %s: wp-config.php */
		__( "There doesn't seem to be a %s file. It is needed before the installation can continue." ),
		'<code>wp-config.php</code>'
	) . '</p>';
	$die .= '<p>' . sprintf(
		/* translators: 1: Documentation URL, 2: wp-config.php */
		__( 'Need more help? <a href="%1$s">Read the support article on %2$s</a>.' ),
		__( 'https://wordpress.org/documentation/article/editing-wp-config-php/' ),
		'<code>wp-config.php</code>'
	) . '</p>';
	$die .= '<p>' . sprintf(
		/* translators: %s: wp-config.php */
		__( "You can create a %s file through a web interface, but this doesn't work for all server setups. The safest way is to manually create the file." ),
		'<code>wp-config.php</code>'
	) . '</p>';
	$die .= '<p><a href="' . $path . '" class="button button-large">' . __( 'Create a Configuration File' ) . '</a></p>';

	wp_die( $die, __( 'WordPress &rsaquo; Error' ) );
}

If your wp-load.php file differs from the above, you could:

rename wp-load.php to old.wp-load.php.
Create a new wp-load.php file.
Copy the code above in to the new wp-load.php file.
Save your changes.

If the above does fix the server 500 error on your site, while that’s good, it’s definitely worth considering checking the contents of old.wp-load.php against the new wp-load.php file to see what’s different. Again, you might be looking at a bigger issue here, such as hacking, or something in your WordPress writign to index.php and causing the server 500 error. If it’s the latter, you’ll need to work out what this is and how to stop it doing that, otherwise the issue is likely to return.

Issues with wp-config.php.

Generally speaking problems with this file are more likely to manifest themselves as “Error establishing database connection” and I’ve written a whole post covering this.

That said, the wp-config.php file does do more than just define how to connect to the database.

Unless you deleted it, there’s likely to be a wp-config-sample.php file in the document root of the domain. If you did delete this, download a copy of WordPress (preferably the same version you have installed, which you can find by looking at the contents of document_root/wp-includes/version.php) then extract it and upload the extracted wp-config-sample.php to the document root of your domain. Then:

Rename wp-config.php to old.wp-config.php.
Rename wp-config-sample.php to wp-config.php.
Update wp-config.php with the DB_NAME, DB_USER, DB_PASSWORD, DB_HOST and $table_prefix found in old.wp-config.php.
Save your changes.

What you effectively acheive by doing this is “resetting” the wp-config.php file back to it’s default, providing the details needed to connect to the site’s database in addition.

Again, if this does fix your issue, you have to question what it is that’s in old.wp-config.php that caused the issue in the first place, and you may need to take additional steps to prevent the issue occurring again in the future.

At this point you’ve covered syntax issues with some core files, so if you’re still experiencing a server 500 error, it’s being caused by something other than the contents of the files mentioned above.

At this point it’s worth considering the PHP environment itself. This would make sense considering WordPress runs PHP!

PHP related issues.

You’re chiefly looking at memory exhaustion or reachign resource limitations here.

There are usually 3 php directives that can cause a server 500 error if these directives are reached or exceeded. These are:

memory_limit (the amount of RAM PHP is allowed to use)
max_exection_time (the amount of time for which a PHP process can run)
max_input_vars (the maximum number of input variables that can be accepted by a single request)

These can usually be increased by a facility in your hosting or by updating a php.ini file (you may need to check this with your hosting provider).

If you’re using cPanel, there’s a “Multi PHP ini editor” you can use to increase these directives:

It’s just a case of incresing the variables in the “setting” column, then clicking apply.

If you increase the memory_limit setting, make sure you remember the M at the end of the number. This measn MB, and if you don’t put this, you’re setting bytes, not megabytes, and there’s 1048576 bytes in an megabyte, so without the M, you’r atually decreasing the memory_limit (by a factor of 1048576, which is A LOT).

File Permissions.

If the permissions of files and folders aren’t set correctly, this can cause a server 500 error.

All the folders within a WordPress installation should have 755 permissions, which are:

user: read, write, execute
group: read, execute
world: read, execute

All the files within a WordPress installation shoudl have 644 permissions, which are:

user: read, write
group: read
world: read

If you have shell access to your hosting, this is the quickest way of sorting this out. You’d SSH to your hosting, then run these commands (obviously you’d need to replace /path/to/wordpres with the actual path where your wordpress installation is held:

find /path/to/wordpress/ -type d -exec chmod 755 {} \;

This changes the permissions of all the folders in your WordPress to 755.

find /path/to/wordpress/ -type f -exec chmod 644 {} \;

This changes the permissions of all the files in your WordPress to 644.

If you don’t have shell access, you’ll need to access the file manager:

Browse to the document root of your domain, and select all the wp-something folders, then right click on them, and click on “change permissions”:

And then set the permissions to 755, then click “change permissions”:

Then select all the files in the document root of your site, right click on them, then click on “change permissions”:

Then set the permissions to 644, then click “change permissions”:

It’s possible that you may need to browse around the directory structure of your WordPress installation to check that all folders ahve 755 permissions and all files have 644 permissions. You can use the method above to correct any that aren’t set with these permissions.

If thing still aren’t working you MIGHT at this point be able to enable debugging in your WordPress and then examine the erorrs being logged and depending on the error that’s logged, take the required action.

A lot of fixes to errors logged after enabling debugging can be found on this post about addressing critical errors within WordPress.

You might find that you have to replace parts of your WordPress if you are still experiencing server 500 errors.

Replacing parts of your WordPress.

I’ve covered some of this in past posts:

So if, after doing all that, you’re still getting a server 500 error, you could well be looking at an issue with the codebase of the WordPress installation itself.

Issues with PHP code.

These generally fall in to two categories:

PHP Errors.

If there is a syntax error or a runtime error in the PHP code that is generating the HTML, it can lead to a 500 error. This could include issues with incorrect function calls, undefined variables, or other PHP-related errors.

Infinite Loops.

If there’s an infinite loop in the code that’s generating the HTML, it can lead to a situation where the server cannot complete the request, resulting in a 500 error.

In Reality.

In reality, you’re not going to be able to fix these (unless you’re capable of rewriting problematic PHP code) so you’re most likely looking at restoring a backup to get your site back online.

If you restore a backup from before your site started displaying a server 500 error, it’s likely to come back online.

You might well wonder why I didn’t mention that in the beginning, but there’s good reason!

By restoring a backup, you’re effectively getting rid of updates that might have caused the server 500 error. The problem is that you don’t want to leave your WordPress in a non-updated state, this is because a lot of updates become available to patch against vulnerabilites that could be exploited to hack your site.

That’s why I didn’t mention this in the first place. Not keeping your WordPress updated, is the number one cause of getting hacked, so you do need those updates, you just might have to wait for one to be released that doesn’t break your site.

If you do end up restoring a backup, you might need to turn off auto updates, wait a couple of days (until a new update that doesn’t break your site is released) then update.

Obviously you won’t know if an update that doesn’t break your site has been released, so you might find your site does another server 500 after updating, and you’ll then have to restore a backup to bring in back online again.

Once you’re able to update your site without it breaking again, you’d then need to turn auto updates back on.

In Conclusion.

The server 500 error when using WordPress is one of the harder issues to sort out.
The causes of a server 500 error can be varied.
The fix you’ll need to apply depends on what’s causing the error.
Understanding the chain of events involved with WordPress serving a page will help when addressing the server 500 issue.
Working through the key components involved with serving your site one by one is a good approach to take.
You may need to replace/reinstall parts of your WordPress to address the server 500 error.
You may even need to restore a backup to address the server 500 error, although there are implications to doing so.