HTTP 500 Internal Server Error: Identifying and Troubleshooting Website Issues

Each time a bot or users access a web page, the server returns a status code. The general “good” status code is 200, which translates to “OK” to bots and web browsers. This means that the page and code rendered fine with no errors. The HTTP 500 response code is a general error. It’s probably one of the most difficult errors to troubleshoot, because there is no real explanation for the problem. The server just returns a general error and it’s up to you to troubleshoot the problem. This article uses Windows as the server operating system, but Linux also returns this same error code for general errors.

Learn more about HTTP status codes and managing your server at Udemy.com.

Finding 500 Errors

It’s better to find 500 errors before your users do. Sometimes, it can happen site-side. Other times, only certain pages return a 500 error.

One way to see server status codes is to use tools such as web-sniffer.net, which is an online tool or Fiddler in FireFox, which is a web browser extension. It’s better to use Chrome or FireFox for identifying issues. Chrome also has developer tools just like FireFox. Internet Explorer (IE) has “friendly errors” on by default. You can turn these friendly errors off in IE’s options, which will then allow you to see error codes.

Seeing 500 Error Code Details

Unless you have error details turned on in your web.config file, Internet Information Services (IIS) doesn’t give you details about a 500 error. By default, the server just gives you the error code. However, if you have a dedicated server or VPS, you can see more detail. If you have shared hosting, you will have to turn on error details in your .NET application in the web.config. You don’t want to leave error details turned on when you work with a production application, because these details can give hackers too much information that makes your web server and application vulnerable.

Windows has a utility called Event Viewer. Event Viewer gives you all kinds of detail including security and authentication issues, application errors and web server events including coding errors. When a 500 error occurs, Event Viewer logs the error where you can see more details including the line number in your code causing the error (if it’s code related).

To open Event Viewer and view your web server errors, click your Windows server “Start” button and type “event viewer” in the text box. Click the “Application” section of the error logs. All applications report errors to this section of Event Viewer, but you can trigger a recent error by refreshing the page with the 500 error.

Coding Errors

Event Viewer tells you the exact line item and coding error for a 500 HTTP response code. Of course, the cause of your coding error is beyond the scope of this article, but you can use this piece of information to then debug your application in Visual Studio.

Coding errors can stem from other issues. For instance, your users might have old cookies stored on their machines that trigger code that no longer works. In that case, you should code your application to delete the cookie. To delete a cookie, you set its expiration date to a date in the past.

Even if you narrow down the coding issue to a specific line of code, the error can stem from several reasons, so it’s up to you to do some investigation. That’s what makes these errors so difficult – the error can be from one or multiple sources.

Plugins and Sniffing User Agent

If you use WordPress, you probably use plugins. Some SEO plugins detect user agent and do some kind of action based on a particular user agent value. User agents are values sent by browsers and bots. Many SEO plugins try to detect search engine bots, which throw user agent. For instance, Google uses the “Googlebot” user agent.

If the plugin has any kind of issue, your server will return a 500 server status to bots and not users. This means that you and your users won’t see a server error, but only bots will see the issue. The result is that your search engine rank will suffer since your site doesn’t respond properly to search engines.

Most people use Linux with a WordPress blog, but PHP and WordPress can run on a Windows server. If user agent sniffing is an issue, Event Viewer will still show the error even though it’s not a .NET website. If you have SEO plugins and don’t have access to Event Viewer or use Linux, the best way to handle this type of issue is to disable all plugins. Enable them one-by-one until the 500 error occurs. Once you find the plugin, you know which one is the culprit so you can either disable it altogether or update it so the bug is fixed.

Learn how to manage an Apache server for a personal WordPress site

These are a few ways to identify the culprit for a 500 error. In some cases, it could also be hardware failure. These are the most difficult to identify and it can lead to a crashed server. If you have a VPS or shared hosting, you can’t do much about it. All you can do is contact your host, but you can be proactive about your web property and make a backup.

If you have a dedicated server, contact your host for help. With dedicated server support, hosts will be more willing to help you figure out the problem even if it’s a coding problem.

Identifying code issues is done using Visual Studio debugger processes if you’re a .NET coder, and PHP tools if you use PHP. PHP does not have a debugger, so it might be more difficult to identify the main issue. However, Apache and Linux also have logs just like IIS, so you can review your logs and any events that could lead to main server failures.

If you need to bring your server down, use a 503 server error code. This code means “Temporary Maintenance,” and most bots and users will come back to view the site. This error is better for bots and SEO than allowing general 500 errors.