What you need to know about Referrer Policy

Seeing some confusing referrer data in your analytics program? It might be the result of an issue with 'noreferrer.' Columnist Patrick Stox explains Referrer Policy, which lets webmasters define the value of the referrer header in outbound links.

Chat with SearchBot

Security Lock Computers Staging Lg

If you’re running WordPress, did you notice a recent change in your analytics where more traffic is being attributed to direct traffic or a no-referral bucket? When WordPress updated to 4.7.4, the text editor TinyMCE also updated, and this is where the problem actually lies.

In November 2016, TinyMCE added a security update that added rel=”noopener” on links with target=”_blank”. This has since been changed to remove the part in TinyMCE, but I don’t believe WordPress has this update yet. With this, traffic that should count as referral traffic may be misattributed.

Noopener

TinyMCE should have left the security fix alone after adding noopener, and in a newer release they did remove. The noopener tag is meant to close a security issue with target=”_blank” called reverse tabnabbing, which grants partial access to the previous page via the window.opener object. Basically, it can prevent a phishing attack by not allowing access to the window.opener object. With access, a simple phishing attack could change the window.opener.location to another page rather than the previous one or inject JavaScript on the previous page.

Noreferrer

Noreferrer is meant to strip the HTTP referrer header (technically the “referer header” because of an old misspelling) and is intended to not pass this value between pages. The referrer header is meant to pass information about the previous web page to the new web page, so if I go from Page A to Page B, then the URL from Page A will be passed in the header, and I will know that the traffic came from Page A.

Nofollow

A lot of people confused “noopener” with “nofollow.” Many forums and Q&A sites mistook these tags to indicate links weren’t passing value, as is the case with nofollow links, but that’s simply not true. Noopener will not have any impact on your SEO, but will create problems with your analytics.

By stripping the referral value, the traffic from these links will be misattributed — instead of showing as referral traffic, they will be attributed as “direct” in Google Analytics. Or, if you have another analytics program, you may see the visits in a noreferral bucket. This is part of what is commonly referred to as dark traffic, or traffic that you know came from a place other than how it is attributed.

A primer on Referrer Policy

Referrer Policy is used to determine what information is sent along with the requests. Many people know, for instance, that the referral value is stripped when going from a page using HTTPS to a page using the HTTP protocol, but did you know that’s because this is the default setting for the Referrer Policy if nothing is specified? Technically, this is “no-referrer-when-downgrade,” which means it will strip the referral when downgrading to an insecure request like switching from HTTPS to HTTP. You don’t have to use the default setting, though.

In the case of the WordPress example we looked at earlier, noreferrer was added to the rel element on links set to open in a new window. This caused enough of an issue by itself, but there are many other ways that the Referral Policy can be set, including at a page level, which can wreak havoc on your analytics.

In one of the newer sections on the IBM website, we had mistakenly launched with a meta tag — which, in our system, actually put the traffic in a noreferral bucket instead of classifying it as direct. So we didn’t see when one page on our website sent traffic to another page on our website.

There are many ways you can deliver the referrer policy:

  • Via the Referrer-Policy HTTP header
  • Via a meta element with a name of referrer
  • Via a referrerpolicy content attribute on an a, area, img, iframe, or link element
  • Via the link relation (rel=) on an a, area, or link element
  • Implicitly, via inheritance

Referrer Policies

Referrer Policy isn’t just for removing the referral value; it’s for giving you control of the value. One of the things often missed when moving from HTTP to HTTPS is setting a referrer policy. Most people accept as fact that you lose the referral value when going from an HTTPS website to an HTTP website, but you don’t have to lose the referral value on downgrade requests if letting insecure websites know that you sent them traffic is important to your business model.

Referrer Policy options

  • No-referrer — No referrer information is sent.
  • No-referrer-when-downgrade — This is the default behavior if no policy is specified. It always passes the full path and will pass a value from HTTPS > HTTPS but not HTTPS > HTTP.
  • Origin — Sends the domain but not the full path.
  • Origin-when-cross-origin — Sends the full path when on the same domain, but only the domain when passing to another website.
  • Same-origin — Sends the full path if it’s the same domain, but strips the value if going to another website.
  • Strict-origin — Sends the domain for HTTPS > HTTPS and HTTP > HTTP, but not HTTPS > HTTP.
  • Strict-origin-when-cross-origin — Sends the full path if on the same domain and from one secure page to another, sends the domain if going from HTTPS on one domain to another domain, and doesn’t pass if going from a secure domain to an insecure domain.
  • Unsafe-url — Sends the full path.

Mozilla has a good table explaining how each of these works here:

Google uses “origin,” which shows the referring page as https://www.google.com/ for any of the Google search results pages, for instance.

One thing to note is that the Referral Policy doesn’t have full support from all browsers, so some information still may not be passed. You can check for support at https://caniuse.com/#feat=referrer-policy. If you suspect you are losing some analytics data or have a need to pass the referral value, it may be time for you to investigate Referral Policy further.


Opinions expressed in this article are those of the guest author and not necessarily Search Engine Land. Staff authors are listed here.


About the author

Patrick Stox
Contributor
Patrick Stox is a Product Advisor, Technical SEO, & Brand Ambassador at Ahrefs. He was the lead author for the SEO chapter of the 2021 Web Almanac and is a reviewer for the 2022 SEO chapter. He’s an organizer for the Raleigh SEO Meetup, Raleigh SEO Conference, Beer & SEO Meetup. He also runs a Technical SEO Slack group and is a moderator for /r/TechSEO on Reddit.

Get the must-read newsletter for search marketers.