14 replies to this topic

[rolf]

I'm just doing a rough design of an A/B split test I intend to carry out and I'm concerned that G may pick up and rank the new version of the page before I've decided which version is best.

The new version may not rank quite as well for one of my busy phrases, but I'm hoping it will convert better on the other busy phrases (this is, of course, the point of doing the test) - but what happens if I'm wrong and the end result is that I get indexed lower for one of my busy phrases and no improvements in other areas?

[1dmf]

I'm no expert but I believe google uses Javascript to make split testing work, as it's generally understood the G! bot doesn't trigger JS, I'd have to assume the page is indexed as is without any JS running.

To see what the G! bot is likely to see, use firefox with JS disabled and view the page in question and its source, what you see is likely to be what G! bot sees.

Unless others know different of course

[rolf]

D'oh, **slaps forehead** it's so obvious when you say it - and even if it's not set up like that by default, I can easily use a bit of JS to get the same result.

I knew all those things, I think I just needed someone with a bit of common sense to put it together for me! (forgive me, it's been a long week)

cheers 1dmf.

[1dmf]

no probs.

we all have those "can't see for looking moments", it's every day for me

[Randy]

Even if you don't use a JS-based testing solution it's not a huge concern Rolf. The ones I've been using for years aren't JS based, so Google could actually see the conversion testing changes on the page, but since every time they visit they'd get a slightly different version it doesn't throw much of a monkey wrench into things. You may need to do a tiny bit of SEO on-page tweaking once you settle on a winner on the conversion analytics side of things.

Typically if you're testing conversion alone you're not really fooling with stuff like page titles. You can test those to see which drives more clickthru's, but that's kind of another type of testing. Titles just don't drive conversions on the back end in my experience.

So if you're not changing the <title> and the phrases you're targeting are still in the content in prominent places, I doubt you'll see much if any ranking effect during your test.

FTR, those times I'm running conversion tests on a prominent traffic driving page is the one time I do actually track rankings. Not so much for use during the test itself, but so that I know where rankings were before I started testing and where they end up after I've settled on a CT winner. And yes there have been times where I've tweaked the winner slightly to improve rankings a bit back towards where they were before.

[Michael Martinez]

Google is now indexing Javascript. I would not try to embed anything in Javascript you don't want Google to index.

[1dmf]

Google is now indexing Javascript.

Do you mean they are indexing the text (code) of the Javascript, or they are firing the Javascript and indexing the result?

[Randy]

Hard to say without seeing what their bot is seeing on the back end 1dmf, but they have said they have some JS enabled Googlebots out there scurrying around now. Which to me would mean they're probably parsing/processing at least some javascript.

No clue whether that means they'd be processing off-domain js calls or not. Or if they'd do that and count it as content for the target domain's page. Flip a coin on that question.

[Michael Martinez]

The only specific text-related statement I have seen from anyone at Google concerning their Javascript capability is that anchor text will now be passed (for links that are allowed to pass value). Not all Javascript links will pass value, as they know about some advertising and affiliate networks and have indicated they will ignore those.

But if Google can pass anchor text from a Javascript link then it follows that they can parse at least some of the text out of the Javascript. I have no idea of how much they can do.

[Randy]

I understand what you're saying Michael. And agree up to a point. The problem is that the statements we've both seen and heard do not go nearly far enough to tell us much where a question like this one is concerned.

I certain can agree that Google can and does see, if not exactly process something simple like a document.write() section of Javascript. And that they have the ability to both recognize and extract normally formated linking code and normally formated anchor text from those types of javascript links.

I have a feeling this is the type of situation they're describing when they say the anchor text can pass value in JS links. Where all of the info necessary for them to extract information is right there in the source code in plain old text.

However being able to extract a url string and anchor from a simple string of data that actually appears in the html source is a completely different level of difficultly from something like a javascript based conversion testing software suite.

With the latter there is typically very little, usually none, of the actual content appearing in the code. Instead there is a javascript that references a unique text string that means nothing, other than the fact that it's the test id in the back end database. And using this test id number some processes run in the background at page load that retrieves information from a database and drops it in the page for JS enabled browsers. In other words, it's there visually for modern browsers, but not there at all if the browser isn't actually processing the javascript to start the database information retrieval.

Google could and certainly is doing a lot of the first example. I've not seen any evidence that they're doing the second example, nor have they said enough about it to say that Googlebot is capable of actually processing more sophisticated javascript like is used in conversion tools.

Both are certainly javascript. But it's really apples and oranges.

[Michael Martinez]

Oh, you're right, Randy. I don't mean for it to sound like I know something I don't.

I'm just saying that if you don't want Google to index a specific block of text, I don't believe you should be using Javascript to publish that text. If you want certainty then doing something with an uncertain outcome is not advisable.

That's all.

[Randy]

Yup, yup. Completely agree Michael.

The old JS way of hiding something from the bots isn't a wise idea anymore these days.

[1dmf]

So are they trying to capture stealth tactics rather than actually wanting the result the end user sees?

AJAX is a prime example that if you don't execute and process the response, the page won't contain any content hwta so ever other than a blank div.

It's not stealth, it's AJAX to perform DHTML, and it doesn't necesarily contain a document.write or other JS style content command.

myObject.innerHTML = myHTML;

unless executed will mean absolutely nothing to G! as plain text for indexing.

Also does G! download the JS file and index it as a JS file to be provide in the SERPS, I'm not happy if it does, ok I know the JS code is available on the WWW, and I know you should use robots.txt to block unwanted files being indexed.

But there is just no need and it's wrong to arbitarily index peoples JS files, i've not come across this yet in any of my SERPS, but if G! is now indexing JS, will this start to happen?

[Randy]

I've not seen evidence of Google indexing .js files and showing them in the SERPs, no. They do show some if you do a search like keyword filetype:js but when I last looked all of those examples are actual examples of js code. Meaning it's code being shown in an html page, not simply linked external javascript.

And you've hit on one of the things I've actually looked at from time to time. That being AJAX driven sites. Their content simply doesn't get fully indexed if the AJAX isn't developed in such a way to make it accessible (via different urls) for non-js compliant browsers.

Now of course none of this means that Google isn't grabbing those .js files and doing something with them internally that doesn't show up in the SERPs. If you asked me to guess, I'd say they probably are doing exactly that. And doing it for the purpose of catching sneaky stuff that flies in the face of their quality guidelines. After all, that's how most of the really widespread Google SERP Hacks have been implemented over the past few years. And it's also how most badware is getting distributed these days. So it would make sense for them to grab that JS code and analyze it.

Oh, and for the record I don't believe encrypting the js does anything to stay out of harms way with Google. I have seen plenty of evidence with badware stuff where the js was encrypted, but Google still picked up the actual site address people were being forwarded to. So encrypting sneaky stuff isn't going to keep if from being discovered.

[1dmf]

Who knows what they really get up to!

But I'm still not sure G! could index dynamic DOM updates via AJAX calls even if it triggered the JS.

If you view the source markup after a DOM update the content isn't there for normal viewing, so I guess the same would be said for the Google bot!