Google not sending any referer data on iOS default search?

UPDATE: Good discussion now on SEL.

Summary: When going from HTTPS to HTTP sites, browsers don’t pass any referer information. When a wired user clicks a result on https Google, Google is doing an internal redirect to an http page THEN sending the user to the search result they clicked on. This redirect allows a referer (with keyword stripped by Google) to be passed.

On Google’s mobile HTTPS version, this first redirect is NOT happening, thus the complete referer is stripped when clicking on a search result.

This appears to be a Google issue, not an Apple issue – and is just made worse by the fact that iOS6 defaults to the https version of google mobile.

While doing some mobile site testing the other day I stumbled upon an interesting happening. I couldn’t find any blog posts or announcements about this, so I’m writing up what I’m seeing.

It would seem that Google is not passing any HTTP_REFERER data For those who have Google as their iOS6 default search engine (Note: I haven’t tested in previous iOS versions. Second note: In my tests, Bing was passing this information.) That means that when it comes to site analytics, mobile visitors searching on their iPhone won’t be tracked as search visitors – they’ll count the same as people who just came directly to your website from a bookmark or by typing it in.

To fully understand what’s happening, let’s look at a couple of examples. To do that, we need a site that’s indexed by Google but that we can safely play with. I’ve got one of those.

For this test, I’ve googled a term (In this case, ‘seotrax’) and then clicked on the link to my test site. Once there, I had the site print out all the server variables passed over so we can see what data is available.

Here’s how normal, web based Google looks:

You can see that the HTTP_REFER value is clearly telling us not only that the visitor came from Google but that their keyword was “seotrax.” This is what most analytics packages look at when tracking your visitors.

But Google SSL (for logged in visitors) does it differently. Back in 2011, Google started encrypting the searches for logged in users. They were still telling us the visitor came from Google, but due to privacy concerns they wouldn’t pass over the keyword (More info on this via Search Engine Land.)

Here’s what a web-based Google SSL search passes:

We can see the HTTP_REFERER is still set, but the q= parameter for the keyword used is missing. We don’t know what they searched, but it’s still counting as a search.

Now, that brings us to the iOS search box in Safari. Here’s what I’m seeing there:

There is NO HTTP_REFERER at all! This traffic looks the same as somebody who just typed in the URL.

This is ONLY happening for the default search on iOS, and NOT if a user actually goes to Google and searches so I can’t tell if it’s a Google issue or a Safari issue.

Is this a bug? Is this on purpose? I can’t seem to find any Google or Apple documentation on it. Will browsers soon follow this lead? There’s been debate for years about whether or not sending referer data is a privacy violation, is the argument swaying toward total privacy? If so, that means webmasters will have to rely on webmaster tools instead of collecting their own search data. That has significant issues for those who want to tie their SEO data to sales or KPIs too, but that’s a topic for another post.

If you want to run your own tests, all you need to do is search for “seotrax” and click on the “SEOtrax.com” result. I’ll leave it printing out server data. If you have an older iOS device or other mobile platform, I’d love for you to leave a comment about how that works too. Thanks!

UPDATE: @seoaware sent me an email saying her older iOS device IS actually passing a referer value – so this appears to be a new change with iOS6 only.

UPDATE 2: I’ve just pulled some graphs from one of my personal sites. There’s a definite spike on “direct” traffic starting after the 9/19 launch of iOS6 – which is what we would expect to see if iOS6 searches aren’t sending a referer.

7 comments September 26th, 2012