We can set our custom error pages using the configuration panel in our applications. This is used to avoid displaying the ASP.NET YSOD (Yellow Screen Of Death) when there is a broken link or an unhandled error. This is a great plus for ASP.NET developers since it avoids us from having to change IIS manually to get the same result. All we have to do is change the web.config in order to modify the way a page is displayed under anomalous circumstances.
To do this we just have to add the node <customErrors> in web.config:
In this example we defined a special page for the error HTTP 404 (resource not found), another one for the error 500 (internal server error, this is, all unhandled errors) and a page (GenericError.aspx) for all other HTTP status but 200 (which indicates that all is fine).
So if we have a broken link which is clicked, instead of displaying an error page, we can define another page with a better and more proper style.
But let’s see the resulting URL in the browser:
By default we get an inconvenient URL which is showing the custom error page address using as parameter the not found page. This is inappropriate and besides it worsens our position in search engines.
Custom pages and SEO
Does it affect SEO negatively? Yes, let’s study the situation carefully:
- A search engine index robot comes to our web site and starts requesting all pages and follows all the links in it.
- It finds a broken link to an ASPX page.
- ASP.NET shows an error page Error404.aspx because the original page doesn’t exist. To do this the server sends a HTTP response status code 302. This is the standard way to indicate a web browser/robot that the page has been moved from the site temporarily and not that it was not found.
- The robot receives the 302 code with the new URL and request the new location. I think that Google robots will remove the page from the PageRank when a 302 is found for 2 or 3 weeks since the page was temporarily moved. So what is placed in the PageRank is the page where the original one was supposedly moved to, which is the 404 error :-(
How can we avoid this?
There are two ways: the easy way and the hard way.
The hard way is to catch all errors in the application using Global.asax or a custom HTTP module, then show the information we want and finally return the right HTTP status code.
The easy way is by using the Custom Error redirect mode. This ASP.NET feature is in the version 3.5 SP1.
This is actually simple and easy to implement. It’s a special attribute in the node <customErrors> in the web.config: redirectMode.
This attribute receives two values:
- ResponseRedirect: it’s the default value. It sends a 302 status code to the client to be redirected to the custom error page.
- ResponseRewrite: this value rewrites the request in the server instead of redirect, so it goes to the custom page but without the client knowing. It addition, the error code (404) is sent to the user.
If we use it in our application, the node <customErrors> in web.config will look like this:
And now if we request a page that doesn’t exist, we’ll get this:
The browser displays the original page requested. There is no redirection for the client. And better yet: we’ll keep getting the 404 status error code.
It’s the same for other status error codes, such as 500 (unhandled errors).
Warning: nothing is perfect
There is an annoying side effect, which hasn’t been fixed in the version 4.0: in the custom error page we cannot access the original request context.
This is, the object HttpContext.Current is null. So we don’t have access to session variables, values in the QueryString among others.
Take this into account if you want to use this method.
At any rate, it’s still very useful.