Dead End Page - How To Track Error 404 - Page Not Found

Landing on a website and getting a 404-Page Not Found error is frustrating.  But owning the website with those errors can mean lost money.  If you’re not already tracking these errors, here’s your primer to start today.If you’re here to implement 404 Page Not Found tracking and know why you need it, you can skip this first section.  If not, I’ll cut to the chase.  Tracking when your website visitors request a page that doesn’t exist has many advantages.  To do this is not just a nice feature to implement, it’s a requirement.  The downside to this is a very poor user experience.

1. You may have links into your website from other sites that you aren't aware of.  Those links may be pointing to non-existent pages on your website.  This has two major downsides:
   • Visitors hate 404 – Page Not Found errors.  They typically bail on the site rather than work to find out the real page they were meant to land on.
   • Search engines can’t pass any of their link love from the other site to yours.  Losing that love is a tragedy.
2. The tactic of creating a custom 404 page is good business.  It forces you to consider the scenario and how you would like to be perceived should someone land on a dead page on your site.

The Code

Common Code

Regardless of your vendor you will need to either locate the current 404 page on your webserver or create one if one doesn’t exist.  This is where you’ll be creative and really consider the user experience with humor, information (sitemaps?) or redirects.On this custom 404 page you will tag it like all of your other webpages with the following exceptions.  One for Google Analytics and for (Adobe) Omniture's SiteCatalyst.

Google Analytics

For Google there are two tagging versions you can consider depending where you are in your timeline of migrating from their synchronous versions to their latest asynchronous version.

Note that as of this writing I personally have run into a significant problem with the asynch code and have rolled it back until it can be addressed by Google.

The code snippets below are your typical code snippets provided by Google Analytics with the addition of detailed trackPageview parameters.  These parameters allow your reporting to expose which page the visitors were trying to reach and where they came from.  See Google’s explanation of 404 tracking.

Old School: Synchronous code

var gaJsHost = (("https:" == document.location.protocol) ? " https://ssl." : "http://www.");document.write(unescape("%3Cscript src='" + gaJsHost + " google-analytics.com/ga.js' type='text/javascript'%3E%3C/script%3E"));try{var pageTracker = _gat._getTracker("UA-xxxxx-x");pageTracker._trackPageview("/404.html?page=" + document.location.pathname + document.location.search + "&from=" + document.referrer);} catch(err) {}

New school: Asynchronous code

var _gaq = _gaq || [];_gaq.push(['_setAccount', 'UA-XXXXX-X']);_gaq.push(['_trackPageview', '/404.html?page=' + document.location.pathname + document.location.search + '&from=' + document.referrer]);(function() {var ga = document.createElement('script'); ga.type = 'text/javascript'; ga.async = true;ga.src = ('https:' == document.location.protocol ? 'https://ssl' : 'http://www') + '.google-analytics.com/ga.js';var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(ga, s);})();

Regardless of which version of code snippet you use, your reports will look similar to this.

Sample Resulting Report

The simplest way to view these reports is to create an advanced segment that sets the Page as containing “/404.html”, or whatever your custom 404 page URL begins with.  Make sure it is qualified as “contains” and not “matches exactly” or anything else.After applying this advanced segment go to “Content-Top Landing Pages”, from there you’ll be able to see a report detailing each instance of the 404 error along with the intended destination page and the site the inbound link came from.

Omniture

sample code

s.pageName=""s.pageType="errorPage"

Do not set the s.pageName variable on this page!From (Adobe) Omniture’s SiteCatalyst v14 Implementation Manual

2.1.44 pageTypeThe pageType variable is used only to designate a 404 Page Not Found Error Page. It only has one possible value, which is “errorPage.” On a 404 Error Page, the pageName variable should not be populated.Table: pageType Variable ParametersThe pageType variable captures the errant URL when a 404 Error Page is displayed, which allows you to quickly find broken links and paths that are no longer valid on the custom site. Set up the pageType variable on the error page exactly as shown below. Do not use the page name variable on 404 error pages. The pageType variable is only used for the 404 Error Page.! NOTE: In most cases, the 404 Error Page is a static page that is hard-coded. In these cases, it is important that the reference to the .JS file is set to an appropriate global or relative path/directory.Syntax and Possible ValuesThe only allowable value of pageType is “errorPage" as shown below.s.pageType="errorPage"Exampless.pageType="errorPage"SiteCatalyst Configuration SettingsNonePitfalls, Questions and TipsTo capture other server-side errors (like 500 errors), use a prop to capture the error message and put “500 Error:<URL>” where <URL> is the URL requested, in the pageName variable. By following this course of action, you can use Pathing Reports to see what paths caused users to generate 500 errors, and the prop will explain which error message is given by the server.

Tracking 404 Error Pages Improves Visitor Experience

This tactic has proven invaluable to me and my clients.  Over time we notice the number of visits to the custom 404 page go down because we create custom 301 redirects for each bad inbound link and redirect to the most appropriate page on the site.  This regular maintenance slowly firms up your website and in the end creates a better visitor experience.