WordPress 500 Internal Server Error: How to Fix It (Step by Step)

You load your site and get a plain white page with one line on it: “500 Internal Server Error.” No menu, no logo, no hint of what broke. The WordPress 500 internal server error is one of the vaguest errors on the web, because it only tells you that the server failed, not why.

The good news: the cause is almost always one of five things, and you can check all of them without being a developer. This guide walks through what the error actually means, the order to check things in, and how to stop it from coming back.

What Does a 500 Internal Server Error Mean in WordPress?

A 500 Internal Server Error in WordPress means the web server hit a problem it couldn’t handle and gave up before it could send your page. It is a generic “something broke on the server side” response, not a specific diagnosis. The real cause is almost always written in the server error log, not on the screen.

The HTTP 500 status code belongs to the 5xx family, which means the problem is on the server, not in the visitor’s browser. Clearing the browser cache or switching browsers won’t fix a real 500 error. Something in the WordPress files, the server configuration, or the PHP environment is failing on every request.

That matters at scale. According to W3Techs, WordPress runs 40.2% of all websites as of September 2026, so the same handful of causes shows up across millions of sites running on very different hosting setups.

500 Error vs Critical Error vs White Screen: What’s the Difference?

A WordPress 500 error, the “There has been a critical error” message, and the white screen of death are three versions of the same underlying failure: a PHP or server error that stops the page from loading. The difference is how far WordPress got before it broke, and that tells you where to look first.

Since WordPress 5.2, most plugin and theme crashes show the critical error message instead of a raw 500 page. So if you’re seeing the server’s own 500 page, the failure often happened before WordPress could catch it. If you’re seeing the critical error message instead, the WordPress critical error fix guide is the better starting point. A blank page with nothing at all is covered in the white screen of death guide.

Why Is My WordPress Site Showing a 500 Error?

A WordPress site usually shows a 500 error because of a corrupted .htaccess file, a faulty plugin or theme, an exhausted PHP memory limit, wrong file permissions, or a PHP version mismatch. The corrupted .htaccess file and a bad plugin update are the two most common causes by a wide margin.

Here is what each cause looks like in practice:

• Corrupted .htaccess: a security, caching, or redirect plugin writes a broken rule into .htaccess, and Apache refuses to process any request.
• Plugin or theme conflict: an update ships code that crashes on your PHP version or clashes with another plugin.
• PHP memory limit: a heavy page builder, WooCommerce, or an import job needs more memory than the server allows.
• File permissions: after a migration or manual upload, folders or files end up with permissions the server won’t execute.
• PHP version change: the host upgrades PHP and an old plugin or theme uses functions that no longer exist.

Timing is the biggest clue. If the 500 error appeared right after an update, a plugin install, a migration, or a hosting change, start with whatever changed.

How to Fix the WordPress 500 Internal Server Error (Step by Step)

To fix a WordPress 500 internal server error, check the server error log first, then reset .htaccess, deactivate plugins, switch to a default theme, raise the PHP memory limit, and fix file permissions, in that order. Most sites come back somewhere in the first three steps. You’ll need access to your hosting file manager or an FTP/SFTP client, since wp-admin is usually down too.

Before touching anything, take a backup if your host offers one-click snapshots. Every step below is reversible, but a backup costs you thirty seconds and removes all the risk.

Step 1: Read the Server Error Log

The server error log is the single fastest way to fix a 500 error, because it names the exact file and line that failed. In cPanel, open “Errors” or “Metrics > Errors.” On most managed WordPress hosts, the log sits in the hosting dashboard under Logs. Look for lines marked “PHP Fatal error” or “.htaccess: Invalid command.”

If the host log is empty or hard to reach, turn on WordPress’s own debug log by adding these lines to wp-config.php, just above the line that says “That’s all, stop editing”:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Reload the broken page, then open /wp-content/debug.log. If the log names a plugin folder, skip straight to Step 3 and deal with that plugin. Turn WP_DEBUG back off once the site is fixed.

Step 2: Reset the .htaccess File

A corrupted .htaccess file is the most common cause of a raw WordPress 500 error on Apache and LiteSpeed servers. In the site’s root folder (the one containing wp-config.php), rename .htaccess to .htaccess_old. If the site loads, .htaccess was the problem.

Now create a fresh .htaccess file with the default WordPress rules:

# BEGIN WordPress
<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

Or log in to wp-admin and go to Settings > Permalinks, then click Save Changes without changing anything. WordPress will regenerate the file. If you had custom rules in the old file (redirects, security headers, caching rules), copy them back one block at a time and reload after each one, so you can see exactly which rule breaks things.

Nginx servers don’t use .htaccess at all. If your host runs Nginx, skip this step.

Step 3: Deactivate All Plugins

Deactivating every plugin at once tells you in one move whether a plugin is causing the 500 error. Go to /wp-content/ and rename the plugins folder to plugins_off. WordPress can’t find any plugins, so it deactivates them all.

If the site loads, rename the folder back to plugins, then reactivate plugins one at a time from wp-admin until the error returns. The last one you activated is the culprit. If you have SSH access, WP-CLI does the same thing faster:

wp plugin deactivate --all
wp plugin activate plugin-name

For a more detailed walkthrough, including how to test without taking the live site down, see how to find which WordPress plugin is causing a problem.

Step 4: Switch to a Default Theme

If plugins aren’t the cause, the active theme might be. In /wp-content/themes/, rename your active theme’s folder. WordPress will fall back to a default theme like Twenty Twenty-Five, provided one is installed. If the site loads, the theme (or its functions.php file) is the problem.

A common trigger here is a snippet pasted into functions.php with a missing semicolon or bracket. One typo in that file is enough to take down every page.

Step 5: Increase the PHP Memory Limit

When a WordPress 500 error only appears on heavy pages (the Elementor editor, WooCommerce checkout, a big import), the PHP memory limit is a likely cause. The error log will usually say “Allowed memory size of X bytes exhausted.” Add this line to wp-config.php:

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

This only works up to the ceiling your host sets in PHP. If 256M doesn’t stick, raise memory_limit in php.ini, .user.ini, or your hosting panel’s PHP settings. The same PHP settings screens are covered in the guide on increasing the WordPress max upload size.

One strong opinion here: raising memory is a bandage, not a cure. If a site needs 512M to render a normal page, something is leaking or bloated, and it’s worth finding the plugin responsible instead of feeding it more RAM forever.

Step 6: Fix File Permissions

Wrong file permissions cause 500 errors because many servers refuse to run PHP files that are writable by everyone. WordPress’s own hardening documentation recommends 755 for folders and 644 for files. You can set these in your file manager, or over SSH from the WordPress root folder:

find . -type d -exec chmod 755 {} +
find . -type f -exec chmod 644 {} +

Permission problems show up most often right after a migration or a manual upload through FTP, when an FTP client applies its own defaults.

Step 7: Check the PHP Version

A sudden 500 error with no updates on your side often means the host changed the PHP version. Old plugins and themes that call removed PHP functions crash instantly on newer PHP. In your hosting panel, check which PHP version the site is running. If it changed recently, temporarily switching back confirms the cause, then update or replace the outdated plugin or theme so you can move forward again.

Step 8: Re-upload WordPress Core Files

If nothing above works, core WordPress files may be damaged by a failed update or malware. Download a fresh copy of WordPress from WordPress.org and upload only the wp-admin and wp-includes folders, overwriting the existing ones. Don’t touch wp-content or wp-config.php. With WP-CLI, wp core verify-checksums will tell you exactly which core files have been modified.

When the 500 Error Is Your Host’s Problem

If you’ve worked through every step and the WordPress 500 error persists, the problem is likely on the server itself, and it’s time to contact your hosting provider. Server-side causes include a crashed PHP-FPM process, a misconfigured server module, hitting the account’s process or CPU limits, or a ModSecurity rule blocking requests.

When you open the ticket, include the exact time the error started, the URL that fails, and any lines from the error log. That turns a “my site is broken” ticket into one support can actually solve, and it usually gets a faster answer.

If the 500 errors come and go under traffic instead of staying constant, that’s usually a sign the site has outgrown its hosting plan rather than a code bug.

How to Prevent the WordPress 500 Error From Coming Back

The best way to prevent a WordPress 500 internal server error is to test updates on a staging site, keep automatic backups, and avoid editing .htaccess or functions.php directly on a live site. Most 500 errors are caused by a change, so controlling how changes reach the live site removes most of the risk.

• Use staging: run plugin, theme, and PHP updates on a WordPress staging site before pushing them live.
• Keep daily off-site backups: a backup stored on the same server doesn’t help when the server is the problem.
• Put custom code in a snippets plugin or child theme: not in the parent theme’s functions.php, where one typo takes down the site.
• Remove abandoned plugins: plugins that haven’t been updated in years are the ones most likely to break on a new PHP version.
• Set up uptime monitoring: a free monitor that emails you when the site returns a 500 means you find out before your customers do.

The Bottom Line

A WordPress 500 internal server error looks scary, but it’s rarely mysterious once you read the error log. Check the log, reset .htaccess, and isolate plugins before you try anything else. That order fixes the majority of cases in minutes. And if you’d rather have someone else handle it, take a look at my work and get in touch.

Frequently Asked Questions