Handling Errors and Duplication, Part 9 of Designed to be Found
The 404 HTTP response means: requested resource not found. Even with an infallible web development process preventing errors ever appearing in your own pages, third party mistakes are able to cause browsers to request non-existing URLs.
Some search spiders will ‘invent’ their own URLs. This is sometimes an attempt to locate higher directories in a site, but search engines also like to test that getting a true 404 error is possible, ensuring that they are not crawling a potentially bottomless site, where any URL at all will return some valid page.
It is a virtual necessity to create a custom 404 error page for any site. This presents your apology for the error and navigation suggestions to help the visitor locate the desired resource.
A common error with the creation of custom 404 pages is that developers forget to ensure sending the correct 404 HTTP response. Instead, the server may often serve a 200 response, because the custom 404 page was indeed found and served just fine.
Microsoft’s ASP.NET is a real pain in this regard, because by default it will serve a 302 redirect to the custom 404 page. This just won’t do. The following codes can all help you to get this issue sorted:
ASP & ASP.NET
Avoiding the redirect altogether proved the most effective method to prevent IIS giving a 302 redirect to the 404 error page. This leaves the erroneous URL in the address bar but serves the custom 404 page content. Then on the custom 404 page, (404.asp in the example), we have the following code:
ASP code for custom 404 page
Response.CacheControl = “no-cache”
Response.Status = “404 Not Found”
ASP.NET code for custom 404 page
Context.Response.Status = “404 Not Found”
Context.Response.StatusCode = 404
Use a tool such as ‘Sam Spade’ or an online Header Checker to ensure that your 404 page gives a true 404 server response.
Look out for part 10 next week…