White screen. Five digits: 500. No admin panel, no site, no hint of the cause. Sound familiar?

The WordPress internal server error 500 is the most silent of all errors. It doesn't tell you what exactly broke, which only makes the panic worse. But reality is mundane: in 9 out of 10 cases the culprit is a plugin, a theme, or a single malformed line in .htaccess. The server hasn't gone crazy; it simply encountered code it cannot execute.

Let's break down the three main scenarios and fix each one step by step. No panic, no calling your host at three in the morning. With your own hands, in 15 minutes.

💡 Quick overview:

• Disable all plugins at once by renaming the plugins folder via FTP; if the error disappears, the culprit is among them
• Reset .htaccess to the standard WordPress template: a broken caching or redirect directive can instantly break your site
• Enable WP_DEBUG in wp-config.php to see the exact file and line with the fatal error
• If your site just moved to a new host, check the PHP version: WordPress as of 2026 requires PHP 8.3 or newer, and old plugins are often incompatible

HTTP response codes: what the server is trying to tell you

Before diving into debugging, it helps to understand the basics of HTTP responses. The server always replies to the browser with a three-digit code, and the first digit already tells you where to look for trouble.

• 1xx, informational: "connection is being established, please wait." These have nothing to do with errors.
• 2xx, success. The famous 200 OK means the server delivered the page without complaints.
• 3xx, redirects. For example, 301 (permanent redirect) or 307 (temporary). The browser navigates to the new address silently; this is a command, not an error.
• 4xx, client-side error. 404 Not Found means the page was deleted or the URL was mistyped. The server is alive; the content simply doesn't exist.
• 5xx, server-side error. This is where our territory begins.

Among 5xx codes, there are three main "patients": 503 Service Unavailable (the server is overloaded; fix with caching or upgrading to a more powerful plan), 502 Bad Gateway (PHP-FPM crashed or lost connection with the web server; a configuration problem), and finally **500 **Internal Server Error, the most generic and therefore the most treacherous. That's what we'll discuss.

Three main causes of error 500 and step-by-step fixes

Error 500 isn't mysterious; it's just generic. The server says: "I couldn't execute the code, but I won't tell you which." Diagnosis means methodically working through three standard suspects.

1. PHP version incompatibility when migrating a site

A classic scenario: you moved your site from an old host running PHP 7.4 to a new one with PHP 8.3 or 8.4. And immediately got a white screen.

The reason is simple: an old plugin or theme uses functions that have been deprecated or removed entirely in newer PHP versions. The interpreter refuses to execute them, and the site crashes.

How to fix. Make a full backup of the wp-content/plugins/ and wp-content/themes/ folders. Then rename the plugins folder to plugins_old via FTP or your hosting file manager; this instantly disables all plugins at once. Did the error disappear? The culprit is among the plugins. Restore them one by one, checking the site each time. The one after which the 500 error returns is the problem.

The same logic applies to themes: switch to a standard WordPress theme (Twenty Twenty-Five or newer). Did the site come back to life? The problem is in your theme; update or replace it.

This scenario most often appears when migrating a site between hosts with different PHP versions. Most hosts no longer offer PHP 7.x in their control panels, and WordPress minimum requirements since 2026 start at PHP 8.3. Old code without updates is doomed in that environment.

2. Corrupted.htaccess, the invisible killer

You configured a caching plugin, enabled redirects, or added your own rules to .htaccess, and the site went down. Instantly and without warning.

The .htaccess file (Apache) controls the web server on the fly: a directive is written, a directive is executed. One syntax error, incorrect flag, or rule conflict, and the entire site responds with a 500.

How to fix. Connect to your site via FTP or through your hosting file manager. Find .htaccess in the root folder (public_html, www, or htdocs). Copy its contents to a text file as a backup. Then replace everything with the standard WordPress template:

1
 # BEGIN WordPress
2
 
3
<IfModule mod_rewrite.c>
4
RewriteEngine On
5
RewriteBase /
6
RewriteRule ^index\.php$ - [L]
7
RewriteCond %{REQUEST_FILENAME} !-f
8
RewriteCond %{REQUEST_FILENAME} !-d
9
RewriteRule . /index.php [L]
10
</IfModule>
11
 
12
 # END WordPress

This code restores the standard URL rewrite rules (pretty permalinks) and removes everything extra. The site should come back to life immediately. You can reconfigure your plugin afterward, but now you know where to look if something goes wrong.

Didn't help? Restore the old .htaccess from your backup and move to the next step. On Nginx, .htaccess doesn't work; check the logs at /var/log/nginx/error.log, the problem is in the server block configuration.

3. Fatal error in PHP code

A plugin or theme calls a function that doesn't exist, passes the wrong argument type, or references a nonexistent class. PHP halts execution, and you're faced with that same 500.

Without debug information, you're guessing blindly. Fortunately, WordPress can display errors; you just need to enable debug mode.

Enabling WP_DEBUG

Open the wp-config.php file in your site's root. Find the line:

1
define( 'WP_DEBUG', false );

Replace false with true. If that line doesn't exist, add it before /* That's all, stop editing! */:

1
define( 'WP_DEBUG', true );

After saving, refresh the page. Instead of a white screen, you'll see a message like:

1
Fatal error: Call to undefined function wpsupercache_gc() in
2
/home/user/public_html/wp-content/plugins/wp-super-cache/wp-cache.php on line 342

The error shows: the type of problem (undefined function), the offending file (wp-cache.php), and the line (342). This is a direct pointer to the plugin that caused the crash. Disable it by renaming the plugin folder, and the site will work again. Then update the plugin, find a replacement, or contact the developer.

Be sure to set WP_DEBUG back to false after diagnosis. On a live site, displaying errors to visitors is unnecessary and can reveal internal server paths. If you want to collect logs without displaying them on screen, add these lines to wp-config.php: define( 'WP_DEBUG_LOG', true ); and define( 'WP_DEBUG_DISPLAY', false );. Errors will be written to wp-content/debug.log.

⁉️🤔 Frequently asked questions

Can I just restart the server to clear error 500?

No. Unlike 503, which often goes away after a restart (when peak load is relieved), error 500 is caused by a problem in the code. Restarting the server won't fix it: after startup, the site will hit the same broken code and crash again.

How do I determine whether a plugin or theme is at fault if the admin panel is inaccessible?

Connect via FTP or through your hosting file manager. Rename the wp-content/plugins folder; this instantly disables all plugins. Did the site come back to life? The problem is in the plugins. If not, rename the active theme folder in wp-content/themes. WordPress will automatically switch to the default theme. Did it come back to life? The problem is in the theme.

Do I have to enable WP_DEBUG on a live site?

No, on a working site WP_DEBUG should be disabled (false). Enable it only during diagnosis and turn it off immediately afterward. For ongoing error collection without showing them to visitors, use the combination of WP_DEBUG_LOG (writes to wp-content/debug.log) and WP_DEBUG_DISPLAY (disables screen output).

What if none of the three methods helped?

Check the PHP memory limit (memory_limit in php.ini). Sometimes scripts don't have enough allocated megabytes and crash with a 500. Increase it to 256M or 512M. If that doesn't help, contact your hosting support: ask them to check the server error logs (error_log for Apache/Nginx). The exact cause will be there, which you can't see from the WordPress side.

My site is on Nginx; what do I do with.htaccess?

Nginx doesn't use .htaccess. Rewrite rules are specified in the server block configuration (nginx.conf or sites-available/your-site). If you're on Nginx and got a 500, check the logs at /var/log/nginx/error.log. An incorrect .htaccess on an Nginx server doesn't cause problems; it's simply ignored.

How do I prevent error 500 in the future?

Three rules for prevention. First: update plugins, themes, and the WordPress core regularly (every month, not once a year). Second: don't cling to abandoned extensions; if a plugin hasn't been updated in over a year, look for a living replacement. Third: before installing any plugin, check the last update date and compatibility with your PHP version on the plugin page in the WordPress directory. Ten minutes of maintenance per month saves hours of emergency debugging.

What to do right now if your site is down with a 500

Error 500 is a puzzle with a predictable solution. In the vast majority of cases, you'll fix the site in fifteen minutes by going through three steps in the right order: disable plugins, reset .htaccess, enable WP_DEBUG. The order matters: from most likely and fastest to most detailed.

If you migrated the site to a new host, start with checking PHP. If you configured caching or redirects, start with .htaccess. If you updated plugins and the site crashed, start with WP_DEBUG. And if you didn't do anything yet a 500 appeared on its own, go through all three steps in sequence; one of them will almost certainly work.

Don't delay diagnosis: every minute of site downtime means lost visitors and search rankings. Open FTP, make a backup, and get started.