WordPress 500 Internal Server Error: How to Fix It

A 500 internal server error is the web server’s way of saying something went wrong while refusing to say what. It is the most generic error on the web, which is exactly why it feels so frustrating: the page is blank, the status is 500, and nothing on screen tells you why. The good news is that on WordPress the list of real causes is short, and the fix is usually quick once you make the server tell you what actually broke. We clear these for agencies whenever a client site goes dark, and this is the order we work in. Back up the site first if you can.

What a 500 error actually is

A 500 is an HTTP status the server returns when it hits an error it cannot handle. Unlike a 404 (page not found) or WordPress’s own “there has been a critical error” message, a 500 can fire before WordPress even loads, for example when a bad rule in .htaccess stops the server cold. That is why it is so vague: the server caught the failure but did not put a friendly explanation where you can see it. The explanation is still recorded, in the server error log, which is the first place to look.

What causes it

• A corrupted .htaccess file (the single most common cause, often after a plugin, a security tool, or a migration rewrote it).
• A plugin or theme throwing a PHP fatal error.
• An exhausted PHP memory limit.
• Wrong file or folder permissions.

How to fix it

1. Read the real error first

Do not guess. Open your server’s error log (in your hosting panel under Logs, or read /wp-content/debug.log after turning on debug logging). To enable it, edit wp-config.php and replace define( 'WP_DEBUG', false ); with these lines:

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

Reload the broken page, then read the last lines of the log. They name the file and the cause, which turns the rest of this list into a single targeted fix instead of trial and error.

2. Regenerate the .htaccess file

This is the most common fix. Over FTP or your host’s file manager, find .htaccess in your site root, rename it to .htaccess_old, and reload the site. If the 500 clears, .htaccess was the culprit. Recreate a clean one from the dashboard: go to Settings > Permalinks and click Save Changes (no edits needed) to write a fresh file. The default WordPress .htaccess looks like this:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

3. Raise the PHP memory limit

If the log says “allowed memory size exhausted,” add this line to wp-config.php, just above the line that says “That’s all, stop editing”:

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

Some hosts cap memory at the server level, so if this does not take, ask your host to raise it.

4. Deactivate plugins and test the theme

If it is not .htaccess or memory, a plugin or theme is throwing a fatal error. Rename the /wp-content/plugins/ folder over FTP to deactivate everything at once; if the site returns, rename it back and re-enable plugins one at a time until the 500 comes back. Then switch to a default theme to rule the theme out.

5. Check file permissions

A botched migration can leave the wrong permissions behind. Folders should be 755 and files 644. Your host’s file manager can reset these in bulk, and the wrong values alone can trigger a 500.

It is one of the WordPress “site is down” errors

The 500 error sits in a small family of “the whole site is down” WordPress failures, each with its own signature. The critical error comes from WordPress’s own PHP handler, the white screen of death is the older silent version, and the database connection error means WordPress cannot reach its database. A 500 is the one that points hardest at the server and .htaccess. They are all worth knowing cold, and they sit alongside the other common WordPress problems. WordPress documents the debugging side in its debugging guide.

When to stop and get help

If the log points at a server-level limit, a core file, or an error that returns the moment you re-enable a plugin the client depends on, that is not the time to experiment on a live site. This is one of the errors our white-label WordPress team clears quietly under your brand, so your client sees a working site and never knows there was a fire.

Frequently asked questions

Still hitting a 500 error after all of this? Some causes sit at the server level, where a guess can make things worse. Send us the stuck site and we will triage it, find the real cause, and give you a fixed quote to get it back online.

Client site down with a 500 and you need it back fast? You can send us the details and we’ll get it online under your brand.