How to Fix the WordPress 500 Internal Server Error (Step by Step)

A WordPress site that suddenly returns HTTP 500 does not tell you what failed. The browser only knows the server could not complete the request. It could be a PHP fatal error, a plugin conflict, a broken rewrite rule, exhausted memory or a failure before WordPress even loads. The quickest fix is not to install another plugin. It is to identify the layer that failed and change one thing at a time.

Step 1: Confirm the error and its scope

Check the homepage, an individual article, wp-admin and a static image separately. If only one URL fails, look for route-specific plugin or template behavior. If every PHP page fails but static files load, PHP or WordPress startup is a stronger suspect. A 502 Bad Gateway or 503 Service Unavailable is not the same as a 500; proxy and application logs may point to different causes.

curl -sS -o /dev/null -w "HTTP %{http_code} | %{url_effective}\n" https://example.com/
curl -sS -o /dev/null -w "HTTP %{http_code} | %{url_effective}\n" https://example.com/wp-admin/
curl -sSI https://example.com/wp-content/uploads/sample.jpg | head -n 8

Replace the domain and sample image with your own. Some servers treat HEAD requests differently; a GET request is the deciding check if results disagree. Note exactly when the failure began: after a plugin update, PHP upgrade, deployment or change to server configuration.

Step 2: Read the server log first

A PHP fatal error usually leaves a precise message: missing function, memory exhaustion, unavailable class or syntax error. On managed hosting, inspect the PHP error log in the control panel. With SSH, the path depends on the PHP-FPM pool and web server. Do not assume an Apache error log contains everything on an Nginx installation.

sudo journalctl -u php8.3-fpm --since "15 minutes ago" --no-pager
# Adapt the service name to the PHP version actually installed.
# Alternatively inspect your host's PHP error log.

Focus on the first fatal error and its file path. A message pointing into wp-content/plugins identifies a candidate, not proof that the plugin itself is defective; another integration can call its API incorrectly. Capture the timestamp and the request that triggers the failure.

Step 3: Turn on WordPress debugging without exposing errors

If server logs do not show a useful stack trace, enable WordPress debug logging temporarily. Add or update these settings in wp-config.php before the line that says to stop editing. If a constant already exists, edit it rather than defining it twice. Never display raw stack traces to public visitors.

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

Reproduce the error once, then inspect wp-content/debug.log via SFTP or the shell. The log can contain paths, queries or personal information: keep it private, rotate it after troubleshooting and disable logging when finished. Ideally place diagnostic logs outside a publicly served directory. A host can disable WordPress logging or send PHP errors elsewhere, so absence of debug.log is not evidence that PHP is healthy.

tail -n 80 wp-content/debug.log
# Turn WP_DEBUG and WP_DEBUG_LOG off again after diagnosis.

Step 4: Isolate a failing plugin, one change at a time

If the admin interface works, deactivate the last changed plugin first. On a broken dashboard with SSH access, WP-CLI can list active plugins and disable a specific suspect without deleting its files. Always run WP-CLI as the application owner where possible, and supply --path if you are not in the WordPress installation directory.

wp plugin list --status=active --fields=name,status,version --format=table
wp plugin deactivate suspected-plugin-slug
# Retest the failing URL, then reactivate only if appropriate:
wp plugin activate suspected-plugin-slug

For a staging environment, you can deactivate all ordinary plugins temporarily and reactivate them one by one. Avoid doing this casually on production: it may disable checkout, login, forms and integrations. Must-use plugins are not disabled by the ordinary --all flag. If WP-CLI cannot bootstrap WordPress, temporarily renaming a specific plugin directory through SFTP can isolate it, provided you record the original name and understand the consequences.

Step 5: Check the active theme and PHP version

If plugin isolation makes no difference, test a default theme in staging. A theme can trigger PHP fatals through custom functions or dependencies. Confirm your deployed PHP version is compatible with the theme, WordPress core and plugins. Upgrading PHP is not automatically a fix: an incompatible extension can make the error worse. Compare the actual running PHP-FPM version with the CLI version, because they can differ.

wp theme list --fields=name,status,version --format=table
php -v
wp core version
# Stage only, if the theme is already installed:
wp theme activate twentytwentysix

Step 6: Repair rewrite rules only if the symptoms fit

A corrupted .htaccess file may produce an HTTP 500 on Apache or compatible setups, while Nginx generally does not read .htaccess. If logs mention rewrite directives or an Apache configuration error, back up the existing file, restore known-good rewrite rules and resave Settings → Permalinks. Do not paste random rewrite directives into production without understanding the host configuration.

cp .htaccess .htaccess.backup-before-fix
wp rewrite flush
# For Apache rewrite-file updates, review the rules and
# permissions before considering: wp rewrite flush --hard

If an unchanged site suddenly fails after a host migration, inspect file permissions, ownership and missing PHP extensions. Avoid blanket chmod 777 commands. They trade one incident for a security exposure and rarely solve the underlying cause.

Step 7: Validate recovery and remove temporary diagnostics

• Homepage and a previously failing article return successful responses.
• A logged-out user can navigate the site; the admin login works.
• Forms, scheduled tasks and commerce functions still run.
• PHP logs no longer show the same fatal during test traffic.
• Debug logging is disabled or access-restricted, and temporary plugin changes are documented.

If your site uses caching, purge only the relevant layers after verifying the application responds correctly. A stale cache can hide a fix or make a broken page appear healthy. Monitor errors for a short window after the change. For a repeatable deployment process with rollback evidence, see Zero-Downtime Deployment and CI/CD.

Frequently asked questions

Can a WordPress 500 error be fixed without wp-admin?

Yes. SFTP, hosting control panels, SSH, WP-CLI and server logs are often more useful than the dashboard. The safest method depends on where the error occurs. Do not delete plugins or rewrite database data just because wp-admin is unavailable.

Will increasing PHP memory fix HTTP 500?

For persistent errors, save the relevant log timestamps, installed plugin versions and last successful deployment SHA in an incident note. A reproducible failure report is easier to review than a list of random settings that were changed. Restore the earliest known-good revision only after confirming database compatibility; a rollback of code will not reverse an altered database schema or third-party payment state.

Only if memory exhaustion is the actual cause. A fatal log line mentioning allowed memory size is evidence. Raising memory while leaving an infinite loop or expensive query unfixed can postpone the same outage. Profile the expensive operation after stabilizing the site.

What should I read next?

The related WordPress security guide covers preventative controls. If your admin loads but remains painfully slow rather than returning HTTP 500, use the separate slow WordPress dashboard tutorial.