Зачастую специалисты по маркетингу создают для одного URL несколько различных вариантов контента, чтобы посмотреть, который из них лучше. Это обычный текущий процесс оптимизации, который приводит к наличию множества различных вариантов. Такой процесс называется вариантным тестированием (split testing).
Проблема с раздельным тестированием состоит в том, что при неправильной реализации оно может привести к значительным сложностям. При реализации изменений на странице необходимо проанализировать три важных эффекта.
1. Вариации производительности страницы в результатах поиска.
2. Вариации в CTR страниц.
3. Вариации в коэффициенте активного посещения для посетителей, которые заходят на вашу страницу (основное назначение вариантного тестирования).
Для повышения коэффициента активного посещения (conversion rate — процент
конверсии посетителей сайта в конечных потребителей — Примеч. пер.) совсем не обязательно жертвовать CTR или рангом. Но если вы выполняете вариантное тестирование, лучше знать о таких возможных последствиях.
Это усложняет дело, поскольку добавляет в уравнение производительности дополнительные факторы. Например, если коэффициент активного посещения в два раза больше, но при нулевом ранге, то, в общем, это хуже для сайта, для которого выполняется органичный поиск. Поэтому при выполнении вариантного тестирования следует учитывать принципы поисковой оптимизации.
В идеале все изменения должны быть просто эстетическими. В большинстве случаев они не должны влиять на ранг или CTR страницы — что облегчает анализ полученных результатов. Если изменения более существенны — например, изменение контента страницы — то это может повлиять на поисковый ранг, что также следует учитывать как фактор производительности.
Один из методов, применяемых для сбора данных при вариантном тестировании —
это случайный вывод страницы А или страницы В и отслеживание коэффициента активного посещения для каждой из них. К сожалению, при неправильном выполнении это способ может запутать поисковые механизмы или вовсе поднять красную карточку. С вариантным тестированием связана и другая проблема: в худшем случае его реализация может быть расценена как рассылка спама и/или маскирование.
Для вариантного тестирования применяются три различных подхода.
1. Случайное перенаправление запросов к странице на другие страницы с вариациями контента.
2. Использование внутренней программной логики для случайного вывода вариаций. 3. Реализация раздельного во времени тестирования.
Первые два метода похожи тем, что они случайным образом выводят различные
вариации страницы. Однако в данной ситуации перенаправления не являются идеальным средством, т.к. они могут запутать поисковые механизмы, и поэтому их следует избегать. По этой причине мы рекомендуем пользоваться внутренней программной логикой. Это согласуется с рекомендацией Мэтта Каттса в его видеообращении по адресу http://video.google.com/videoplay?docid=l156145545372854697.
Программирования для этого нужно немного. К примеру, если имеется пять версий
Web-страницы— page [ 1. . 5 ] . php— то для вывода этих вариаций можно использовать функцию include():
$id = rand(1,5);
include('page' . $id . '.php');
// далее идет код замера производительности
Но проблема все-таки остается: при наличии существенно различных и случайно
выдаваемых страниц это может быть расценено как маскирование. Мэтт Каттс также говорит об этом в вышеупомянутом видеообращении.
Маскирование можно использовать для вывода только одной версии конкретному
поисковому механизму. Это снимает проблему, когда поисковый ранг какой-то версии выше, чем других версий. Кроме того, это теоретически устраняет возможность того, что все версии будут расценены как спам (пока вас не засекли!). Да, маскирование используется для "маскирования маскирования"! Но мы рекомендуем применять этот способ с осторожностью, поскольку Google не одобряет его.
В любом случае — если вас засекли, вас могут поставить в угол. Дополнительная
информация о маскировании приведена в главе 11.
Последний метод — раздельное во времени тестирование — также реализуется
безопасно и очень легко. Просто собираются данные за какой-то промежуток времени (например, за неделю) для варианта А, а затем весь процесс повторяется для варианта В. Однако этот способ может оказаться менее точным и потребовать больше времени на сбор данных.
Итак, ниже дано резюме.
1. Не игнорируйте органичные (возможно, отрицательные) эффекты вариантного
тестирования.
2. Применяйте внутреннюю программную логику или раздельное во времени тестирование. Не используйте перенаправления.
3. Маскирование можно применять для вывода поисковым механизмам только одной версии, но Google не одобряет этот подход.