WordPress 500 internal server error: what it means and how to diagnose it

Your site was working. You made a change, or maybe you didn’t make any change at all, and now it isn’t. The browser shows a 500 internal server error, or a blank white screen, or just a generic “something went wrong.” No detail. No direction. The server hit a condition it couldn’t handle and stopped there.

The 500 error is the most deliberately unhelpful error in WordPress. It’s a catch-all: the server couldn’t complete the request, and it isn’t going to tell you why. What makes it fixable is that “something went wrong on the server” actually narrows down to 4 or 5 categories, and you can rule them out in order without reading code.

This is that sequence.

What a 500 internal server error actually means

The HTTP 500 status code means the web server encountered an unexpected condition before it could finish processing the request. It’s a server-side failure, not a browser problem, not a network problem, not your internet connection. The problem is somewhere between the server receiving your request and WordPress generating a response.

In practice, WordPress 500 errors almost always come from one of these causes: a corrupted .htaccess file, a plugin conflict or fatal PHP error, a PHP memory limit being hit, a corrupted theme file, or a misconfiguration introduced by a recent update. The error is vague because the server stops before WordPress can produce a more specific message. The diagnostic sequence below is designed to surface that specific message.

Before anything else: check the timing

When did the error start? If you can answer this, it narrows the cause immediately.

If it started right after you updated a plugin, a theme, or WordPress core, the update is the most likely cause. If it started without any obvious change on your part, the .htaccess file or a PHP memory limit is more likely. If it’s appearing only on specific pages and not others, that points to a page-level plugin conflict rather than a site-wide server failure.

Write down the timing before you start. It determines which step to try first.

Step 1: Regenerate the .htaccess file

A corrupted .htaccess file is the most common cause of 500 errors in WordPress, and fixing it takes about 30 seconds.

If you can still access your WordPress admin dashboard, go to Settings, then Permalinks, and click Save Changes without changing anything. WordPress will regenerate a clean .htaccess file automatically.

If you can’t access the dashboard because the error is blocking you, connect to your site via FTP or your host’s file manager. Find the .htaccess file in your root directory (the same folder as wp-config.php). Rename it to something like .htaccess_old. Then try loading your site. If it loads, your .htaccess file was the problem. Go to Settings, then Permalinks, and save to generate a fresh one.

Step 2: Deactivate your plugins

If the .htaccess fix didn’t resolve it, plugins are the next most common cause. A plugin that introduced a PHP fatal error will stop WordPress from loading entirely, which produces a 500 error with no further detail.

If you can access the dashboard, go to Plugins and deactivate everything. Then reload your site. If it loads, you know a plugin is the cause. Reactivate them one at a time, testing after each, until you find the one that triggers the error again.

If you can’t access the dashboard, connect via FTP or file manager. Navigate to wp-content and rename the plugins folder to something like plugins_disabled. This deactivates all plugins at once. If the site loads after that, rename the folder back to plugins and then go into the dashboard to reactivate plugins one at a time until you find the culprit.

Step 3: Enable the debug log to see the actual error

If deactivating plugins didn’t fix it, you need to see the real error. The debug log is how you do that without reading code.

Connect to your site via FTP or file manager and open wp-config.php. Find the line that says define( 'WP_DEBUG', false ); and change it to define( 'WP_DEBUG', true );. Add two lines directly below it:

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

Save the file and reload your site. WordPress will now write errors to a file called debug.log inside wp-content. Open that file. The error at the top is almost always the one that caused the 500. It will name a specific file, a line number, and a description of what failed.

You don’t need to understand PHP to use this information. Copy the error, the file name, and the line number. That’s what you hand to a developer or paste into your AI assistant. Enabling the WordPress debug log and reading what it surfaces is the fastest way out of a 500 error, because it replaces the vague server message with a specific cause.

When you’re done diagnosing, set WP_DEBUG back to false. You don’t want error output running on a live site.

Step 4: Check the PHP memory limit

If the debug log shows a “fatal error: allowed memory size exhausted” message, the fix is different from a plugin conflict. WordPress has hit its PHP memory ceiling and stopped.

Connect via FTP or file manager and open wp-config.php. Add this line before the comment that says “That’s all, stop editing”:

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

Save and reload. If the error clears, memory was the issue. If your hosting plan has a hard cap below 256M, you may need to contact your host or upgrade your plan to hold the increase.

Step 5: Switch to a default theme

If none of the above resolved it, a corrupted theme file is the remaining common cause. Connect via FTP or file manager, navigate to wp-content/themes, and rename your active theme’s folder. WordPress will fall back to a default theme. If your site loads, the theme introduced the fatal error and needs to be reinstalled or replaced.

What you’re doing when you work through this sequence

Every step in this list is ruling out one category of cause. The .htaccess check rules out server configuration. The plugin deactivation rules out PHP conflicts from third-party code. The debug log surfaces the actual failure message so you stop guessing. The memory limit check rules out resource exhaustion. The theme swap rules out corrupted theme files.

Most 500 errors resolve in steps 1 through 3. The debug log in step 3 is the most powerful tool in the sequence because it replaces the catch-all error message with something specific. Once you have a specific error, the problem has a name, and named problems are fixable.

If you’re working through a site where a lot of things have been behaving unexpectedly, not just the 500 error, it’s worth looking at what else the server was doing before this started. PHP errors in WordPress often accumulate quietly in the debug log before they escalate to a full 500. A 500 is usually the loudest moment in a failure pattern that started earlier and went undetected.

If you want to capture both browser-side and server-side evidence at once and get a plain-language explanation of what broke, Loupely does that in one click: it reads the PHP error log, the plugin hook execution, the REST API responses, and the browser console together, and tells you what to do next.

After you fix it: what to do before the next update

500 errors after updates are preventable. Before updating a plugin or WordPress core, make a full site backup. Then update one thing at a time and test after each. If you’re running WooCommerce or a page builder, treat those updates as high-risk and leave a testing window before you have active customers on the site.

The sites that recover from 500 errors fastest aren’t the ones with the fewest plugins. They’re the ones where someone knew what changed and when.