What do you do when someone clicks through on a dead link or mistypes a URL for your Web site? Years ago when I first learned about error 404 handling I was appalled to discover that my hosting service at the time didn’t even set up a default page for me. Many Web sites today still don’t have a 404 condition handler, although Web hosting service providers have improved the quality of their setup packages considerably. On Apache-based services I typically find default error handling documents already configured.
Still, it’s no fun to click through on a URL and see a dumb Web page that serves no purpose other than to tell you the page you’re looking for doesn’t exist. In fact, the page may exist but you’ve got the wrong URL.
Although many people in the SEO community recommend implementing 301-redirects to handle bad URLs there are drawbacks to the 301-based solution. For example, if you change out 30,000 URLs you don’t want to create a .htaccess file with 30,000 entries (although there are ways to wildcard stuff, you need to understand what you’re doing). Every visitor to your site forces your server to check every .htaccess file in directories they visit. If you’re getting 1 million page views a day, you’re potentially adding 1 million .htaccess file processes to your server load.
That is substantial processing time, so the smaller your .htaccess file is, the better. Hence, at some point you have to look for a better solution than just using 301-redirects. And keep in mind that while smaller sites may not get that much traffic, they may be sharing server resources with hundreds of other sites. A server could still be getting hammered by mismanaged 301-redirection.
For that reason and others, many of us years ago turned to customizing our 404 results. For a few years I and many other people simply set our root URLs or sitemap pages as the default 404 documents. While this helped wandering visits find current or real content on our sites, it didn’t really get them to where they wanted to be.
I’ve advocated the use of site search to help people find what they are looking for more quickly but I have to admit that it never occurred to me to offer site search on a 404 document.
Now Microsoft is offering an ASP Web Page Error Toolkit solution to help people on IIS platforms with their 404 handling. They’ll give you site search.
Geeze, why didn’t I think of that?
I like the idea and my hat is off to Microsoft for suggesting what seems like a pretty good idea. I’ll have to play with it and see how well it works.
{ 1 comment… read it below or add one }
colstrom 06.05.08 at 2:15 pm
Site Search is a great idea to add to a 404 page, especially for traffic pulled from search engines.
As a user, If I click through to a page and it displays a generic error, I am left with few options other than clicking ‘back’. This is especially true when the browser generates the error page, rather than one being served by the site.
As a site owner, the concept of throwing those click-throughs away seems silly. I do routinely monitor my logfiles for 404 errors, and I have a weekly summary emailed to me. I use this information to set up 301 redirects (where appropriate), or when the opportunity is present, I write new content to reside there (the URL is already indexed and linked from somewhere, why not use it?).
Some time ago, I replaced the default 404 error with a custom error stating that the page isn’t there, and a convenient link to the front page of the site. Site search is a much better concept. I suppose it should also be possible to display the results of a query based on the URL causing the error, guiding the user to (hopefully) related content.
You must log in to post a comment.