How to Fix the 500 Internal Server Error in WordPress

A 500 internal server error means the server ran into a problem while building your page and stopped without saying what went wrong. On a WordPress site, the usual causes are a damaged .htaccess file, a plugin or theme that crashes PHP, a PHP memory or time limit, the PHP version, or file permissions. The server's error log names the real cause, and the steps below work through the likely ones in order.

The error itself does not mean your content is gone. Change one thing at a time so you know what fixed it, and take a backup first if your host's backup tool still works.

What does a 500 internal server error mean?

It means the server hit "an unexpected condition" that stopped it from completing the request, in the words of the HTTP standard, and nothing more. The details go to the server's error log. You may see:

• A plain "Internal Server Error" page from the web server, which points to its settings (often .htaccess) or to PHP failing to start.
• A blank page, or your browser's own error page with the code 500, usually meaning PHP stopped before WordPress could show a message.
• "There has been a critical error on this website." WordPress shows this when PHP code crashes, and sends it with the same 500 status code.

What should you check first?

• Is it your host? Check your host's status page and your email. If every site on your account fails at once, the server is the likely cause.
• Where does it happen? Every page points to .htaccess, a plugin or theme that loads everywhere, or the server. Only the dashboard or one page points to a plugin that runs there.
• What changed? An update, a new plugin, a PHP version change, a site move, or an edit to .htaccess or wp-config.php. Undo the most recent change first.
• Check the admin inbox for a WordPress email titled "Your Site is Experiencing a Technical Issue" (see fix 2).

How do you fix a 500 error in WordPress?

Work through these in order: WordPress's documentation calls the first the most likely cause. If you can already open your error log (fix 6), read it first.

1. Replace a damaged .htaccess file

The .htaccess file holds settings for Apache and LiteSpeed web servers, including your permalink rules, and one bad line can cause a 500 error. Nginx servers do not use .htaccess, so skip this fix on Nginx.

• Using SFTP or your host's file manager, open your site's main folder (the one containing wp-admin) and show hidden files.
• Rename .htaccess to .htaccess_old, then reload your site.
• If the site loads, go to Settings > Permalinks and click Save Changes, and WordPress writes a fresh file (or, if it cannot, shows the rules to paste in yourself).

For a standard site at the root of its domain, WordPress's documentation gives the default section as:

# 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

Keep the old file: it may hold redirects or rules from caching and security plugins. Add those back one section at a time, reloading after each. Watch for lines starting with php_value or php_flag, which work on some server setups and cause exactly this error on others.

2. Find a plugin or theme that crashes PHP

Since WordPress 5.2, when a plugin or theme crashes the dashboard or login page, WordPress emails the admin address, naming the culprit, with a recovery mode link. The link (valid for one day by default) opens your dashboard with it paused, so you can deactivate or update it.

With no email and no dashboard, turn plugins off from the file side:

• In the wp-content folder, rename plugins to plugins.hold. Every plugin is deactivated.
• If the site returns, log in and open the Plugins screen, then rename the folder back (the plugins stay deactivated) and reactivate them one at a time. The one that brings the error back is the cause.
• To test a single suspect, such as the plugin you just updated, rename only its folder (adding "-old" works).

If plugins are not the cause, rename your active theme's folder in wp-content/themes. Its code stops running, and on Appearance > Themes, WordPress switches to a default theme if one is installed. If an update started the trouble, our guide to WordPress update disasters covers recovering safely.

3. Raise PHP's memory and time limits

PHP gives each request a set amount of memory and time, and a request that runs out stops with a fatal error. The log shows "Allowed memory size of ... bytes exhausted" or "Maximum execution time of 30 seconds exceeded."

WordPress asks PHP for at least 40MB of memory on a normal site and 256MB in the dashboard, but it only ever raises your host's limit. To ask for more, add this line to wp-config.php, above the line that says "That's all, stop editing!": define( 'WP_MEMORY_LIMIT', '256M' );

That works only if your host allows it. If not, raise memory_limit in your control panel's PHP settings (in cPanel, the MultiPHP INI Editor) or ask your host. If the site keeps needing more, find the plugin responsible: WordPress's documentation warns that a bigger limit can hide the real problem.

PHP's default time limit is 30 seconds, and hosts set their own. Raise max_execution_time in the same PHP settings or ask your host, rather than adding php_value lines to .htaccess.

4. Check the PHP version

Hosts retire old PHP versions, and an older plugin or theme may contain code a newer version rejects. The mismatch can run the other way too: WordPress 7.0 and later need PHP 7.4 or newer, and on anything older WordPress stops with a 500 and a message beginning "Your server is running PHP version".

Find your version under Tools > Site Health, on the Info tab, or in your control panel (in cPanel, the MultiPHP Manager). If the error began when the version changed, switch back (or ask your host to), then update or replace the plugin or theme that failed and test the newer version on a staging copy of your site. WordPress.org recommends PHP 8.3 or greater.

5. Correct file and folder permissions

WordPress's documentation recommends 755 or 750 for folders and 644 or 640 for files, with wp-config.php at 440 or 400, and never 777. Too strict, and the server cannot read a file it needs. Too loose, and some servers that run PHP under your account refuse to run the files and return a 500 instead. If many are wrong, ask your host to reset permissions and ownership for the whole site.

6. Read the server's error log

The error log usually names the file and line that failed. Where it lives depends on your host:

• On cPanel, Metrics > Errors shows up to the 300 most recent web server errors, and many cPanel hosts also write PHP errors to files named error_log in the folder where the failing script ran.
• Managed WordPress hosts often have a log viewer: in MyKinsta, for example, each site's Logs tab.
• Anywhere else, ask your host.

Read the entries from the moment the page failed. A path through wp-content/plugins/ names the plugin's folder (fix 2), a memory or execution time message to fix 3, and a line naming .htaccess to fix 1.

If that log says nothing useful, WordPress can keep its own: WP_DEBUG and WP_DEBUG_LOG in wp-config.php write errors to wp-content/debug.log, as our guide to the WordPress white screen of death explains. Turn them off and delete the file afterwards, because anyone may be able to read it.

7. Know when your host must look

As a last step, WordPress's documentation suggests re-uploading the wp-admin and wp-includes folders from a fresh download of the same WordPress version, which replaces damaged core files without touching wp-content.

Beyond that, the cause may be outside WordPress: the server's configuration, the way PHP runs, your account's resource limits or file ownership. Ask your host to look if the error continues with plugins off, a default theme and a fresh .htaccess file, or if every site on the account is down. Tell them when it started, which pages fail and what you have tried.

When should you get professional help?

If the error is costing you orders or you would rather not edit server files, hand it over. WP Resolve's Emergency Fix is a flat $199 with a 24-hour turnaround, and no plan is needed.

How do you stop a 500 error from coming back?

You cannot prevent every server fault, but these habits make the next one shorter:

• Keep daily off-site backups and know how to restore them.
• Update one plugin at a time, testing on a staging copy first.
• Use uptime monitoring, so you hear about an outage before customers do.
• Plan PHP upgrades rather than waiting for your host to retire your version.

WP Resolve's care plans cover most of this. Essential Care, at $79 a month, includes weekly core, theme and plugin updates with visual checks, daily off-site backups kept 30 days and uptime monitoring, and Business Care ($149 a month) adds updates tested on a staging copy first.

Not sure where your site stands? Ask for a free site health check covering updates, backups, security and speed, or text (916) 209-0917.

Frequently asked questions