How to Troubleshoot a WordPress 500 Internal Server Error

Before you change anything

A 500 Internal Server Error is an HTTP server response, not a diagnosis. Start by preserving the current state: confirm that a recent backup exists, note any deployment or configuration change that preceded the error, and use a staging copy when one is available.

Avoid changing plugins, PHP settings, rewrite rules and file permissions at the same time. That makes the actual cause harder to identify.

Start with the server error log

The fastest path is usually the PHP, web-server or hosting error log. Look for a fatal error or configuration failure at the same timestamp as the failed request.

Useful evidence includes:

• the PHP error type and file path;
• the plugin, theme or custom-code file involved;
• memory or execution-limit messages;
• rewrite or permission errors from the web server;
• failures introduced immediately after a deployment.

Enable WordPress logging when appropriate

WordPress provides WP_DEBUG, WP_DEBUG_LOG and WP_DEBUG_DISPLAY controls in wp-config.php. The official WordPress documentation recommends using the debug tools for development and staging rather than exposing debug output on a live site.

A common diagnostic configuration is:

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

With the standard configuration, logged WordPress errors can then be reviewed in the content directory’s debug.log. Disable temporary debugging settings after diagnosis when they are no longer needed.

Isolate application-level causes

If the error began after a code change, plugin update or theme deployment, test that change first. On a recoverable staging copy, isolate one variable at a time.

Plugins

Temporarily disable the suspected plugin or recent update and retest the failing request. If the site is inaccessible through the WordPress administration area, use the hosting control panel, file system or an appropriate command-line workflow instead of making unrelated database changes.

Theme or custom code

Check recent edits, child-theme code, snippets and deployment commits for PHP syntax errors or calls that are incompatible with the current environment.

Check PHP and web-server limits

If application code does not explain the failure, review the hosting stack. Common areas include PHP memory exhaustion, unavailable PHP extensions, invalid rewrite directives, incorrect file ownership or permissions, and server configuration that changed during a migration.

The exact checks depend on whether the site runs on Apache, NGINX, a managed WordPress platform, containers or another stack.

Confirm the fix and remove temporary diagnostics

After identifying the cause, reproduce the original request, verify the server log is clean, and test adjacent functionality such as forms, scheduled tasks, checkout or API requests when they share the affected code path.

Document the root cause and the change that resolved it. A useful troubleshooting record makes the next incident substantially faster to diagnose.