What Is a 500 Error (Internal Server Error)?

Code 500 belongs to the 5xx family, reserved for failures that happen inside the server rather than in the request itself. Under RFC 9110, the current specification, the server responds with 500 when it "encountered an unexpected condition that prevented it from fulfilling the request." In practice, it is the catch-all for server errors: it applies whenever something breaks and no more specific code describes what happened.

That vagueness is the key to understanding it. A 404 error means the requested resource does not exist. A 400 error means the request itself was malformed. A 500 says neither of those things: it confirms the server received the request, started processing it, and something broke along the way, whether in the application code, the database connection, or exhausted resources.

On WordPress and similar platforms, 500 errors usually show up after activating an incompatible plugin or theme, or after a PHP update that leaves older code unsupported. On higher-traffic sites, it can also simply be the server running out of memory or available connections during a traffic spike.

All four codes are server errors, but each marks a different point in the process. Mixing them up complicates diagnosis, because the fix is not the same in any two cases.

In practice, 502 and 504 almost always involve a proxy or load balancer, while 500 and 503 can happen on a single server. Compared to a 404 error, all four share one trait: the request arrived correctly formed, and the failure sits on the server side, not the client side.

When a correctly formed request reaches the server, it starts processing it: querying the database, running the application logic, building the response. A 500 appears when something breaks in that process, after the request has already passed the checks that would otherwise trigger a 400 error, and before the server finishes generating the response.

HTTP/1.1 500 Internal Server Error
Content-Type: text/html; charset=UTF-8
Date: Sat, 08 Aug 2026 10:21:09 GMT

The most common causes repeat often. A plugin or theme with broken code, frequently after a WordPress update that clashes with the installed PHP version. A database connection failure, whether from wrong credentials, a downed service, or a connection limit exceeded. A misconfigured .htaccess file, especially after manual edits or a move to a new server. Exhausted server resources, memory or processes, during traffic spikes the hosting plan cannot absorb. Less often, an expired SSL certificate or a PHP version conflict between the code and the environment running it, sometimes triggered by a host-side update.

Unlike a 404 error, which confirms the server finished searching and found nothing, a 500 leaves the process unfinished, often with no obvious pattern from the visitor's side. That is why checking server logs is almost always the first step: they record which process or line of code caused the failure, information the HTTP response alone does not provide. A quick look at the error page in the browser will not tell you that.

A single 500 error lasting seconds or minutes barely affects rankings. Google treats isolated failures as normal noise from any server. The problem starts when the error repeats or persists: Google Search Central confirms that 5xx errors, along with 429, cause its crawlers to temporarily slow down crawling, and if the server keeps returning 500 long enough, the affected URLs eventually drop out of the index.

Search Console groups these failures under the "Server error (5XX)" category in the Crawl Stats report, separate from 4xx errors. A sustained increase there is the most reliable signal that the problem is not a one-off, even if the site looks fine during a manual check.

The good news is that recovery is just as fast. Once the server starts responding normally again, Google gradually restores the previous crawl rate. Unlike a 404 error, which removes content from the index without needing to repeat, a 500 only does damage once it becomes the rule rather than the exception.

• Check server logs right after a 500 to identify the process, plugin, or line of code responsible, instead of just reloading the page.
• Set up uptime monitoring that alerts on the first 500, not only once the site goes fully offline.
• Return 503 instead of 500 during scheduled maintenance, since 503 tells Google the outage is temporary and keeps affected URLs from dropping out of the index.
• Test plugin and theme compatibility before every WordPress update, especially on stores or sites with custom integrations.
• Verify the SSL certificate and PHP version after any hosting migration, two frequent and easy-to-miss causes.
• When an error appears after a recent change, disable plugins or themes one at a time to isolate the cause instead of blindly rolling back the whole update.

• Returning 500 instead of 503 during a migration or maintenance window, which can speed up pages dropping out of the index.
• Ignoring a 500 that only appears intermittently, assuming it is fixed just because the next load works.
• Rolling back an entire update without checking the logs first, missing the chance to identify which plugin actually caused the failure.
• Confusing a 500 with a 404 error when reading reports, treating a server failure as missing content.
• Not monitoring uptime at all, and finding out about the problem only when a client or Search Console reports it days later.