11–20 of 71 posts
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 , the webpage would f…
Could it be to hide the query in the referrer? Although I think all clicks go through Google servers first.
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.
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 , the webpage would f…
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
That's pretty neat. Didn't know that. Thanks!
Which seems like it could be used to fool someone into thinking there really are no results for a subject.
Or to pretend Google search is broken ;)
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 , the webpage would f…
Interesting that your alice/wonderland example works. Would've thought Google would try to prevent that.
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 , the webpage would f…
Earlier quoted context omitted.
Interesting that your alice/wonderland example works. Would've thought Google would try to prevent that.
I don't think they can - iirc the hash isn't sent to the server, so to it this looks like any other normal query.
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 , the webpage would f…
Interesting that your alice/wonderland example works. Would've thought Google would try to prevent that.
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.