Zero Pageviews Is Your Goal: Finding Problem Pages with Website Analytics

Website analytics are great for monitoring visits to the content that your team has spent time and resources working on. Are people finding this important content? Which parts of the content are people using the most

However, website analytics are also important for tracking the performance of the web pages that you don’t want people to visit. These are pages that you would expect to be associated with bad experiences and frustration. Most commonly, I’m talking about error pages, but there are other negative page visits that could be measured on your site, too.

Error Pages

The easiest place to look for problems is 404 pages. In most situations, your website is set up to have 404s when the URL requested by the browser doesn’t match an expected one. These pageviews to your 404 page still register hits to your analytics account, so you can examine these URLs and perform other analysis there. 

For DAP Users

If you’re using the Digital Analytic Program’s (DAP) Google Analytics account, filters have been set up that make finding visits to 404s easy. You can search for URLs with the substring “vpv404” inserted between the hostname (i.e., usa.gov) and the path (i.e. /consumer-problems). If DAP has referral information for the URL (where the user came from), it will append that to the URL after a forward slash. This can help with figuring out the problem.

Non-DAP Users

If you don’t use DAP, you will want to figure out how to filter for URLs that have led to 404 errors. One way that might work is to filter with the Page Title dimension; for example, the strings “404” or “error” may be a part of all the page titles for not found pages.

Examples of Error Page Issues You Can Find and Solve

USAGov has had a lot of success correcting problems by using this method. For example, we have discovered and rectified issues like: 

• Old popular pages of ours that external websites still link to. To help these users, you can set up a redirect that matches the URL to point it at a current relevant page. You can also reach out to the websites that link to your pages so that they can update their resources. Or maybe it’s time to revive the content?
• Redirects that stopped working. Things break sometimes! How would you know if you’re not keeping an eye on your 404 pages?
• Broken URL generation. If your website has dynamically generated URLs, the code that creates them can break in certain places. For example, we used to have a search box tool for our index of federal agencies. The URLs in the results were generated by using rules that were supposed to match the rules that we generated the pages with… until they didn’t! We wouldn’t have known to investigate until we saw a bunch of URLs from our agency records folder that were 404 errors. Another similar problem we have encountered is the rules accidentally changing for how our CMS handles punctuation in the field it bases URLs on. The rules changed, and we saw a 404 spike.
• Weird CMS user error mistakes. For example, a couple of times we have added links to our own pages but left off a forward slash at the front. 404 spike! 
• URLs typed in with errors. Sometimes people incorrectly type your URLs into their devices because they got it from a newspaper or similar. If you discover the problem, you can do redirects to make sure they get where they need to go.
• Your system is so sensitive! Some websites have URLs that are case sensitive or can’t handle a missing forward slash at the end, etc. You can discover if these types of limitations are keeping people away from the content they need.

These Are Not the Pages You’re Looking For

You may have pages that are not 404s but you don’t expect to get many visits, like an “about your website” page. Lots of traffic to pages likes this may be a sign of confused users, perhaps poking around your footer trying to orient themselves. So, you might want to investigate. At USA.gov, we have found too much traffic heading towards our contact page for media and our email subscription sign-up page, and these have led to us to explore design changes.

One of our most noteworthy examples of tracking pages that we didn’t want users to visit involves discovering hostnames that were not ours appearing in our Analytics account. Long story short, criminals were copying our web page code to create websites to steal personally identifiable information and money from users. Luckily, we were digging deep in our analytics account for things that looked wrong, and not just right. (We discovered this problem with a different account from DAP, because we had one that let us track hits to our pages regardless of hostname.)

Conclusion

There are lots of problems that impact real visitors negatively that can be discovered by using your analytics products to look at the pages you don’t want people visiting. It might sound upside down, but flipping your analytics strategy can sometimes help you improve the experience for lots of web-crawling Americans. What’s more, it can be a part of your analytics work where the metric goals will be clear to everyone: zero!