A WordPress 500 internal server error means the server failed before it could return the requested page. Start with the hosting error log. It often identifies the failing plugin, theme, PHP file, memory limit, or server rule and can save you from disabling working components.
Before changing files or settings, create a backup or confirm that your host has a recent restore point. If the error appeared immediately after an update or configuration change, reverse that change first.
Check the server error log
Open the PHP or web-server error log in your hosting control panel and reload the affected page once. Check the newest entries for:
- A path inside
wp-content/plugins - A path inside
wp-content/themes Allowed memory size exhausted- A PHP parse or fatal error
- An
.htaccessor rewrite configuration error - Permission or ownership errors
When the log names a specific plugin, theme, or edited file, address that component before trying broader fixes. Do not enable public PHP error display on a live site because messages can reveal sensitive server information.
If your host does not provide logs, ask support for the error entries generated at the exact time and URL of the failure.
Test the .htaccess file on Apache servers
A damaged or unsupported .htaccess rule can cause every request to return HTTP 500. This file is used by Apache and compatible servers; an Nginx-only site will not normally use it.
Connect through SFTP or your hosting file manager, then find .htaccess in the same directory as wp-config.php.
- Download a backup of
.htaccess. - Rename it to
.htaccess-old. - Reload the site.
If the site works, sign in to WordPress and open Settings > Permalinks. Click Save Changes without changing the permalink structure. WordPress will attempt to create fresh rewrite rules, as described in its internal server error guidance.
Check the new file for custom security, caching, redirect, or hosting rules before copying any of them back. Restore them individually so you can identify the rule that triggers the error.
With WP-CLI, you can flush the current rewrite rules using:
wp rewrite flushUse this only when WordPress can load far enough for WP-CLI to initialize. A warning that the rewrite rules are empty can mean the site has no permalink structure configured; check Settings > Permalinks rather than forcing a new structure. The wp rewrite flush documentation also notes that writing a hard .htaccess flush may require elevated server permissions.
Disable plugins without wp-admin
If the error followed a plugin installation or update, deactivate that plugin first. When the cause is unclear, list the active plugins:
wp plugin list --status=activeThen deactivate them all temporarily:
wp plugin deactivate --allReload the failing page. If it works, reactivate plugins one at a time and test after each activation:
wp plugin activate plugin-slugThe error will usually return when the conflicting plugin is activated. Leave that plugin disabled, then check its vendor documentation or contact its support team before updating, replacing, or removing it. The official wp plugin deactivate command reference covers individual, bulk, and network-wide deactivation.
If WP-CLI is unavailable, use SFTP to rename wp-content/plugins to plugins-disabled. This disables standard plugins without deleting their files. Restore the directory name afterward and reactivate plugins individually.
Must-use plugins in wp-content/mu-plugins are not disabled by renaming the normal plugins directory. Ask the host or site developer to inspect them if the error continues.
Rule out the active theme
A fatal error in the active theme can also produce a 500 response. This is especially likely after editing functions.php, installing a theme update, or changing PHP versions.
If wp-admin works, temporarily activate a current default WordPress theme. If the dashboard is unavailable, use SFTP to rename the active theme’s directory under wp-content/themes.
WordPress can fall back only when another valid theme is installed. Confirm that a default theme exists before renaming the active one. Restore the original directory name to roll back the test.
If switching themes fixes the error, inspect the server log for the exact file and function involved. Do not edit the production theme blindly, particularly if an update would overwrite the change.
Act on PHP errors shown in the log
For an Allowed memory size exhausted error, ask your host whether the account has reached its PHP memory limit. Raising a WordPress setting cannot override a lower server-level limit.
For parse errors or uncaught fatal errors, the log should identify a file and approximate line number. Restore a clean copy of that file or undo the recent edit. A higher memory limit will not repair broken PHP syntax.
WordPress debugging can write errors to wp-content/debug.log, but it requires editing wp-config.php. Follow the official WordPress debugging instructions and keep on-screen error display disabled on production:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );Remove these settings or set WP_DEBUG back to false after collecting the error. Debug logs can contain paths, query details, or other information that should not remain publicly accessible.
Replace damaged WordPress core files last
If logs do not point to a plugin or theme, and the problem started during an interrupted WordPress update, core files may be incomplete.
Download a fresh copy of the same WordPress release and replace only the wp-admin and wp-includes directories. Do not replace wp-content or wp-config.php. Back up the existing files first, and avoid mixing files from different WordPress versions.
If the site still returns HTTP 500 after these checks, send your host the failing URL, the time of the latest request, and the corresponding log entry. The remaining cause is likely at the PHP-FPM, web-server, filesystem ownership, security-rule, or account-resource level and may not be changeable from WordPress.