Read the log, then fix one thing

500 Internal Server Error in WordPress: Read the Log First

Diagnose an HTTP 500 error on WordPress by reading the log rather than guessing at it. The generic server failure hides a specific cause: a corrupt .htaccess, a file permission the server refuses, an exhausted PHP memory limit, or a fatal error inside one plugin. Turn error output on first - the line number it prints ends the guesswork in seconds.

HTTP 500 is the server reporting that something failed without saying what. On WordPress the causes are a corrupt .htaccess file, a fatal PHP error in a plugin or theme, an exhausted memory limit, or file permissions the server refuses. The error log names which.

Is this what you are seeing?

Tick everything that matches. The result names the cause to start with.

Every page returns 500, including wp-admin
It began immediately after a plugin or theme update
It began after editing permalinks or a redirect rule
Only wp-admin fails and the front end is fine
It appears on one heavy page and nowhere else
It started after files were uploaded over FTP
It appeared after a host migration

Tick a symptom to narrow it down.

server error log line and htaccess permission check — Which symptom points at which cause: every page returns 500, including wp-admin points at corrupt htaccess; it began immediately after a plugin or theme update points at fatal PHP error; only wp-admin fails and the front end is fine points at exhausted memory limit.

What actually causes it

Cause	How to confirm	Typical fix
Corrupt htaccess	Rename the file; the 500 becomes a working site or a 404	5 min
Fatal PHP error	The error log names the file and the line	20 min
Exhausted memory limit	The log reports an allowed memory size being exhausted	15 min
Incorrect file permissions	Directories want 755 and files 644; anything group-writable is refused by some servers	15 min

A generic code with specific causes

HTTP 500 means the server hit something it was unable to handle and declined to explain further. The status code carries no diagnostic information at all, which is why the instinct is to start changing things.

Resist it. Two lines in wp-config.php turn the generic failure into a filename and a line number, and the fix is usually obvious from there. Every minute spent enabling logging saves several spent bisecting plugins.

Where PHP has not started yet

One distinction decides where to look. A fatal PHP error is recorded in the WordPress debug log; a failure in .htaccess or in file permissions happens before PHP runs at all, so WordPress records nothing.

An empty debug.log alongside a persistent 500 is therefore informative rather than unhelpful: it rules out the application and points at the server. Rename .htaccess, check permissions, then read the host error log.

A PHP fatal reaches the visitor in whatever form the server is configured to show. With error output off it arrives as a white screen of death; inside a mail hook it arrives as a contact form that silently stops sending. One fault, three symptoms, all on the WordPress error index.

How to fix it

Turn on error output before anything else. Set WP_DEBUG and WP_DEBUG_LOG to true in wp-config.php with WP_DEBUG_DISPLAY false, then reload. The log names the file and the line, which converts this from a guessing exercise into a two-minute fix.
Rename .htaccess and reload. A working site or a 404 both mean the file was the cause. Regenerate it by saving the permalink settings, which writes a clean copy.
Read the log and go straight to the named plugin. A fatal error names its file. Deactivate that plugin over SFTP by renaming its folder - wp-admin is usually unreachable at this point.
Raise the memory limit if the log says so. Add define('WP_MEMORY_LIMIT', '256M'); to wp-config.php. Where that changes nothing, the host caps it above WordPress and the limit has to be raised server-side.
Correct file permissions. 755 on directories, 644 on files, and 600 on wp-config.php. Uploads over FTP and copies from another host routinely arrive with permissions the new server refuses to execute.
Turn WP_DEBUG back off. Leaving it on writes paths and query detail into a log inside the web root, which is information nobody outside the site needs.

When that fix does not hold

Do not leave WP_DEBUG_DISPLAY on while the site is public. It prints file paths, database structure and plugin internals to every visitor, which is a gift to anyone probing the site. Log to a file instead, and switch it off once the cause is found.

Questions people ask before calling

Where is the WordPress error log?

At wp-content/debug.log once WP_DEBUG_LOG is enabled. The server keeps its own log too, usually reachable through the hosting control panel, and that one records failures happening before PHP starts.

How do I deactivate a plugin when wp-admin returns 500?

Rename its folder inside wp-content/plugins over SFTP. WordPress cannot find it, treats it as deactivated, and the admin becomes reachable again.

Why does only the admin area return 500?

Admin screens use considerably more memory than the front end, which is often served from a cache. A limit the front end never approaches gets hit on the first bulk action.

The log is empty and the site still returns 500.

Then the failure happens before PHP runs, which points at .htaccess, file permissions or the server itself. Check the host error log rather than WordPress.

More errors