|500 HTTP Status and Search Engines|
| 3:55 am on Sep 23, 2010 (gmt 0)|
Microsoft's workaround for this recent ASP.NET vulnerability is to "map all error codes to the same error page" (http://www.microsoft.com/technet/security/advisory/2416728.mspx)
Any ideas on what would happen from an SEO viewpoint if I return a 500 HTTP status for every error?
| 5:55 am on Sep 23, 2010 (gmt 0)|
It's not clear to me that you're being asked to return the same status code - only the same generic error message page.
| 1:10 pm on Sep 23, 2010 (gmt 0)|
From the FAQs section of the security advisory cited above:
|Q: Am I vulnerable if I have a custom logging module that redirects to an error page instead of using the workaround listed below? |
A: If the responses that are sent out from your custom logging module do not let the client distinguish between error responses either through its content or time that it takes to serve out, then such a module is an adequate replacement for the customErrors workaround. These responses include both the entire HTTP response and the HTTP error code. If any of the above is not true at all times, then this is not sufficient.
This *seems* to indicate that it is necessary to make the entire error response generic, so that different types of errors cannot be distinguished in an way by HTTP clients. In typical fashion, the wording in this Advisory is just not explicit enough to be absolutely sure -- They state what is insufficient, but not what is sufficient.
But by adding up all the clues in this Advisory, I would interpret it to mean that everything about all error responses should be entirely generic, to include the server status response code, the content-body of the response, and even the time typically taken to generate that response. Note that they even recommend inserting a random delay if some of your error-types typically take longer than others to detect and process.
My gut feeling on this is that you'd be better off returning a generic 400-Bad Request, which is the most-generic of error codes indicating a client error if your site typically experiences many client errors (based on the counts of 400, 403, 404, and 410 errors that you see in your error log daily) and very few actual server-side errors. In this case, indicating a client-side error for all errors is "true more often" than indicating a server-side error by using a 500-Server Error response.
However, it does seem to me to be preferable in either case to return the most-generic error code -- i.e. either 400 or 500, so that the server does not indicate any specific "reason" but rather a generic one.
But in either case, returning inaccurate server responses is likely to cause some kind of upset to search engine spiders, and all we can do is to hope that MS fixes the root problem as quickly as possible so that this work-around will no longer be necessary.
| 11:35 pm on Sep 26, 2010 (gmt 0)|
Thanks Jim. Here's hoping the patch is released quickly.
| 10:08 pm on Sep 27, 2010 (gmt 0)|
Just seen a report that an out-of-band patch for ASP.NET is being issued Tuesday 28th.