Monday, March 19, 2012 at 4:13 PM
Webmaster level: allProtecting users’ privacy is a priority for us and it’s helped drive recent changes. Helping users save time is also very important; it’s explicitly mentioned as a part of our philosophy. Today, we’re happy to announce that Google Web Search will soon be using a new proposal to reduce latency when a user of Google’s SSL-search clicks on a search result with a modern browser such as Chrome.
Starting in April, for browsers with the appropriate support, we will be using the "referrer" meta tag to automatically simplify the referring URL that is sent by the browser when visiting a page linked from an organic search result. This results in a faster time to result and more streamlined experience for the user.
What does this mean for sites that receive clicks from Google search results? You may start to see "origin" referrers—Google’s homepages (see the meta referrer specification for further detail)—as a source of organic SSL search traffic. This change will only affect the subset of SSL search referrers which already didn’t include the query terms. Non-HTTPS referrals will continue to behave as they do today. Again, the primary motivation for this change is to remove an unneeded redirect so that signed-in users reach their destination faster.
Website analytics programs can detect these organic search requests by detecting bare Google host names using SSL (like "https://www.google.co.uk/"). Webmasters will continue see the same data in Webmasters Tools—just as before, you’ll receive an aggregated list of the top search queries that drove traffic to their site.
We will continue to look into further improvements to how search query data is surfaced through Webmaster Tools. If you have questions, feedback or suggestions, please let us know through the Webmaster Tools Help Forum.
18 comments:
if you really wanted to reduce latency, you would stop using this javascript that loads a google URL before showing the search result that you click on...
John,
I've just read the articles you've linked to & a few other IETF documents to get a little background on this change.
From what I understand of it, Google will include a new meta tag in the source of the search results for user agents that support it (Chrome at the moment but others in the future). This new referrer meta tag will dictate if, when & how the user agent will set the HTTP REFERER header.
What I am unclear on is how this will do any of the following:
a) "automatically simplify the referring URL"
b) "faster time to result"
c) "streamlined experience for the user"
Can you talk to each of those points at all?
As I see it & I could be completely off base with this but where appropriate the user agent is going to set the HTTP REFERER header not unlike it does now. The improvement to speed would only be the absence of a HTTP REFERER header in some instances, not something that a user is going to actually notice surely and the user experience remains unchanged - they clicked a link.
I appreciate that it'll be useful from a privacy stand point, providing a simply way for webmasters to specify that they do/don't want the HTTP REFERER header set for links from certain pages in a site, such as keeping social profile URLs hidden.
Sorry if I've missed the point but it'd be great if you could expand on the above.
Regards,
Al.
I really like to improvement search result to find accurate Webpages.I hope these help you and more understanding what Google is doing.
Alistair: I've been playing with this for a few hours now and I think I get what the a and b points refer to.
The fact that the referring URL will no longer contain any information other than the host URL will make it simpler. No more tons of different values in referrer analytics reporting.
The current secure search includes a redirect to a non secure page that alters the referrer value before the visitor arrives at their requested site. If you log out of Google you do not have that redirect, and it feels much quicker. Removing the redirect from the signed in experience creates a faster trip from search results to requested page.
@Alistair The difference to the current setup is that it would not need an intermediary redirecting page in order to remove the potentially personal content in the query. By having the browser do this on its own, that additional step is no longer necessary.
I may be stupid but I don't even understand the nature of this change. Can you please explain it in plain English for people like me who don't speak Google corporate speak?
What I get now is that I have to use Google Chrome and a new proprietary meta tag to get some "not provided" data back in Google Analytics.
My concern is with the data in analytics and my question is:
Can you guarantee that all traffic from https Google URLs with a referrer of "origin" is exclusive to SSL organic search traffic and that no other Google product will use this method of sending traffic?
I suspect moves like this from Google are to bullet-proof themselves against the risk of the referrer being used to identify the user via something like their G+ profile ID's. I bet there are some smart people out there that have worked out how to do that. I know my theory sounds like a long shot but why else would they keep on at screwing around with referrer data?
Either way, this is an announcement I'd like to see clarification on - in particular how will this affect referrers (if at all) in analytics packages.
Does this mean, that there will be no more not_provided referrers in analytics?
If this means that the (not_provided) keywords go away, it also means that it will be harder to calculate the percentage of users that are actually logged in to Google when searching for you site.
Or will we still be able to calculate that? It seems like an important issue for us who actually take social SEO seriously.
@John Mueller
Does it mean that, from SSL search serp, you go straight to destination page without getting non-SSL-redirect-page? (of course when when UA is modern browser like chrome)
If so, what will it be when user uses non-modern browser for SSL search?
No referrer data at all from SSL search? (because navigating SSL-page to Non-SSL page will generate no referrer data)
Or, Google reverts mechanism to use redirect page for non-modern browsers?
@John Mueller:
Will there be any referrer data for clicks on AdWords ads?
Will this change prevent me from having to click back twice to get back to my search results or will I have to continue using my current work-around of typing www.bing.com into the address bar?
Difficult to say from this post exactly how it will look.
But if Google start using "origin" as the metadata attribute then https://www.google.com/ will be the referrer for logged in searches via google.com. No (query) parameters will be passed, so "not provided" will still be recorded.
You should (to answer @Nikkelin) be able to judge the number of logged in visitors as they will have https google domains as referrer, whereas non-logged-in will have http google domains.
Could you confirm that we'll not be able to make a difference between a Google Shopping Search and a Regular Search?
Thanks
I really like to improvement search result to find accurate Webpages.I hope these help you and more understanding what Google is doing.
I'm very interested to see this begin to come through. However, my concern is with aggregating the "not-provided" data.
For instance, if a site has a handful of visitors, using Chrome, who are logged in. Then there is insight into Chrome usage, the visits are identified via referrer data from the secure URL for Google, mentioned before, and they still get lumped in with "not-provided" data.
Then all others who are logged in, still get lumped in with "not-provided". I feel like in order to be a more insightful webmaster and utilize this data there will have to be a lot of backing out of several data sources.
One would assume this is to improve the experience of users on all levels (i.e. from search to landing page).
Post a Comment