Often, marketers want to create several variations on content for a particular URL in the interest of observing which one converts the best. It is typically an ongoing optimization process, and many different variations may be served over time to that end. This is called split testing.
The problem with split testing is that it cannot be considered in a vacuum. First:
1. Page A may perform better than page B with regard to conversions, but:
2. Page A may perform more poorly in the SERPs.
Obviously, this can complicate matters, as it introduces another factor into the performance equation. For example, if a page converts twice as well, but doesn't rank at all, it is a net loss. Therefore, search engine optimization principles must be considered when making any changes.
Ideally, all changes would be purely aesthetic; and in most cases doing so would not affect the rank of the page. If they are not, it creates a complication for this reason, as changing on-page content can clearly influence rankings; but there is another reason, too. Keep reading.
One method employed to collect data for split testing is to randomly show page A or page B and track conversion rates for each. Unfortunately, done incorrectly, this practice can confuse search engines or raise red flags. This is the other problem with split testing. At worst, implementing this will be perceived as spamming and/or cloaking. Let's examine the 3 different ways to split test.
1. Redirects directed to the variations randomly
2. Internal program logic displaying the variations randomly
3. Temporal split testing
Methods 1 and 2 are similar in that they randomly display variation A or B. However, redirects are not ideal in this situation, and they can be avoided. Therefore, I recommend using internal program logic. This is consistent with Matt Cutts' recommendation in his video (http://video.google.com/videoplay?docid=1156145545372854697). That means some light programming --
For example, if you have 5 versions of a web page, page[1..5].php,
$id = rand(1,5);
include('page' . $id . '.php');
// tracking program application code here.
The problem regardless is that if the pages are significantly different and served randomly, it might actually be perceived as cloaking. Matt Cutts hinted at that in the aforementioned video.
Cloaking may be used to show only one version to a particular search engine. This eliminates the problem whereby a certain version ranks better in search engines than others. It also eliminates the possibility that it will be perceived as spam academically (so long as you're not detected!). Yes, cloaking is being used to prevent the perception of cloaking! However, I'd recommend doing this with a caution that Google frowns upon it.
Either way, if you're detected, you might be sent to the corner. For more information on cloaking, click here.
The last method, "temporal split testing," is also safe, and extremely easy to implement. Simply collect data for one timespan for A (perhaps a week), and again for B. However, doing so may be less accurate and requires more time to make determinations.
So, in summary:
0. Don't ignore the organic, possibly dertrimental, effects of split testing.
1. Use internal program logic or temporal-based split testing. Do not use redirects.
2. You may use cloaking to show only one version to search engines, but Google frowns upon this approach.












November 14th, 2006 at 12:35 pm
As you say one version of the site ranks better. One version converts better. As you surely know that´s just why people are blackhat cloaking.
That´s the reason why in my opinion cloaking is not a good advice for sole testing purposes.
I think it´s less dangerous changing the content a few times for a period then cloaking your page.
Maybe another testing approach is to send your articles to your newsletter readers before posting it in your weblog.
The advantage is that you can create several headlines and article-bodys with similar onpage-metrics and then split test them at your newsletter audience.
Later if you know the best fitting combination you may post the article and maybe tweak it after it is index and ranked.
November 14th, 2006 at 12:39 pm
I see it as an innocuous form of cloaking, personally.
But I do see your point. If you aim to optimize both ends, you'll be spamming and cloaking.
Point taken. Thing is, to AB test, it's not changing a few times -- it's changing randomly. The irony is, I suspect that can be surmised as cloaking. Matt Cutts stopped short of saying that in one of his videos; but it makes sense.
The safest approach, I'd say, is temporal -- if you can stomach it.
November 16th, 2006 at 5:11 am
I get that it´s not your intention to tweak rankings by this method but in my opinion you can´t draw a real clean line to practical adapt this.
The temporal testing approach seems more safe. But how do you want to test onpage factors that way?
Tweaking after the first buzz may be fine. But if you want split testing different content-bodies and Headlines you need to test each of it in several ranking performance runs to compare influence on rankings regarding this is not happening in a vacuum.
So if you go this way you will only be able to have the best fitting version for conversion AND ranking a few weeks after you released your article. Doing the following before launching your article should be a good way to fix this.
- create versions 3 or 4 versions of your copy with similar onpage metrics
- do some split testing runs on smaller parts of your email audience
- compare best testing results and select the better 2
- mix up headlines
- return testing
- compare best testing results and select the most appealing headline and the most converting article body.
- tweak your article for ranking purposes
- return testing conversion rates
- repeat the last 2 steps a few times
Based on how many email subscribers you have this will result in 1 or maybe 2 days of testing before your can release an mostly optimized article.
What do you think?