homepage Welcome to WebmasterWorld Guest from 54.167.173.250
register, free tools, login, search, pro membership, help, library, announcements, recent posts, open posts,
Pubcon Platinum Sponsor 2014
Home / Forums Index / Google / Google SEO News and Discussion
Forum Library, Charter, Moderators: Robert Charlton & aakk9999 & brotherhood of lan & goodroi

Google SEO News and Discussion Forum

This 174 message thread spans 6 pages: < < 174 ( 1 2 3 [4] 5 6 > >     
Google AJAX Powered Serps Kills Referals
Brett_Tabke




msg:3841738
 2:56 am on Feb 4, 2009 (gmt 0)

Story on Clicky [getclicky.com] about Google testing ajax powered SERPs. I believe the finders credit goes to this story [smackdown.blogsblogsblogs.com]. I think it is a major story. It has big implications for site owners and webmasters.

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

 

Receptional Andy




msg:3842909
 12:30 pm on Feb 5, 2009 (gmt 0)

The fp parameter seems to be connected with this - without it I get redirected to the traditional GET results.

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.

coopster




msg:3842916
 1:16 pm on Feb 5, 2009 (gmt 0)

Correct, you can change the fp argument and paging still works fine within the same search results, or at least appears to work just fine.

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):
https://developer.mozilla.org/en/DOM/window.location

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.

Receptional Andy




msg:3842917
 1:19 pm on Feb 5, 2009 (gmt 0)

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?

Brett_Tabke




msg:3842920
 1:32 pm on Feb 5, 2009 (gmt 0)

We ended up with about 6% without referring urls from Google yesterday. That was on over 100k in referrals. So that is a pretty significant "test".

coopster




msg:3842923
 1:38 pm on Feb 5, 2009 (gmt 0)

It's a whole lot of work to be "not a test", I'll say that much :P

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.

Receptional Andy




msg:3842931
 1:49 pm on Feb 5, 2009 (gmt 0)

Google have always been a fan of large scale live tests. Certainly this is large-scale enough to make it much less likely that it's not going to go any further.

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!

coopster




msg:3842946
 2:16 pm on Feb 5, 2009 (gmt 0)

An interesting post was started in Website Analytics - Tracking and Logging titled
Tracking traffic sources [webmasterworld.com]
Why does google analytics gives you a source you can't track?

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?

zuko105




msg:3842995
 3:21 pm on Feb 5, 2009 (gmt 0)

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.

Looks like more and more users are getting this "turned on" on their side and even have seen it with one user.

Receptional Andy




msg:3843026
 3:53 pm on Feb 5, 2009 (gmt 0)

Getting specific data out of GA is like pulling teeth, so I'm having a hard time verifying that GA is also broken by this (having to hack around to get a full referring URL? Sheesh).

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.

bwnbwn




msg:3843037
 4:04 pm on Feb 5, 2009 (gmt 0)

I have been reading all the post and 1 topic I am looking for is how will I verify were the traffic came from google serps or Google adwords.

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.

Receptional Andy




msg:3843040
 4:07 pm on Feb 5, 2009 (gmt 0)

bwnbwn: you should be using tracking URLs (e.g. www.example.com?src=adwords&kw=keyword) to monitor paid camapigns - referrers have never been reliable for this, although they do help to track down what you actually showed up for, as opposed to the words in campaigns that triggered listings.

2clean




msg:3843042
 4:07 pm on Feb 5, 2009 (gmt 0)

Usual G Practice. Don't announce something, let the community run awol with it. Pickup any bits that could be useful.....
And then just go ahead with it regardless.

Brett_Tabke




msg:3843072
 4:31 pm on Feb 5, 2009 (gmt 0)

The fact that people are finding the code and there is no new functionality on the page, is very interesting. hmmm

bwnbwn




msg:3843085
 4:39 pm on Feb 5, 2009 (gmt 0)

Receptional Andy
although they do help to track down what you actually showed up for
this is my main intrest I have
words in campaigns that triggered listings
covered.

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.

freejung




msg:3843144
 5:37 pm on Feb 5, 2009 (gmt 0)

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?

Receptional Andy




msg:3843152
 5:43 pm on Feb 5, 2009 (gmt 0)

I hear you, bwnbwn.

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.

willybfriendly




msg:3843188
 6:28 pm on Feb 5, 2009 (gmt 0)

Came across a blog that provided an unattributed quote from "a Google rep" saying that this was intended to provide "faster" results, that it was a test, and that it is not G's intent to interfere with referral data.

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.

coopster




msg:3843238
 7:15 pm on Feb 5, 2009 (gmt 0)

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?

zuko105




msg:3843311
 9:06 pm on Feb 5, 2009 (gmt 0)

@freejung

I'm using the new analytics code.

freejung




msg:3843323
 9:24 pm on Feb 5, 2009 (gmt 0)

Then it would appear that Analytics is not immune from this problem, which I would take as good news. If Analytics still worked, this could be seen as a move to drive out competition. As it is, it looks more like an unintended consequence of an experiment.

I bet it blows over in a few days and we never hear about it again.

steveb




msg:3843390
 11:24 pm on Feb 5, 2009 (gmt 0)

"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...

dstiles




msg:3843394
 11:26 pm on Feb 5, 2009 (gmt 0)

To me it looks as if the people developing this stuff are not talking to their security people.

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.

pageoneresults




msg:3843430
 2:02 am on Feb 6, 2009 (gmt 0)

Is it possible that failed GA calls (404) are part of this? I've been getting them for over a year now and recently they've increased a bit.

/google-analytics.com/ga.js

I 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!

Chico_Loco




msg:3843477
 4:10 am on Feb 6, 2009 (gmt 0)

pageoneresults,

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.

MatthewHSE




msg:3843485
 4:20 am on Feb 6, 2009 (gmt 0)

Many people don't like visiting GA-enabled sites because of the sluggishness of GA itself.

I won't use it on my sites for that very reason. It drastically slows down every page load, and somehow or other the rest of the page won't render until GA has loaded.

skipfactor




msg:3843841
 3:58 pm on Feb 6, 2009 (gmt 0)

I'm not seeing the "test" anymore.

Receptional Andy




msg:3843845
 4:04 pm on Feb 6, 2009 (gmt 0)

I've seen a decrease in these referral today, also.

randle




msg:3843862
 4:26 pm on Feb 6, 2009 (gmt 0)

Anyone feeling like a guinea pig right about now?

whitenight




msg:3843961
 5:43 pm on Feb 6, 2009 (gmt 0)

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!

Dave_Hybrid




msg:3844001
 6:43 pm on Feb 6, 2009 (gmt 0)

Re: The idea of Goog using some for of website preview...

Shouldn't the no-archive tag fix that, no cache - no preview, the user HAS to click to read and users are curious fellows.

signor_john




msg:3844034
 7:19 pm on Feb 6, 2009 (gmt 0)

Shouldn't the no-archive tag fix that, no cache - no preview, the user HAS to click to read and users are curious fellows.

Beats me, but if I were a user digging my way through the SERPs, I wouldn't bother with Web sites that played hide-'n'-seek--I'd make my choices from the previewed sites, unless the previews didn't reveal any useful content.

This 174 message thread spans 6 pages: < < 174 ( 1 2 3 [4] 5 6 > >
Global Options:
 top home search open messages active posts  
 

Home / Forums Index / Google / Google SEO News and Discussion
rss feed

All trademarks and copyrights held by respective owners. Member comments are owned by the poster.
Home ¦ Free Tools ¦ Terms of Service ¦ Privacy Policy ¦ Report Problem ¦ About ¦ Library ¦ Newsletter
WebmasterWorld is a Developer Shed Community owned by Jim Boykin.
© Webmaster World 1996-2014 all rights reserved