The importance of error pages …
search engine optimization, techie tips
So, you’ve built this super cool website. You are really pleased with it and you set it live expecting great things. But wait, the client has rung you to say that when they search for their site on google their old listings are still there but when they click through they get ‘404 Error – Page Not Found’.
What do you do? Well there are a number of things you can do. You could wait 3 – 4 weeks for the listings to drop out of Google, if you have a google webmaster account you could log in and manually delete every link that is now dead (which would again take time to be approved) or, if your website is hosted on an Apache server, you could modify the .htacces file…
So what is a .htaccess file?
Basically, it’s a text file where you can list commands for an Apache server. Telling it to behave in a certain way depending on certain conditions. .htaccess is actually a file extension rather than the name of a file. Don’t misunderstand though, your file on your server needs to be called .htaccess not file.htaccess. The name stands for hyper text access and is a ASCII text file and you can create a .htaccess file using any basic text editor.
So what can you do with a .htaccess file?
.htaccess files are extremely powerful. The main reason they are used is to either re direct pages or to create pretty url’s. I’m not going to go into detail about what pretty url’s are in this post. I’ll save that for another time.
If you build all of your websites using Wordpress or a similar open source content management solution, then you probably won’t need to know anymore about .htaccess files other than this is the file you are editing when you change your permalinks.
About those ‘page cannot be found’ errors …
So why should you worry about these errors?
No website is absolutely perfect 100% of the time. There could be any number of reasons why somebody could get an error page on your site. You could have recently re arranged your site and not updated a link correctly, deleted a page and accidentally left the link in place or any number of other reasons.
Error pages re assure the visitor that they have come to the right place. If they were browsing your website anyway and clicked on a link that is broken, chances are, they would use the back button in their browser and there is no harm done. But if they found the page through a search engine you have potentially lost a new visitor, and maybe even new business. The browser back button would take them back to the search engine.
Creating your own custom error pages
Getting around 404 Errors using Wordpress is really simple. All you have to do is add a page to your theme called 404.php that uses your styling and your custom error message. If an error occurs Wordpress will automatically look for that page first. For more information on creating error pages have a look at the Wordpress codex here
If, like me, you also build completely bespoke websites and applications, then knowing how to avoid error pages adds a massive amount of usability to any site you build.
Its not a complicated process, all you have to do is create your custom error page and upload it to your server. Once you’ve done that open your .htaccess file within any text editor and add these lines to it.
ErrorDocument 400 /notfound.php ErrorDocument 401 /notfound.php ErrorDocument 403 /notfound.php ErrorDocument 404 /notfound.php ErrorDocument 500 /notfound.php
If you prefer you can add the absolute url to the page. For example:
ErrorDocument 400 http://www.kirstyburgoine.co.uk/notfound.php
This is especially useful if you have pages within sub folders within your site.
That’s it! You can test your error page by typing anything after your domain name. If it loads your error page instead of a standard ‘not found’ page. You have successfully setup error pages.
You can see mine in action here:
Wordpress Error page: http://www.web-ramblings.co.uk/test
Custom Error page: http://www.kirstyburgoine.co.uk/test
Have fun!
Tags: .htaccess, 404 Errors, 500 Error, Apache, Page Not Found, wordpress
Good post, but I have a question about the 500 error being handled in the htaccess. I use IIS MOD-Rewrite on top of ColdFusion, so forgive me if this is a misunderstanding in the different flavors of URL rewriting; but, in my experience, a 500 error is thrown by the ColdFusion server, after is passes through the rewrite layer. As such, I don’t think the rewrite would have a chance to handle it?
Is it fair to assume that the htaccess file would only handle 500 errors that were thrown before the rewrite executes, and not after (as might be thrown by your PHP, ASP, ColdFusion application server)?
Hi Ben,
Thats an excellent question. My experience is limited to apache servers so I can’t comment on how a Coldfusion server deals with 500 errors.
My understanding is that a 500 – Internal Server Error is a general error and doesn’t give any specific details of what causes it. It is usually a request for a url that has caused a fault with the server. Often javascript or an applet etc.
If there is an error in your .htaccess file then no it won’t be able to redirect to your error page. If it is any other type of general error your .htaccess file should be able to redirect to your custom page without a problem.
Hope that helps
@Kristy,
Sorry, I don’t think I was being clear in my question. The way I understand it, a request goes through a request work flow. For example (and forgive me if this is not accurate with Apache):
1. User requests page.
2. Apache receives request.
3. Apache applies URL rewriting based on htaccess.
4. Apache hands request off to application server (ie. PHP, ColdFusion, ASP).
What I am asking is, the 500 errors in the htaccess file, do they handle 500 errors thrown in step #4 (once the request is handed off to the server-side scripting language)? Or do they only handle 500 errors thrown before step #3.
And, if they only handle errors before step #3, how does Apache even get the URL rewriting step?
I guess I am confused as to how a 500 error would be at that particular time / place.
Ooops, sorry about misspelling your name (Kirsty).
Sorry if I am confusing. I have only built one site with mod-rewrite and all it was doing was forwarding to index.cfm/#path_info#. This is all relatively new to me and the IIS MOD-Rewrite documentation doesn’t make any reference to the ErrorDocument directive (it’s not 100% compatible with Apache’s version).
Hi Ben,
No worries, I’ve seen far worse spellings of my name
I’m not an absolute authority on this but my understanding is that a 500 error generally happens at step #4.
Once Apache hands the request off to the application server the page is loaded. Its during the page loading process that a javascript or an applet etc. can cause a 500 error.
If the server is set up to intepret these errors using the .htaccess file (which most Apache servers are, some need configuring though) the error is passed back to Apache which checks the .htaccess file to see how to handle it.
If you have set up default error pages then those are displayed. If not the default error page is displayed.
Here are a few resources I’ve found helpful in the past:
http://httpd.apache.org/docs/2.0/custom-error.html
http://www.checkupdown.com/status/E500.html
http://en.wikipedia.org/wiki/List_of_HTTP_status_codes
I hope that is more helpful
Do you know if this will happen if the application server sets the response headers manually? Or does it only work with an uncaught exception is thrown?
Anyway, I’ll do some research on my own. I appreciate the inspiration.
@Kirsty,
It looks like this might be something that is not compatible with IIS MOD-Rewrite. I set up the following htaccess file:
ErrorDocument 400 400.cfm
ErrorDocument 401 400.cfm
ErrorDocument 403 400.cfm
ErrorDocument 404 400.cfm
ErrorDocument 500 500.cfm
I tried to trigger a 500 error from within the application server layer (ColdFusion) using CFHeader (which sets header values):
————————————–
“hello”
————————————–
This shows “hello” on the page, indicating that no redirect has been done. Furthermore, FireBug shows the response code coming back as 500.
I thought that maybe this was an issue because I was setting a header and not actually throwing an error. So, I created another page with the bunk code (reference to an undefined variable):
This also shows up as a 500 status code in FireBug, but all I get is the error on the screen (Variable bar is undefined).
I tried to look at the log file and I get this as the last few entires:
init rewrite engine with requested uri
pass through /iis_mod_rewrite6/
init rewrite engine with requested uri
pass through /iis_mod_rewrite6/index.cfm
It looks like the 500 error never gets passed back up into the rewrite engine.
It looks like this approach is simply not compatible with IIS MOD-Rewrite
Hi Ben,
Thanks for all your comments on this its been really interesting.
Perhaps I should have been clearer in my original post, using .htaccess files is a technique specifically for Apache servers.
I know for a fact that Windows Servers using IIS will not read a .htaccess file, and although I have never used a Coldfusion server, you mention that its running IIS. In which case its highly likely that it won’t use the .htaccess file either.
Many hosting companies have a setting within their control panel that allows you to set up custom error pages. I installed a website on a windows server the other day and to set up the error pages all I had to do was switch on that feature and tell it which page I wanted to display if an error occurred.
Perhaps its worth going back to your hosting and asking them what their preferred method is?
Thanks
Kirsty
I have now updated my original post so that its clearer that the technique is for Apache
@Kirsty,
Sorry, I understood that you were posting about Apache. I am on IIS, but the ISAPI plugin – IIS MOD-Rewrite – allows IIS to read and use htaccess files the same way Apache does… or at least to the best of it’s ability – it’s not 100% compatible.
For the IIS version, this appears to be a point of non-compatibility.
I guess I’m still just having trouble wrapping my head around the 500 error. If you set the HTTP Response headers in PHP to return a status code of 500, does this get kicked back up to your htaccess file? That is the workflow that is really fuzzy in my head.