Forum Moderators: Robert Charlton & goodroi
About 7 years ago, in the classic "3 characters from done [webmasterworld.com]" thread we had talked about the ramifications on seo of se's switching from GET to POST'ed data. However, it never came to pass that browser programmers would allow an unchecked form "post" submission. However, the hiding or obscuring of referral data is nothing new:
March 2002: [webmasterworld.com]
Both AOL and Overture routinely encode urls and session strings. There are some meta engines and java script based forms on engines that already hide referral strings. Most of us have seen this effect from search MSN already.
I honestly don't think G is shortsighted enough to do something like that system wide for the sake of obfuscating seo efforts. Websites would have little incentive to look to Google for traffic or optimize for Google. The focus would no longer be on Google for optimization. We wouldn't know what or how to optimize for keywords - optimization would be shots in the dark. Our only option would be to look for other big sources of traffic [webmasterworld.com].
There has always been the unwritten trust between websites and search engines that they could use our data, as long as they sent us traffic. Refererless traffic pretty much breaks that unwritten but implicitly agreed upon trust and treats websites as commodities - just food for the engine.
On the other hand, we have to respect a websites - even Google's - opportunity to innovate. I think we have to see what G is doing with the Ajax before passing final judgment on it and it's intentions. I doubt that it is Googles will to break log analyzers and keyword trackers with this test. I think that is a by-product of whatever Ajax implementation google is currently testing.
On the third hand, it would probably drive alot of webmasters to look to AdWords for traffic. hmmm
Incidentally, using a US IPand with cookies disabled, I can consistently retrieve AJAX results by visiting a URL with the following syntax:
[google.com...]
The value of fp appears to be irrelevant as long as it's present. Google also adds an additional parameter (e.g. &cad=[a-z]) for the AJAX searches.
Regarding the fragment identifier (in JavaScript it is the window.location.hash property) and some of the questions of what can and cannot be done with the hash, I wrote a small chunk of html with JS when I first looked into this. True, the hash and anything after it never leave the browser. You can change it within the browser session though. Many of us have noticed this by following a named anchor if we have ever navigated a large page with "return to top" style layout. However, it can also be changed using JS, which is exactly what G is doing in this case. Here is a small sample of HTML for demonstration:
<html>
<head>
<title>Fragment Identifier</title>
<script type="text/javascript">
var d = document, w=window;
window.onload = function()
{
d.getElementById('p').style.display = 'none';
d.getElementById('p').style.visibility = 'hidden';
d.getElementById('chg').style.display = 'none';
d.getElementById('chg').style.visibility = 'hidden';
d.getElementById('nxt').style.display = 'none';
d.getElementById('nxt').style.visibility = 'hidden';
d.getElementById('a').onclick = function()
{
d.getElementById('p').style.display = '';
d.getElementById('p').style.visibility = '';
d.getElementById('chg').style.display = '';
d.getElementById('chg').style.visibility = '';
}
d.getElementById('chg').onclick = chgLoc;
d.forms[0].onsubmit = function() { return false; };
}
function chgLoc()
{
w.location.hash = 'anchor';
var nxt = d.getElementById('nxt');
nxt.style.display = '';
nxt.style.visibility = '';
nxt.style.background = "yellow";
d.getElementById('anchor').focus();
}
</script>
</head>
<body>
<p>
Look at the browser bar and notice no fragment identifier.
Click on <a id="a" href="#button">this link</a> to jump to the next
paragraph. The page is so short you likely will not see any movement in
the browser display so the paragraph is hidden until you click the link.
</p>
<p id="p">
Now that we have a fragment identifier in the browser address bar, see?
Click the Change location button to watch it change and bring you to the
next anchor link in the page.
<form method="post" action="">
<button name="chg" id="chg" value="chg">Change location</button>
<fieldset id="nxt">
<legend></legend>
After clicking the Change location button your browser will
bring you here and this fieldset turns yellow. You will also
see <a id="anchor" href="#button">this anchor</a> is now in focus.
</fieldset>
</form>
</p>
</body>
</html>
More info on window.location here (oddly enough, notice the example on this page):
[developer.mozilla.org...]
G has used a regular expression to modify the window.location element to replace the
search?query string. Unless a user has JavaScript disabled in their browser, this technique works just fine and the referer query never reaches your logs.
G has used a regular expression to modify the window.location element to replace the search? query string. Unless a user has JavaScript disabled in their browser, this technique works just fine and the referer query never reaches your logs.
I noticed the regex. What I don't quite get is why if I click search, my browser makes a background GET request for /search?q= etc. Do I go to that page and then get redirected? that doesn't seem to be the case. I didn't think you could modify window.location without triggering an additional redirect?
I didn't think you could modify window.location without triggering an additional redirect
Test the sample snippet I have there, Andy. Feel free to load the page with a query string first and then use/modify the JS to play around with the window.location property -- you can do quite a bit with the client side code.
coop: got it. The AJAX request is for exactly the same results page (via GET) that would be triggered prior to this test. Then the whole page content is pretty much replaced. So internally at Google, it's pretty much the same as before. Very smart!
Anybody here using GA that can comment in that thread in regards to the discussion here being a possibility for what is being noticed in GA?
Looks like more and more users are getting this "turned on" on their side and even have seen it with one user.
However, as GA is called via google-analytics.com and google ids are stored by google.com it would seem a tricky thing for them to match up. The communication would have to be behind the scenes with the GA server in any case, and it would seem hard to do that reliably.
I use my referrals to help me keep track of my adwords targeted keywords and were they came from, but is seems now I am not able to or will not be able to if this goes through. I use the referrals to check were the traffic is coming from and what terms I am getting hits off of. This really is going to be a problem for me as I assume the only thing now I can look at is from within my campaign stats, and you know it is always good to watch who spends your money and were it is (was) going.
although they do help to track down what you actually showed up forthis is my main intrest I have
words in campaigns that triggered listingscovered.
I use the referrals as a tool to help me determine if I need to shut down a word due to our natural listings and vice versia. Looking in the actual serps helps me in these decisions and as business continues to get tighter and tighter I need to save every penny possible.
In my google analytics, my google.com referrals (non organic) are up about 1000% (ten times the normal amount). Those are the referrals that don't have the string. Looks like google analytics is not capturing those search strings.
Confirmed. I am seeing the exact same result for yesterday. 1000% increase in non-"organic" google traffic in google analytics.
I am using the old analytics code. Can anyone confirm whether the new version of the code gives the same result?
I did track down some spec related to referrers and fragments in RFC 2616 [tools.ietf.org]:
The [referrer] URI MUST NOT include a fragment
There's certainly no functional change in pages that I've seen. The behind the scenes GET request to Google is exactly the same as it was previously. The only difference to Google will be they have no referrer info either, but then they have various other methods of tracking page to page user activity.
Take it for what its worth, since it lacks attribution, and the silence of G on these boards is absolutely deafening.
I have seen the phenomenon under discussion, and except for the hash I can discern absolutely no difference from previous results from a user perspective.
The only difference to Google will be they have no referrer info either, but then they have various other methods of tracking page to page user activity.
Perhaps I am misunderstanding you here, but the query string is indeed passed back to G search during "next page" requests, as you mentioned in the sentence previous to this one -- it is exactly the same. Or are you referring to Google Analytics in particular?
I'm using the new analytics code.
I bet it blows over in a few days and we never hear about it again.
Let's hope so, although for some reason I'm thinking the above quote was first written by Neville Chamberlain...
Because of Javascript malware exploits there is an increasing trend to block Javascript on sites, especially if it's an unknown one. Through lack of technical knowledge or through laziness many people block pretty near all sites (I see examples of this daily). I think people's wariness/awareness at present is low but with every virus caught it is sure to increase to the point where Javascript will be blocked as routine.
The current status of Firefox's NoScript is:
921,785 weekly downloads
41,530,931 total downloads
Firefox currently has between 18% and 50% of the browser market, depending on whose stats you use. No doubt there is or soon will be a similar block app for MSIE.
Another point I think google may try to adopt is to make links active via JS. I visit several sites that work that way and they do NOT get my custom once I hit an inactive link. Presumably google will provide for non-JS browsers (I noted such a comment earlier in this thread).
Many people cannot manage stats for themselves and I doubt most of my customers would be able to manage or understand GA: some can barely manage to hit the Compile Stats button on their web sites.
Many people don't like visiting GA-enabled sites because of the sluggishness of GA itself.
Is it possible google are driving down a blind alley?
Just my tuppence-worth.
/google-analytics.com/ga.jsI probably see upwards of 150/200 of those per day on sites that I monitor that type of activity. We've narrowed it down to the second GA call failing but that is about it. Would this Ajax thingy have any affect on those JS calls?
< Don't let that post count fool you, I'm still a noob!
Don't think they're related at all. I believe the issue you mention stems from when some javascript clients choke on a portion of the Google Analytics code (it screws up on the http/https detection), which makes the request URL for the ga.js include relative to your site as opposed to absolute to Google's site.
Many people don't like visiting GA-enabled sites because of the sluggishness of GA itself.
Anyone feeling like a guinea pig right about now?
I'm feeling like I should call up my friendly fellow "watchdog" who just so happened to be appointed to the POTUS's cabinet this month and leave a little "irritating buzz" in his ear about Goog.
I've had enough of it!
They want to play? Then let's play!
Shouldn't the no-archive tag fix that, no cache - no preview, the user HAS to click to read and users are curious fellows.
