
Ask HN: Why does Google put the query in the URL hash instead of query string? - SimeVidas
Search for something on Google, and the URL will look something like this:<p>https:&#x2F;&#x2F;www.google.com&#x2F;?gfe_rd=cr&amp;ei=some_long_string&amp;gws_rd=ssl#q=something<p>The search query is the `#q=something` part of the URL, whereas other parameters are stored in the URL via the query string (the part between `?` and `#`). Why is that? Why isn’t the search query stored in the query string? Why in the hash?
======
kc10
If you are search from any place (toolbar, addressbar) other than google.com,
your search query would be passed in as a query string.

But once you are already on google.com search page, the entire page need not
be reloaded. So google would fetch the search results for the new search
string via a XHR and update the page.

In fact if you search for
[https://www.google.com/search?q=wonderland#q=alice](https://www.google.com/search?q=wonderland#q=alice),
the webpage would first load the search results for 'wonderland' and once the
page is loaded, there would be another XHR for 'alice' and the DOM would be
updated again with the new results.

~~~
michaelvillar
They could use `pushState` to change the query without reloading the page?

~~~
thomasahle
Would that not remove the possibility for sharing or manually editing the URL?
(I'm asking because I don't know how much cool stuff pushState can do.)

~~~
TazeTSchnitzel
Not unless the server doesn't interpret the URL the same way.

~~~
draw_down
The fragment of a URL is not sent to the server as part of an HTTP request

------
exodust
On a related note, and probably obvious to many, I've just discovered I can
make a nice little link to a one-result search, handy for a bookmark.

Things like current temperature and forecast I don't want a dedicated app for
when a simple search is more efficient...

[https://www.google.com/search?num=1&q=temperature+london](https://www.google.com/search?num=1&q=temperature+london)

~~~
piyush_soni
Yes, and if you're using Firefox, you can this with the knowledge of its Smart
Keywords to create super quick shortcuts!

[https://support.mozilla.org/en-US/kb/how-search-from-
address...](https://support.mozilla.org/en-US/kb/how-search-from-address-bar)

For example, I directly go to Wikipedia's page on "India " by typing _wp
India_ in my address bar using these search keywords, or search images of
birds on google by typing _gi birds_ in it.

(There's a rather cumbersome way to do the same in Chrome as well)

~~~
notzorbo3
It's not that cumbersome in Chrome. Right click the URL bar -> "Edit search
engines" -> Find the search engine you'd like to easily search, double click
the second column and enter a keyword for it. For example, for wikipedia, I
have "wp" as a keyword. In the URL bar, you can just type "wp<tab>" and you
can search wikipedia.

~~~
notatoad
you don't even have to do any configuration. after you've used a search box
that's correctly formatted (like wikipedia's is) chrome automatically offers
you the option to "press tab to search" when you start typing that's site's
url.

~~~
Ajedi32
Yep, I use this feature all the time and I think there's only ever been one or
two sites I've had to set it up for manually. For most sites, Ctrl+T <First
2-3 Letters of Site Name> <Tab> <Search Query> <Enter> works just fine without
me having to configure anything.

------
jasonkester
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
There 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
If 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.

------
Illniyar
As others have said, it's to show the data without reloading the page.

They could of course do it without actually adding anything to the url - but
then it won't be bookmarkable (and refresh would get you back to a page
without results).

They could use the new history pushstate api, but then: 1\. it won't work in
older browsers 2\. if they wanted it to work in older browsers they'll have to
shim it (which ends up using hashes anyway) - and maintain it, and it will add
the the page download size, which google (at least in the main site) take very
seriously.

~~~
oneeyedpigeon
Why would google.com/?q=search-term not be bookmarkable?

~~~
benbayard
OP is saying if you do not update the URL between searches it will not be
bookmarkable. Not, if you update the URL with the actual search term in a
query string. The reason they do not update the URL query string itself is due
to browser incompatibility. Doing it this way they get support for all
browsers released after 2010, whereas they could only support IE 10 or greater
by using History.pushState

------
eschutte2
Because subsequent searches aren't full page reloads. The first search (via
the Chrome URL bar) puts the search in the "q" query string for me.

~~~
k_
> Because subsequent searches aren't full page reloads.

This does not mean google cannot rewrite the url without reloading the page
(via history.pushState). But less browsers supports this [1] (IE9, browsers
from 2009, and some android browsers).

[1]:
[http://caniuse.com/#search=history.pushState](http://caniuse.com/#search=history.pushState)

------
martin-adams
Could it be to hide the query in the referrer? Although I think all clicks go
through Google servers first.

~~~
josteink
Correct. The only service which can provide you with google queries is google
analytics.

So if you want the data, you are forced to help spread the google drag net
across the internet.

~~~
iamchrisle
No. Keywords do not appear in Google Analytics since search switched to HTTPS.
The query strings are dropped going from HTTPS to HTTP. Keywords will show up
as "(not provided)"(Disclaimer: I work at Google but I'm not on the search
team. I do use Google Analytics.)

~~~
spullara
They drop them from https to https using this method as well. In this case,
what is good for the user is amazing for Google. They are the only ones that
get access to the query stream.

------
NKCSS
Anchors are not part of a referer sent to external websites; also, it will not
be logged in webserver logging since it's never sent to the server. Everything
from # on is stripped off and stays on the client. The only way to interact
with it, is via javascript.

~~~
danellis
"never sent to the server"

It's sent in a separate request.

~~~
NKCSS
That's because a request is manually created with javascript; this is not
because it's part of the url. If you append #something to most random url's,
nothing will happen (unless specific behaviour was written to do so).

~~~
danellis
Yes, I know.

------
karol
Pretty sure they do it for search privacy as hash is not usually passed in
"referer" header, so the pages visited from google search will not have access
to the typed query.

------
liveoneggs
I think they did it to reduce stability and occasionally render blank results
pages.

~~~
aaronmdjones
I've lost count of the amount of times I've had to force-refresh the page and
enter my query all over again because of this.

