A 500 means your server broke and doesn't know why. The fix is always the same shape: open the error log (server, application, and CDN), find the stack trace from the moment of failure, and work backwards. The most common real causes are bad recent deploys,…
HTTP 500 Internal Server Error is the universal "something broke on our end" response. It is deliberately vague because the server hit a condition the application code didn't know how to handle: an unhandled exception, a database connection that timed out, a misconfigured config file, an out-of-memory crash, a syntax error in a recent deploy. Unlike 4xx errors (which point the finger at the client), 500 is the server admitting fault. It is the single most common server-side error on the web and almost always means "check the application logs immediately."
Critical SEO impact when persistent. Googlebot retries 500 responses (a brief spike of 500s during a deploy is forgiven), but pages that consistently return 500 for hours or days are deindexed. Worse, a sitewide 500 outage during a Googlebot crawl can cause Google to throttle crawl rate for weeks afterward as a protective measure. Users bouncing immediately from a 500 page also send a strong negative engagement signal. Set up uptime monitoring with sub-5-minute detection so a 500 outage doesn't silently last overnight.
LemWatch alerts within seconds when a monitored page starts returning 500. We track error frequency over time and surface patterns (always at 3am? during deploys? under load spikes?) so you can fix root causes instead of just restarting the server.
HTTP 500 has existed since the original HTTP/1.0 spec (RFC 1945, 1996) and is the most-cited server error in web infrastructure. It is the response that gave the term "Five Hundred Error" cultural weight — when AWS, Google, or Cloudflare have a major outage, the public-facing symptom is almost always a wave of 500s.
HTTP 500 Internal Server Error means the server encountered an unexpected condition it couldn't handle. It's the generic catch-all for any server-side failure — application bug, database error, config issue, out-of-memory, anything where the server crashed trying to respond.
Open the server's error log immediately. The application log (Laravel, Rails, Node.js, Django, PHP-FPM) will have a stack trace from the exact moment of failure. That trace tells you what to fix — usually a recent deploy, a database issue, or a misconfigured file. Roll back the deploy if the timing matches.
Almost always a plugin or theme update that introduced a fatal PHP error. Add define('WP_DEBUG', true); to wp-config.php to see the actual error, then disable plugins one by one (rename the plugins folder via SFTP if you can't reach wp-admin) to find the culprit.
No. 500 means "the server itself broke" — the application crashed. 502 Bad Gateway means "a proxy in front of the server got an invalid response from the server" — the application may be down, unreachable, or returning garbage. The fix is different: 500 → check app logs; 502 → check whether the upstream app is even running.
A brief 500 during a deploy does not. A persistent 500 (hours or days) causes Google to deindex affected pages and reduce crawl rate sitewide. Set up uptime monitoring with sub-5-minute detection to catch outages before they damage rankings.
A single-page 500 usually means the application is fine but that specific page hits a code path that throws — a bad database query, a null value the code didn't expect, a missing template. The page's entry in the application log will tell you which line of code blew up.
Indirectly, yes — a malformed request that the server didn't validate properly can crash the handler and produce a 500. But the correct response for invalid client input is 400 Bad Request. A 500 here is still the server's fault: it should have validated and rejected the input cleanly.
Production servers deliberately hide error details from the response to avoid leaking stack traces. To see the real error, look in the application log file on the server. For local debugging, enable framework-specific debug modes (WP_DEBUG, APP_DEBUG, DEBUG=True) — never enable these in production.