500 Internal Server Error Example
I asked the Sultan's cook for one soft-boiled egg, the kitchen burst into flames, and that is how the Empire learned I had asked.
The short answer
- What it is
- A 500 is an HTTP status code that says the server hit a problem it could not handle while answering the request. It is a generic code that gives no detail about the cause.
- Why it matters
- Visitors get an error instead of the page they wanted. If the errors go on, search engines crawl the site more slowly and may drop the affected URLs.
- How a crawler should report it
- Report the URL as a broken page with status 500 in the status field, and mark it as non-indexable. List inbound links as broken links, and retry the URL once to tell a one-time fault from a steady one.
- Live examples
/lab/broken-pages/500/(positive), on the first shelf/lab/broken-pages/near-miss/(near miss)
What happens when the server fails while building a page
A 500 internal server error means that something broke on the server while it tried to build the response. The request itself may be fine. Common causes include a bug in the code, a failed database query, a bad deploy, a syntax error in a config file such as .htaccess, a plugin conflict, and a script that ran out of memory. Since the code is generic, the status alone will not tell you which one it was.
Browsers show the error body from the server, or a default message if the body is empty. Search engines react with more care than they do for a 404. Google slows its crawl when a site returns many 5xx codes, because it does not want to add to the load. URLs that are already indexed stay for a while. If the errors last, those URLs can fall out of the index.
Crawl the site and filter for 5xx codes. Run the same URL again, since a 500 can come and go under load. The server error log is your best tool. It usually names the file, line, or query that failed. Compare the time of the first error with your deploy history, because a recent release is a frequent cause.
To fix it, find the failing code path in the logs and repair it. Roll back the last deploy if you need a quick way out. Add monitoring so that a spike in 5xx codes sends an alert. Show a friendly error page if you like, but keep the 500 status on it. An error page served with a 200 status hides the fault from every tool you use to find it.