пятница, 10 августа 2018 г.

Лайфхак № 4.1. Универсальный способ определения геозависимости запроса в Яндексе – восстанавливаем утраченную работоспособность

Геозависимость запроса в Яндексе является одним из важнейших параметров в алгоритме ранжирования. И если вы хотите реально понимать, как ранжируются те или иные запросы, какие запросы будет эффективно комбинировать для одной посадочной страницы, а какие – нет, вам необходимо уметь определять их основные параметры, а не слепо полагаться на результаты работы так называемых «кластеризаторов по топу».
Немногим менее года назад я представил рабочий на тот момент универсальный способ определения геозависимости запроса в Яндексе с использованием только документированных операторов языка запросов. Настоятельно рекомендую внимательно перечесть ту статью, чтобы иметь полное представление о логике данного метода. Вкратце же – этот метод базируется на основополагающем принципе – в выдаче Яндекса для геозависимых запросов в сниппетах наблюдается подстветка топонима, соответствующего региону выдачи, а для геонезависимых – нет. Суть метода заключается в построениие выдачи, в которой для любого проверяемого (исходного) запроса мы сможем гарантировано увидеть на первой странице сниппет, содержащий нужный нам топоним, по наличию подсветки которого мы сможем сделать вывод о геозависимости проверяемого запроса.
К сожалению, упомянутый метод не так давно потерял свою работоспособность. Судя по всему, неожиданным образом потерялась логика группировки запроса на две независимые части по разные стороны от оператора | («логическое ИЛИ»). То есть по факту Яндекс этот оператор игнорирует, и выдачи как с ним, так и без него идентичны:
Вообще, с логикой работы даже документированных операторов языка запросов в последнее время в Яндексе творятся очень странные вещи. Но как бы то ни было, постараемся понять, чем грозит методу подобная реакция поиска на запрос? А тем, что метод уже не является универсальным, и может не давать результатов для целого класса запросов, содержащих в себе такие ключевые слова, для которых на сайте, выбранном для сужения запроса, не найдется релевантных документов. Например:
То есть нам необходимо вернуть потерянную группировку двух частей запроса. Удивительно, но в этом нам может помочь уже официально списанный Яндексом в утиль оператора группировки () («круглые скобки»). О прекращении поддержки этого оператора наряду с некоторыми другими было объявлено 31 января 2017 года, вскоре он исчез из официальной документации. Но, тем не менее, на текущий момент частично сохранил свою работоспособность.
Для начала хочу внести небольшую, но важную поправку к своей предыдущей статье о методе определения геозависимости. Тогда я писал о том, что «изучая свойства геозависимости запросов, я обратил внимание на тот факт, что добавление к исходному запросу через документированный оператор | (логическое ИЛИ) какого-либо достаточно редкого термина (т.е. имеющего достаточно большое значение IDF – обратной частоты встречаемости в коллекции документов)».
Но, к сожалению, забыл добавить, что для корректной работы метода, этот термин с большим IDF должен быть обязательно геонезависимым. То есть геозависимость запроса, состоящего из двух частей, разделенных оператором | («логическое ИЛИ») есть логическая сумма (дизъюнкция) значений геозависимости этих двух частей, при этом значению 1 («ИСТИНА») соответствуют геозависимые запросы, а значению 0 («ЛОЖЬ») - геонезависимые. И поэтому только в том случае, когда добавочный запрос является геонезависимым, геозависимости исходного запроса и конечного составного запроса совпадают.
Правда, в оправдание своей забывчивости я могу сказать, что в подавляющем своем большинстве запросы с большим IDF являются геонезависимыми, поэтому вероятность при его случайном выборе ошибки была невелика. Собственно, выбранный мною добавочный запрос, состоящий из термина arsenaltula, как раз и является геонезависимым, в чем мы убедимся несколько позже.
Итак, конструируем новый запрос, который бы сохранил логику работы предыдущего. Для начала нам понадобится выбрать другой тестовый сайт, так как у сайта, использовавшегося в примерах предыдущей статьи из заголовков страниц исчез топоним «Тула». По подсветке которого в сниппетах выдачи для соответствующего региона «Тула» (lr=15) и определяется геозависимость запроса. Я просто заменю официальный сайт тульского футбольного клуба «Арсенал» на сайт его болельщиков, доменное имя которого отличается от предыдущего только наличием дефиса, и страницы которого также релевантны выбранному добавочному запросу. И, что немаловажно, содержат в заголовках нужный топоним, отображаемый в сниппетах. Заодно по отсутствию подсветки топонима в сниппетах убедимся в том, что выбранный добавочный запрос действительно геонезависим:
Далее пробуем заключить в скобки обе части запроса из предыдущего метода. И, к моему огромному удивлению, получаем опять пустую выдачу:
Эпик фейл? Недокументированный оператор уже не работает? Но не тут-то было! Получается, что при таком применении – да, действительно не работает. Но неисповедимы пути Яндекса, и стоит нам поменять местами части запроса, как мы чудесным образом получаем нужный нам результат.  По отсутствию подсветки в сниппетах говорящий нам, что базовый запрос геонезависим:
Поистине, текущая логика работы языка запросов Яндекса непредсказуема. Сразу же возникает вопреки всякой элементарной логике шальная гипотеза изыскателя – а вдруг подобная рокировка поможет нам и без недокументированных «скобок»? Но не тут-то было, здесь Яндекс остается на удивление логичным:
В общем, получаем понимание, что пока придется-таки использовать недокументированные «скобки». Напоследок убеждаемся, что для геозависимого исходного запроса, новый метод демонстрирует ожидаемую подсветку в сниппетах:
Что позволяет считать его вполне рабочим. В итоге берем новый метод на вооружение вместо прежнего, искренне надеясь, что коварная и непредсказуемая логика языка запросов Яндекса его в скором времени не испортит. Ну, а если и испортит, так все равно сможет найтись достойная альтернатива.
P.S. Замечено, что к сожалению, иногда в Яндексе глючит оператор | («логическое ИЛИ»), и метод выдает пустую выдачу. Но это не проблема метода, а проблема Яндекса. К счастью, пока довольно редко встречающаяся.

вторник, 17 июля 2018 г.

Метод попарного сравнения как способ анализа наложения пост-фильтров

Санкции, применяемые поисковыми машинами к результатам органической выдачи, можно разделить по характеру их действия на две основные группы – пост-фильтры и пред-фильтры.
Суть пост-фильтров заключается в том, что сначала рассчитывается реальное численное значение релевантности документа запросу, а затем из него вычитается некоторая величина (штраф). В отличие от них характер действия пред-фильтров заключается в том, что сначала дисконтируется или вообще обнуляется значение некоторых факторов ранжирования для документа, а затем уже с использованием измененных значений этих факторов рассчитывается значение релевантности.
Одним из способов анализа пост-фильтров является подход, основанный на модификации базового запроса таким способом, чтобы удалить действие пост-фильтров на определенные документы. При этом важно, чтобы модификация не влияла на базовую часть запроса, по которой собственно и рассчитывается релевантность.
Одно время для Яндекса существовало несколько способов подобной модификации. Например, добавление к запросу незначащих символов (таких как точка, запятая или скобки). Или же добавление к запросу через оператор отрицания термина, выдача по которому заведомо пуста (как правило, для этого использовался случайный набор символов, так называемая «абракадабра»). Но рано или поздно почти все эти способы перестали работать.
Кроме, пожалуй, одного – сужения выдачи на меньшее число документов. Возможно, что пост-фильтры отключаются, когда число ответов в ней сравнительно невелико. Что, в принципе, логично с той точки зрения, что искусственное занижение релевантных ответов в такой «короткой» выдаче может способствовать появлению в топе откровенного мусора с околонулевой релевантностью.  
Так, к примеру, сужение выдачи на сайт (так называемый поиск по сайту или «Показать еще с сайта») иногда приводит к смене самой релевантной страницы. Сотрудники службы поддержки Яндекса (собирательным образом которых является Платон Щукин) предпочитают это объяснять тем, что «по служебным запросам при поиске по сайту некоторые факторы могут учитываться иначе, чем при построении общей выдачи». В принципе, гипотеза о снятии пост-фильтров при сужении выдачи вполне укладывается в это объяснение.
Одним из таких методов сужения выдачи для анализа на предположительное применение к сайту пост-фильтров по определенному запросу в Яндексе, является так называемый метод попарного сравнения.
Суть его заключается в том, что документ (или сайт), занимающий определенное место в общей выдаче по запросу, последовательно сравнивается с документами (или сайтами), занимающими места в общей выдаче выше него путем сужения выдачи на два этих документа (или сайта). Если в суженной выдаче исследуемый документ (или сайт) ранжируется выше хотя бы нескольких документов, стоящих выше него в общей выдаче, то делается вывод о наложении на него в общей выдаче пост-фильтра.
Поясню на примере. Так, сайт известной компаний BDBD, в которой я когда-то работал, на момент написания статьи находился в седьмом десятке выдачи Яндекса по региону «Москва» по запросу [продвижение сайтов]:
Место достаточно низкое для такой известной компании, особенно с учетом того, что несколько лет назад этот сайт стабильно занимал первые места в выдаче по этому запросу. В связи с этим напрашивается предположение о применении к сайту каких-либо санкций.
С помощью попарного сравнения можно убедиться, что рассматриваемый сайт опережает в выдаче, суженной на два сайта, многие сайты, которые ранжируются в общей выдаче гораздо выше него, например, во втором десятке:
Стоит заметить, что для сужения выдачи на два сайта используется исключенный из списка документированных оператор группировки () («скобки»). Несмотря на прекращение официальной поддержки, этот оператор сохранил частичную работоспособность и в данном случае прекрасно справляется с возложенной на него функцией.
Безусловно, метод попарного сравнения нельзя назвать стопроцентно точным инструментом анализа наличия пост-фильтров. Однако, на мой взгляд, если сайт при попарном сравнении обходит достаточно большое количество сайтов, которым он уступает в общей выдаче, то это весьма серьезный повод задуматься о том, что с ранжированием исследуемого сайта по данному запросу то-то не так. К сожалению, сейчас служба поддержки Яндекса практически никогда не признает наличия санкций, если об этом нет отметки в сервисе Яндекс.Вебмастер. Поэтому поиск причин наложения санкций становится нетривиальной задачей.





четверг, 7 июня 2018 г.

Изображения в сниппетах десктопной выдачи Яндекса

В конце марта 2018 года в поисковой выдаче Яндекса для десктопов были зафиксированы два важных нововведения в части сниппетов. Во-первых, появилась возможность увеличить текстовое содержимое сниппета (ссылка «Читать еще»):
Причем, сниппет может увеличиться в несколько раз:
А во-вторых, в сниппеттах органических результатов выдачи стали появляться миниатюрные изображения, сформированные на основе содержащихся в документе картинок. Раньше в десктопной выдаче изображения присутствовали только в сниппетах примесей, например, из Яндекс.Новостей или Яндекс.Видео.  Причем, в отличие от изображений в сниппетах примеси, которые располагаются в левой части сниппета, изображениям в сниппетах для органики отведена правая часть:
Изображения в сниппетах показываются для первых нескольких страниц поисковой выдачи, как правило, для топ-30. Самое низкое место, на котором я видел органический сниппет с изображением, было 45-м. Наличие изображений не зависит от геозависимости или степени коммерциализации запроса. Однако для разных запросов число снипеттов с изображениями сильно разнится. Так, например, запрос [продвижение сайтов] в выдаче для Москвы вообще не имеет изображений со сниппетами, а вот для запроса [достопримечательности санкт-петербурга] я насчитал 20 таких сниппетов в топ-30. Исследования показывают, что один и тот же документ может, находясь в топе органической выдачи, иметь изображения в сниппете по одним запросам, и не иметь по другим. Например:
Возможно, вероятность появления сниппета с изображением для документов из топа выдачи каким-то образом зависит от популярности запроса в поиске по картинкам.
Также исследования показывают, что, выбираемое для сниппета изображение, скорее всего, не зависит от запроса. Во всяком случае, мне пока не удалось найти ни одного примера, когда у одного документа по разным запросам были бы в сниппетах разные изображения.
Несомненно, наличие изображения в сниппете делает его более привлекательным, и может повлиять на решение пользователе о переходе на сайт. Поэтому представляется достаточно актуальной задача управлять изображением, выбираемым Яндексом для демонстрации в сниппетах для конкретного документа. Первое, что приходит в голову – возможность указания файла изображения для сниппета в микроразметке, например, с помощью метатега <meta property="og:image" content=... /> (задающего URL изображения, описывающего объект) из поддерживаемого Яндексом стандарта Open Graph.
Однако собирательный образ сотрудников службы поддержки Яндекса Платон Щукин в своем блоге поспешил разочаровать SEO-специалистов:
«Сразу отмечу, что вручную повлиять на появление картинки в поисковой выдаче возможности нет и не нужно специально прописывать картинку с помощью микроразметки. Индексирующий робот самостоятельно выбирает изображение для добавления в результаты поиска со всех представленных на странице картинок. При выборе картинки учитывается множество факторов, среди которых, например, присутствие картинки на Я.Картинках.»
Я провел экспресс-анализ 20 сниппетов из упомянутой выше выдачи по запросу [достопримечательности санкт-петербурга]. В 7 случаях микроразмерка Open Graph не используется. В оставшихся 13-ти изображение в сниппете совпадает с указанным в разметке файлом в 3-х случаях и не совпадает в 10-ти. Если учесть, что картинок на странице, в среднем не меньше десятка, то тот факт, что совпадение случилось в почти четверти случаев, наводит на мысль о его неслучайности. Конечно, выборка очень мала, и в будущем следует проверить на больших данных гипотезу о влиянии микроразметки на выбор изображения для сниппетов. Но тем не менее слова Платона о полном отсутствии возможности влиять на формирование «картиночной» части сниппета можно поставить под сомнение.
Несомненно, факторов, влияющих на выбор картинки для снипетта, не один, и не два. Но ничто нам не мешает их исследовать. И в этой связи я хочу поделиться весьма любопытным сообщением двухлетней давности, оставленным сотрудником Яндекса Дмитрием Вульбруном в блоге разработчиков продукта «Яндекс.Поиск по сайту». Он обозначил ряд требований для того, чтоб картинка могла появиться в сниппете выдачи поиска по сайту (возможность размещения там картинок появилась еще в 2013-м году):
«И еще нужно, чтобы выполнялся ряд требований:
размер картинок не менее 90/90 пикселей;
в урле нет признаков рекламы (слова ad, adv, и прочее, нет ссылок на известные рекламные сети);
картинки не слишком широкие и не слишком высокие (отношение бОльшей стороны к меньшей не более, чем 2);
картинка находится в том же блоке, что и основной контент страницы. Лучше, если она находится внутри текста.»
Полагаю, наработки функционала формирования сниппета в поиске по сайту вполне могли впоследствии использоваться и в основном поиске. Так что, на мой взгляд, мы имеем достаточно неплохой стартовый набор факторов для исследования возможности влияния на «картиночную» часть сниппета декстопной выдачи.


среда, 16 мая 2018 г.

Рекламная мимикрия под фильтром

Во второй половине апреля сего года многие вебмастера, занимающиеся поддержкой так называемых «контентных» проектов, монетизирующихся за счет размещения на своих страницах контекстной рекламы, начали массово получать в сервисе Яндекс.Вебмастер малоприятные сообщения о фатальной ошибке «Малополезный контент, спам, избыток рекламы»:
Судя по активности в теме форума Searchengines.guru, в которой развернулась дискуссия по данной проблеме, количество практически одновременно попавших под данный фильтр сайтов, достаточно велико. Что наводит на мысль об очередном обновлении алгоритма антиспама.
И действительно 24 апреля в блоге Яндекса для вебмастеров появилась запись «О рекламе, которая вводит в заблуждение», которая подтвердила эту версию, внеся некоторую конкретику: «Мы обновили алгоритм, определяющий влияние рекламы на удобство использования сайта, улучшив определение страниц с рекламой, вводящей пользователей в заблуждение и мешающей навигации по сайту (например, маскирующуюся под элементы интерфейса сайта)».
Проанализировав высказывания представителей Яндекса в различных дискуссиях по данной проблеме на различных площадках (в том числе и в блоге Яндекс.Вебмастера), можно с определенностью утверждать, что данное обновление направлено на распознавание рекламных ссылок, которые обладают следующими свойствами:
  1. явно не обозначены, как рекламные, при этом имитируя элементы навигации по сайту, на котором демонстрируются;
  2. описание ссылок не соответствует контенту страниц, на которые они ведут.
При этом сотрудники Яндекса утверждают, что нововведения направлены не против конкретной рекламной платформы. Однако массовость санкций говорит за то, что под них наверняка попадает какой-то достаточно популярный среди вебмастеров формат. И действительно, оказывается, что в указанный паттерн идеально укладывается один из наиболее кликабельных форматов рекламных объявлений системы контекстной рекламы Google Adsense – «Адаптивные блоки ссылок». Во-первых, эти блоки действительно адаптируются под интерфейс сайта, на котором размещаются, во-вторых, нередки ситуации, когда тексты ссылок не соответствуют содержимому страниц, на которые они ведут.
Так, например, вот такой типичный адаптивный блок ссылок Google Adsense, расположенный на странице со статьей про укладку ламината на информационном сайте, неискушенный пользователь может действительно принять за элемент внутренней навигации по сайту:
Малозаметная надпись «Объявления, связанные с запросом» особой ясности для пользователя о том, что этот блок является рекламным, не вносит, да, и появляться она стала не так давно, судя по обсуждению на форуме Searchengines.guru. Тем более такой яcности не вносит микроскопический треугольный логотип ассоциации Digital Advertising Alliance (в которую входит компания Google) в верхнем правом углу рекламного блока. Итак, первое условие для срабатывания нового фильтра – мимикрия под элементы навигационного интерфейса сайта – соблюдено.
К тому же при клике на ссылку данного блока пользователь попадает на страницу рекламного сервиса Google, где ему в большинстве случаев предлагается рекламная ссылка совсем по другой теме:
То есть соблюдается и второе условие для срабатывания фильтра – несоответствие контента целевой страницы содержимому рекламного объявления. Бинго! Можно резать.
Очень похоже на то, что новый алгоритм пытается каким-то образом сопоставить текст рекламного объявления с контентом страницы, на которую он ведет. И в случае наличия несоответствия накладывает санкции на рекламную площадку.  Таким образом страдают не все рекламные площадки, использующие определенный рекламный формат, а только те, которым не посчастливилось разместить у себя рекламные объявления, ведущие на нерелевантный им контент. Этим вполне могут объясняться и сообщения вебмастеров о том, что в ряде случаев пометка о нарушении исчезает без каких-либо действий по изменению формата рекламных объявлений – видимо, в определенный момент вследствие естественной ротации рекламы боты Яндекса просто перестают обнаруживать на сайте «неправильные» объявления.
В общем, как-то так удачно совпало, что один из наиболее популярных рекламных форматов основного конкурента Яндекса идеально подходит под условия срабатывания его нового фильтра. Хочется думать, что это не более чем совпадение.
Справедливости ради стоит упомянуть, что Яндекс и сам отнюдь не лишен в склонности к мимикрии своих рекламных форматов под элементы страниц, на которых они размещаются. Так, например, формат объявлений Директа на странице поисковой выдачи сейчас практически неотличим от сниппетов органических результатов поиска, а пометка «Реклама» рядом с ними становится все менее и менее заметной. Не удивлюсь, что скоро ее можно будет разглядеть только на высокочётких и высококонтрастных мониторах дизайнеров Яндекса. И то, если знать точно, где ее искать. Ну, а собственные сервисы Яндекса, подмешиваемые в выдачу, и вовсе не нуждаются в каких-либо отличающих их от органики пометках:
Точно так же довольно ловко мимикрируют объявления Директа под формат ленты навигации Яндекс.Дзен, отличаясь по сути лишь скромным малозаметным сереньким шильдиком с надписью «Яндекс.Директ»:

А теперь вопрос – многие ли неискушенные пользователи понимают, что «Яндекс.Директ» – это реклама?
В общем, похоже, что своя мимикрия всяко ближе к телу.

пятница, 20 апреля 2018 г.

Яндексовский оператор "минус" - всё?.. Уфф, нет, ещё дышит...

Оставшийся единственным документированным из всех операторов отрицания Яндекса оператор ("минус") внезапно полностью прекратил свою работу.
Причем, в официальной документации по языку запросов он продолжает фигурировать:
Но вот выдача по приведенному в документации примеру демонстрирует его полнейшую неработоспособность. Такое впечатление, что этот оператор просто игнорируется:
Напомню, что в прошлом году прекратили своё существование и исчезли из документации операторы отрицания ~ и ~~.
Интересно, что мы наблюдаем на этот раз – планомерное продолжение политики на урезание функционала языка запросов или же просто очередной пример ставших уже обыденностью глюков и багов?


UPD. Оказывается, что слухи о смерти оператора ("минус"), похоже, слегка преувеличены, и с ним не везёт только залогинившимся в свой аккаунт пользователям Яндекса (спасибо Евгению Кулакову за указание на этот факт). В случае разлогинивания обнаруживается пропащая работоспособность оператора. Правда, только в органике, виджет справа от органики продолжает явно игнорировать оператор отрицания:
Так, что, жив, курилка! Но, похоже, при этом таки серьезно болен…


вторник, 10 апреля 2018 г.

Безвременная кончина директивы Host в Яндексе

Изменения в поисковом функционале Яндекса продолжают демонстрировать стабильную тенденцию на урезание – ничего нового уже давно не добавляется, а вот многое из старого планомерно перестает поддерживаться. В марте текущего года очередной жертвой этого процесса стала директива Host для файла robots.txt.
12 марта 2018 года Яндекс в своем блоге для вебмастеров анонсировал скорое прекращение поддержки директивы Host, а уже 20 марта констатировал сей факт, сопроводив его новыми подробными инструкциями по переезду с помощью 301-го редиректа.
Директива Host как рекомендация для робота-зеркальщика о выборе главного зеркала была введена еще в начале прошлого десятилетия, если не ошибаюсь, в Рамблере, и со временем стала поддерживаться другими российскими поисковиками. На данный момент она содержится в документации поисковой системы Mail.Ru. Google эту директиву никогда не поддерживал.
Яндекс долгое время использовал эту директиву как рекомендацию для указания главного зеркала наряду с серверным редиректом. В 2011-м году для случаев выбора предпочтительного домена для индексирования из вариантов с www или без www, в сервисе Яндекс.Вебмастер появился инструмент «Главное зеркало», для которого был заявлено, что «такой способ выбора главного зеркала имеет больший приоритет, чем директива Host, но меньший, чем редирект (301, 302)».
Удивительно, но не смотря на заявленное главенство приоритета серверного редиректа перед остальными способами указания главного зеркала, сотрудники Яндекса никогда не рекомендовали его применять. Дело в том, что при использовании редиректа в Яндексе типичной ситуацией было выпадение редиректящего сайта из индекса до того момента, пока проиндексируется сайт, на который указывает редирект. И даже если сайт, являющийся целью редиректа, уже был проиндексирован, то все равно процесс выпадения редиректящего сайта происходил быстрее, чем его подклейка в качестве второстепенного зеркала к цели редиректа. В итоге характеристики, влияющие на позиции, а, следовательно, и поисковый трафик, переходили от второстепенного к главному зеркалу далеко не сразу, процесс мог затянуться на месяцы. Поэтому намного более надежным способом переклейки главного зеркала была директива Host, т.к. сайт, указанный как второстепенное зеркало, находился в индексе непосредственно до момента переклейки.
Одну из проблемных ситуаций, в которой необходимо было поменять главное и второстепенное зеркало местами, так описывал в своей инструкции по деликатному переезду с http на https собирательный образ сотрудников службы поддержки Яндекса Платон Щукин: «Процесс в целом ничем не отличается от склейки, только в этом случае я особенно не рекомендую использовать редирект для переезда: получится, что главное зеркало недоступно из-за редиректа, а цель редиректа - это неглавное зеркало и в поиск попасть не сможет. В результате в поиск страницы не смогут попасть совсем. В такой ситуации устанавливайте директиву "Host: https://site.ru", используйте "Переезд сайта", адрес в поиске будет изменён в течение нескольких недель».
Сейчас этот совет Платона Щукина перечеркнут с пометкой о том, что он устарел, и сотрудники Яндекса, отменив поддержку директивы Host, утверждают, что переклейка сайта с помощью постранично настроенного 301-го редиректа будет занимать всего несколько дней. Однако это будет возможно только в том случае, если в связке с 301-м редиректом будет использоваться инструмент «Переезд сайта», подразумевающий наличие подтвержденных прав на оба сайта.
Инструмент «Переезд сайта» можно использовать для склейки зеркал и без настройки редиректа, однако в таком случае оперативность не гарантируется и срок склейки может затянуться на несколько недель. Стоит заметить, в этом случае, как и раньше в случае директивы Host, второстепенное зеркало будет гарантированно находится в индексе, и поэтому этот способ могут выбрать наиболее осторожные владельцы сайтов, готовые пожертвовать временем ради минимизации рисков потери трафика, пусть и кратковременной. Тем более, что в комментариях к новости Яндекса об отмене поддержки директивы Host уже встречаются совсем свежие печальные истории потери трафика при переезде с помощью 301-го редиректа:
В случае же, когда нет возможности подтвердить права на оба сайта, придется пользоваться только 301-м редиректом без поддержки инструментом «Переезд сайта». Сотрудник Яндекса Елена Першина утверждает, что склейка должна произойти, но отсутствия проблем не гарантирует:
Склейка сайтов без использования инструмента «Переезд сайта» также весьма актуальна для тех случаев, когда переезд сайта осуществляется с целью ухода из-под наложенных на него санкций поисковика. Так как инструмент «Переезд сайта» требует наличия подтверждения прав владельца на оба сайта, то не надо быть семи пядей во лбу, чтобы понимать, что в случае наличия такой информации у Яндекса, санкции очень быстро переедут со старого на новый сайт. Если же у поисковика достоверной информации о связи между владельцами склеиваемых сайтов нет, то ему следует исключить возможность попытки нанесения целенаправленного вреда конкуренту путем подклейки к его сайту своего скомпрометированного сайта в качестве второстепенного зеркала с целью переноса санкций. Здесь поисковику придется оценивать вероятность наличия реальной связи между владельцами сайтов на основе косвенных признаков, каковыми, например, могут являться идентичность структуры и контента сайтов до переезда.
Кстати, в свете изменений в процедуре переезда сайтов в Яндексе интересен также и вопрос возможных изменений степени полноты переноса характеристик сайта на новый домен. Ведь до сих пор при склейке зеркал с второстепенного зеркала на главное переносились явно не все характеристики. Например, нельзя было предать возраст сайта, что было сделано для предотвращения манипуляций с «состариванием» сайтов с помощью подклейки к ним возрастных «дропов».
В любом случае, отказ от директивы Host в пользу 301-го редиректа является еще одним шагом Яндекса в процессе унификации своего функционала с функционалом Google, для которого 301-й редирект изначально являлся основной процедурой для указания главного зеркала при склейке сайтов. Напомню, что в прошлом году Яндекс расстался с частью операторов языка запросов, не имевших аналогов в Google, что я отмечал в своей статье «Кастрация языка запросов Яндекса». Вполне возможно, что в скором времени следует ожидать от Яндекса очередных шагов по прекращению поддержки других элементов своего функционала, не имеющих аналогов в Google. К наиболее известным из них можно отнести тег noindex, а также директивы файла robots.txt Clean-param и Crawl-Delay.


Технологии Blogger.