4 ms·
I had always assumed they did this for financial reasons. The hash won't be sent along as part of the referrer header, so the search query won't be available t
by jasonkester 10y ago
I had always assumed they did this for financial reasons.
The hash won't be sent along as part of the referrer header, so the search query won't be available to 3rd party analytics. The only way to track search queries is to use Google's own analytics, which can correlate queries to traffic since it's watching both ends of the handoff.
The technical explanation discussed in this thread is certainly valid. But it only explains what is happening. The question posed was "why". Why would a search engine implement a design that would have the effect of removing the query string from referrer headers?
Answer that, and you'll answer your question
- shezi 10y agoThere are good technical explanations of the behaviour in the comments. And the observed behaviour is that only subsequent queries get put in the hash instead of the query. The why is also addressed by the comments (IE only got support for pushState after the solution was already built). Besides, for a long time, Google added intermediate pages when you clicked through a search result, adding the appropriate referrers right back in. I don't think you need to attribute this behaviour to malice when a simple technical explanation suffices.
- jessaustin 10y agoIf that's "malice" then everything Google does is malicious. There's nothing wrong with doing something for multiple reasons. It seems exceedingly unlikely that "now we can control Referer" never came in search product discussions.
- currysausage 10y agoIf you click a search result, you still have a google.com/url?… redirector in between, so hiding the search term in the hash wouldn't really be necessary.