Short answer: a 500 Internal Server Error means the web server or PHP failed while building the page and gave up. The visible message is deliberately generic; the specific cause is in the server or PHP error log. Generic “500 fix” checklists guess at what your log already names.
Scope and timestamp it first
Is every URL failing or just one? Does /wp-admin/ still load? Note when it started and what changed immediately before — an update, a deployment, a PHP version change, or a new server rule. Then take a snapshot before you change anything, including the broken state.
Read the log
Enable WP_DEBUG_LOG in wp-config.php (WP_DEBUG on, WP_DEBUG_DISPLAY off) and read /wp-content/debug.log, plus your host’s error log. A 500 usually resolves to one of: a PHP fatal error naming a file, exhausted memory, an execution timeout, or a rejected .htaccess directive.
The .htaccess test
On Apache, a corrupted rewrite file is a classic cause. Rename .htaccess to .htaccess_old over SFTP and reload. If the 500 clears, the file was the problem — but do not leave the site without rules: regenerate clean ones by going to Settings › Permalinks and clicking Save, which writes a fresh default .htaccess.
Then isolate plugins and theme
If it is not .htaccess, rename /wp-content/plugins to plugins_off; if the site returns, re-enable plugins one by one to find the culprit. If plugins are clear, rename the active theme’s folder to force a default theme. This is the same isolation sequence that resolves most application-level 500s.
Memory, timeouts and permissions
If the log points at memory, raise WP_MEMORY_LIMIT. If it is a timeout on a heavy operation — an import or backup — that task belongs on the command line, not a browser request. After a migration, a 500 can also be wrong file permissions: directories should generally be 755 and files 644, never 777.
Verify, and rule out compromise
Re-request the URL that returned the 500, then check the admin, a form and any scheduled job. If the log points at core files you do not recognise, or the 500 arrives with unexpected redirects, treat it as a possible hack rather than a configuration fault.
WP REPAIR INCIDENT STANDARD
How to narrow the fault without guessing
A 500 is an intentionally generic server response. The decisive evidence is the error emitted at the same timestamp by the web server, PHP or the application.
Record the exact URL, HTTP method and timestamp.
Read both the web-server and PHP logs before changing .htaccess or plugins.
Separate one-route failures from whole-site failures and logged-in from logged-out behaviour.
Treat unfamiliar modified core files or redirects as a possible compromise, not a configuration issue.
What must be verified
- The original request returns the expected status and body.
- Logs stay clean after repeating the triggering action.
- Business-critical paths and scheduled tasks still work.
Official technical sources
This guide explains the diagnosis. If the site is affected now, the intervention should preserve a rollback path and verify the real business journey.
See the emergency repair service →