The WordPress 500 internal server error is the catch-all failure message that tells you something went seriously wrong — without telling you what. Unlike errors with specific codes or messages, the WordPress 500 internal server error gives you a blank page or a generic critical error notice and nothing else to go on. I have tracked down and fixed this error more times than I can count across client sites, and the frustrating truth is that it can come from half a dozen different places. The good news is that those places are all predictable, the diagnostic steps are the same every time, and the WordPress 500 internal server error almost never involves data loss when you approach it correctly. This guide walks through every cause and every fix in the sequence that resolves it fastest. This fits into the wider topic we cover in our WordPress Errors Complete Guide.
What Actually Causes the WordPress 500 Internal Server Error
HTTP 500 is a server-side error code, meaning the server received the request but could not complete it due to an internal problem. When you see the WordPress 500 internal server error, the server encountered a condition it could not recover from — and rather than show you a specific error, it shows you nothing useful. The reason for the vagueness is that 500 errors can come from many different layers of the application stack, and the generic message is the server’s way of saying “something broke, and it’s not the browser’s fault.”
In WordPress specifically, the WordPress 500 internal server error clusters reliably around five main causes. A corrupted or malformed .htaccess file is the single most common trigger — WordPress uses .htaccess for permalink URL rewriting, and a syntax error or conflicting rule in that file causes Apache to reject every request with a 500. Plugin PHP fatal errors are the second most common cause: any plugin running code that throws an unhandled PHP fatal error brings down the entire WordPress execution process and produces the WordPress 500 internal server error for every page load. Theme problems — a syntax error in functions.php, a missing required PHP extension, or an incompatible template — work the same way.
PHP configuration limits are the fourth cause, and they are the trickiest because they produce the WordPress 500 internal server error silently — no memory exhausted message, just a blank server error — when a process exhausts its memory or execution time limit before WordPress can output anything. File permission problems round out the five: when PHP cannot read a required file due to incorrect permissions, the server cannot execute the request and the WordPress 500 internal server error results. The cause map matters because the fix sequence follows directly from it.
| Cause | Typical Trigger | Where to Look |
|---|---|---|
| Corrupted .htaccess | Plugin activation, manual edit | WordPress root directory |
| Plugin PHP fatal error | Plugin update, core update, new install | wp-content/plugins/ |
| Theme file error | Theme update, manual edit, child theme conflict | wp-content/themes/ |
| PHP memory/timeout | Traffic spike, heavy plugin, large import | wp-config.php, php.ini |
| File permissions | Hosting migration, manual chmod, malware cleanup | Server file permissions |
Fix 1 — Regenerate the .htaccess File
Start here because a corrupted .htaccess file is the single most common cause of the WordPress 500 internal server error, and the fix takes under two minutes. Connect to your server via FTP or your hosting file manager and navigate to the WordPress root — the same directory that contains wp-login.php. You should see a file named .htaccess there. If your file manager does not show it, check that hidden files are visible (most FTP clients show hidden files when you enable that option in settings).
Rename the existing .htaccess to .htaccess_old. This does not delete it — you can restore it if needed. Reload your site. If the WordPress 500 internal server error clears, the .htaccess file was the problem. Now regenerate a clean one: log in to the WordPress admin panel (which should now load), go to Settings → Permalinks, and click Save Changes without changing anything. WordPress writes a fresh, correct .htaccess file automatically. Delete the .htaccess_old file once you have confirmed the site is working.
If you had custom rules in the old .htaccess — from a security plugin, a caching plugin, or manual additions — add them back one section at a time after the fresh file is in place, reloading after each addition to identify which rule was causing the WordPress 500 internal server error. This is faster than trying to debug the original file character by character, and it guarantees a clean starting point.
Fix 2 — Deactivate Plugins to Isolate the Error Source
If regenerating .htaccess did not resolve the WordPress 500 internal server error, a plugin PHP error is the next most likely cause. Plugins run code on every page load, and a single plugin with a fatal error in its code — triggered by an incompatibility with another plugin, a WordPress core update, or a bug introduced by the plugin’s own update — can bring down the entire site and produce the WordPress 500 internal server error across every URL.
Since the WordPress admin panel may also be affected by the WordPress 500 internal server error, plugin deactivation usually needs to happen via FTP. Connect to your server and navigate to wp-content/plugins/. Rename the entire plugins folder to plugins_disabled. Reload your site — if the WordPress 500 internal server error clears, a plugin is responsible. Rename the folder back to plugins, then rename individual plugin subdirectories one at a time, reloading after each, until the error reappears. The plugin folder whose renaming triggers the WordPress 500 internal server error again belongs to the culprit plugin.
Once identified, check whether the plugin has a recent update that addresses the error, or whether an alternative plugin provides the same functionality without the conflict. Do not simply leave the plugin deactivated without addressing the underlying issue — if it was active for a reason, that function needs to be covered some other way. Contact the plugin developer’s support with the specific error from your server error log (covered below) and they will typically have a fix or workaround.
Fix 3 — Switch Themes to Rule Out Theme Errors
Theme files are executed on every front-end page load, and errors in theme code produce the WordPress 500 internal server error just as reliably as plugin errors do. A manual edit to functions.php with a syntax mistake, a theme update that introduced a bug, or a child theme that calls parent theme functions in an incompatible way can all result in the same blank 500 error page. Theme-caused WordPress 500 internal server errors are particularly common immediately after theme updates or after a WordPress core update that changed an API the theme depended on.
To test whether a theme is responsible, connect via FTP and navigate to wp-content/themes/. Rename your active theme’s folder — for example from mytheme to mytheme_off. WordPress automatically falls back to its bundled default theme (Twenty Twenty-Four or similar) when the active theme cannot be found. Reload your site. If the WordPress 500 internal server error disappears, your theme contains the problem.
At this point you have two options: restore a previous version of the theme from a backup (if you made edits that introduced the error), or download a fresh copy of the theme from its source and re-upload it. If you recently edited any theme file manually, compare your edited version against the original using a diff tool — the syntax error causing the WordPress 500 internal server error is usually visible immediately when you see the two files side by side. For child themes, temporarily deactivating the child theme and loading the parent theme alone confirms whether the child theme code or the parent theme is responsible.
Fix 4 — Check Your Error Logs and PHP Configuration
If plugin and theme deactivation have not cleared the WordPress 500 internal server error, reading the server error log is the next step — and arguably should have been the first step if you had immediate access to it. The error log contains the exact PHP error or server configuration message that produced the WordPress 500 internal server error, which eliminates all the guesswork of the systematic deactivation approach.
Access error logs through cPanel → Errors, or navigate to public_html/error_log via FTP — most shared hosting plans write PHP errors there. The log entry for a WordPress 500 internal server error will typically contain the timestamp of the error, the error type (Fatal error, Parse error, etc.), and the exact file and line number where the error occurred. This immediately tells you whether a plugin, a theme file, or a core file is responsible, without the need to deactivate things systematically.
PHP configuration limits are one category of WordPress 500 internal server error that the error log identifies but that looks different from a PHP fatal error. A memory exhaustion that happens before any output is written to the browser produces the 500 error silently — the log shows a memory limit message while the browser shows a blank page. Increase the memory limit in wp-config.php by adding define( 'WP_MEMORY_LIMIT', '256M' ); and test again. Similarly, if the log shows a timeout, increase max_execution_time via php.ini or by adding set_time_limit(300); to wp-config.php.
Fix 5 — Check File Permissions and Replace Core Files
File permissions that prevent PHP from reading WordPress files are an uncommon but real cause of the WordPress 500 internal server error, particularly after hosting migrations, manual file operations, or malware cleanup procedures that changed permissions incorrectly. WordPress files should generally be set to 644 permissions and WordPress directories to 755. Permissions set to 777 (fully open) or to values that PHP cannot read (like 600 on directories) both produce the WordPress 500 internal server error in different ways.
Check permissions through FTP — most FTP clients show permissions in the file listing and allow you to right-click and change them. In cPanel, the File Manager shows and allows editing permissions for each file and directory. The most important permissions to verify are the WordPress root directory (755), wp-content/ (755), wp-content/uploads/ (755), and all .php files (644). Incorrect permissions on any of these can contribute to or directly cause the WordPress 500 internal server error.
Replacing core WordPress files is the final check for persistent cases of the WordPress 500 internal server error where no other cause has been found. Download a fresh copy of WordPress from wordpress.org matching your current version, extract the archive, and upload the wp-admin and wp-includes directories to your server, overwriting the existing versions. Do not touch wp-content, wp-config.php, or .htaccess. Corrupted or incomplete core files from a failed update occasionally produce the WordPress 500 internal server error in ways that are otherwise invisible, and a clean core reinstall eliminates that possibility definitively.
Our guide on fixing the WordPress white screen of death covers the closely related blank-page error that often appears alongside the WordPress 500 internal server error and shares several of the same root causes and fixes. Our guide on how to enable WordPress debug mode safely explains the full debug configuration that turns silent 500 errors into readable PHP error messages — the single most useful tool for diagnosing any WordPress 500 internal server error that the systematic fixes above have not resolved. The WordPress support forums archive thousands of reported cases of the WordPress 500 internal server error with host-specific and plugin-specific solutions that cover edge cases not addressed in any general guide. See also WordPress Post Not Saving for a related case.
