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 noreferrer” on links with target=”_blank”. This has since been changed to remove the noreferrer 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 noreferrer. 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 noreferrer” 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 noreferrer will not have any impact on your SEO, but noreferrer 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 noreferrer 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 noreferrer 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 http://ift.tt/1UfCGuI. 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.
Some opinions expressed in this article may be those of a guest author and not necessarily Search Engine Land. Staff authors are listed here.
No comments:
Post a Comment