Tracking 404 Error Pages

There are tools out there that find bogus links on your site, and some even try to find links outside your site that point to nirvana. But your friendly marketer likely wants to have better data than that, so she asks you to build tracking for 404 pages.

Now what?

Let me explain, both for Javascript-only (“legacy”) and DTM-based deployments.


If your site is not yet using a TMS, or if your TMS wants you to write Javascript code for Analytics, then you should read this part.

What we need:

  • a 404 error handler page
  • the Analytics library loaded on that page (either s_code.js or AppMeasurement.js)
  • a limited data layer on the 404 handler page
    1. stating it is the 404 handler page
    2. carrying the original URL that failed
  • a little Javascript block at the bottom of the page

There is a special report for pages that do not exist, aptly called the “Pages not Found” report. For a not-found page to show up in this report, its URL has to be tracked, and the system has to be told that this URL was bad.

Here’s what that would look like:

	s.pageName = "404:" + window.location.href;
	s.pageType = "errorPage"; // this makes it a call for the Pages not Found report

The two things to note here are:

  1. Setting s.pageType = "errorPage" is what makes this call special. By setting this, you tell Analytics that the page name should be treated like a URL for the Pages not Found report.
  2. Setting s.pageName, you should include the original URL. That’ll help you figure out where the problem is. Whether you use window.location.href, window.location.pathname, or something else, is entirely up to you.

Note that the s.pageType Variable is not used anywhere else! The above is the only use case and the only allowed value for that variable!


This will be pretty easy, too (so I wrote it first). We need:

  • a 404 error handler page
  • a limited data layer on the 404 handler page
    1. stating it is the 404 handler page
    2. carrying the original URL that failed
  • one Page Load Rule
  • a little bit of custom Javascript inside that rule

To show you an example, here’s what happens if you go to — say —

Data Layer on the 404 handler page
The resulting tracking call looks like this:

Analytics tracking call on 404 page
And in Analytics, you’ll later see this:

Analytics Pages not Found report
How did I do that? Easy. Here is the PLR:

Page Load Rule for 404 page
And the custom code is actually a single line:

Custom Code inside the PLR
Want to see the httpErrorCode Data Element, too? Sure:

Data Element for 404 error tracking
Any questions?

Note that my 404 handler page is good in that it leaves the URL untouched, making it easy to create the pageName for tracking. Other content management systems redirect the browser. If yours does that, make sure the original URL is available somewhere in the page, so that it can be read and used for tracking.

Does it make sense to go one step further and track the referrer into a prop? I guess it does.

2 thoughts on “Tracking 404 Error Pages

  1. Sometimes (pretty often in fact) we use just Image pixel tracking, because IT DEV OPS want error pages on lower network nodes (i.e. Proxy) to be independent from other resources (no DTM and preferrably no external scripts).


    We mostly add some other custom variables to have status codes, in case that we want dynamic stuff from DOM – i.e. location.pathname, we use inline script to create the image.

    This way you don’t have to worry about library updates.

    Liked by 1 person

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s