Diagnose a WordPress 500 Error Without Guessing at Plugins

A 500 response says the server failed, not why. The same browser page can be produced by Apache or Nginx configuration, PHP-FPM, WordPress bootstrap, a plugin, or a malformed rewrite file. Treating all 500s as plugin conflicts wastes the best evidence.

The reliable route is not the longest checklist; establish the failing boundary, keep one clean reproduction, and change one layer at a time until the evidence lets you use response scope, server logs, rewrite rules, and a controlled isolation sequence to find the layer returning HTTP 500.

Read the failure at the right layer

• A malformed .htaccess or server directive prevents the request from reaching WordPress.
• PHP terminates with a fatal error, resource limit, or unreadable file.
• A security or cache layer converts an upstream error into a generic 500 response.

The branches are ordered to protect the strongest evidence around this possibility: a malformed `.htaccess` or server directive prevents the request from reaching WordPress. The observed scope and logs—not a familiar-looking error screen—decide which one applies.

Runtime incidents cross several boundaries: the browser reports an HTTP result, the web server hands work to PHP, and WordPress then loads core, plugins, the theme, and data; evidence from the earliest failing boundary is more useful than the component visible on screen; in this guide, the practical goal is to use response scope, server logs, rewrite rules, and a controlled isolation sequence to find the layer returning HTTP 500.

Build a clean diagnostic record

1. Run curl -I https://example.com/affected-path/ and compare the home page, a static file, wp-login.php, and the failing route.
2. Match the response timestamp with the web-server and PHP logs; note which process wrote the error.
3. Temporarily test standard rewrite rules on staging, preserving the original file as evidence.
4. Use wp core verify-checksums and inspect the first application frame in any PHP stack trace.

The sequence moves from observation toward intervention. Preserve the result of the final check—use wp core verify-checksums and inspect the first application frame in any PHP stack trace—because it provides a useful comparison after the repair.

curl -sS -o /dev/null -D - https://example.com/robots.txt
curl -sS -o /dev/null -D - https://example.com/
curl -sS -o /dev/null -D - https://example.com/wp-login.php
curl -sS -o /dev/null -D - https://example.com/affected-path/

Repair the cause—not the message

1. Correct the failing directive or restore the last known-good configuration, then reload the web server only after its config test passes.
2. Isolate a named plugin or theme rather than deactivating unrelated components.
3. Repair ownership or permissions only on the file named by the log; avoid recursive 777 changes.

Before applying “Correct the failing directive or restore the last known-good configuration, then reload the web server only after its config test passes,” name its rollback point and the evidence that will count as success. Afterward, repeat the original request and specifically check whether you can confirm the affected URL returns the intended 2xx or 3xx status with curl -I; a changed symptom at that point is new evidence, not permission to make several more changes at once.

Verification checklist

• Confirm the affected URL returns the intended 2xx or 3xx status with curl -I.
• Review logs during a fresh request and verify no hidden warning becomes a later fatal.
• Test both logged-out and authenticated requests if caching differs by cookie.

One successful refresh is not closure. Keep the incident open until you can also review logs during a fresh request and verify no hidden warning becomes a later fatal, adjacent paths have not regressed, temporary diagnostics are gone, and another operator can explain what changed.

Prepare a useful escalation if the boundary is outside your control

A hosting escalation should include the UTC timestamp, affected URL, response status, request or trace ID when available, PHP version, WordPress version, and the first relevant log entry; redact cookies, passwords, tokens, database credentials, and personal data; include the result of this first observation: run curl -I https://example.com/affected-path/ and compare the home page, a static file, wp-login.php, and the failing route.

State what was tested, including the result of “Run `curl -I https://example.com/affected-path/` and compare the home page, a static file, wp-login.php, and the failing route,” and what changed between attempts; evidence tied to that observation is safer and more actionable than granting broad access or sending an unnecessary full database export.

Tempting moves to avoid

• A browser refresh is not evidence that the origin recovered; a CDN may serve an old response.
• Do not overwrite .htaccess before saving its custom rules.

Primary references

• WordPress common errors — official reference consulted for this guide.
• WordPress debugging — official reference consulted for this guide.

Editorial note: The scenario above illustrates how to approach “Correct the failing directive or restore the last known-good configuration, then reload the web server only after its config test passes”; it is a documented example, not a claim about a reader’s server, so verify the cited documentation, take the appropriate backup, and follow the real environment’s access and change-control rules.