вторник, 4 июля 2017 г.

Лайфхак №3. Определение аффилиатов в Яндексе – поиск альтернативных способов

Наверное, трудно найти такого SEO-специалиста, который бы не слышал о понятии аффилирования сайтов в Яндексе. Суть его заключается в группировке нескольких сайтов одного владельца в поисковой выдаче. В итоге по общим запросам показывается только один, самый релевантный документ из всех сайтов аффилированной группы. В подразделе «Некачественные сайты» раздела «Помощь вебмастеру» документации Яндекса можно встретить такую фразу:
«Мы стараемся не индексировать или не ранжировать высоко:
...
Группы сайтов одного владельца/компании, предоставляющие пользователю одни и те же товары или услуги, созданные с целью заполнения нескольких позиций в результатах поиска и сбора трафика».
Немногим более года назад я опубликовал простой и эффективный способ проверки аффилированности двух сайтов в Яндексе. К сожалению, используемый в нём оператор отрицания был исключен из документации языка запросов и поддержка его официально прекращена. Видимо, по этой причине на протяжении некоторого времени данный способ вообще не работал (что сказалось на работоспособности некоторых SEO-сервисов, предлагающих автоматическую проверку сайтов на аффилированность), и только буквально недавно работоспособность способа опять восстановилась. Хотя анализ выдачи показывает, что оператор отрицания все равно работает сейчас не совсем корректно (что, впрочем, пока не сказывается на работоспособности обсуждаемого способа), и гарантировать, что способ сохранит свою работоспособность ни в коей мере нельзя.
Таким образом возникает задача поиска очередного лайфхака в виде альтернативного метода определения аффилированности двух сайтов, который не использовал бы недокументированных операторов языка запроса.
Напомню суть существующего способа. Нам необходимо построить выдачу по какому-либо запросу, в которой должны находиться главные страницы сравниваемых сайтов. Если они показываются на одной странице выдачи, значит, аффилирования нет. Если же показывается только одна из них, то значит, сайты саффилированы и сгруппированы в выдаче, и показывается только один из них, наиболее релевантный запросу. Рассматриваемый способ ограничивал выдачу главными страницами рассматриваемых сайтов с помощью оператора url:. Однако использование данного оператора (равно как и другие документные операторы документные операторы url:, site:, host: и rhost: ) приводит к разгруппировке выдачи по доменам, и чтобы принудительно сгруппировать ее обратно, использовалась конструкция из последовательного примененных операторов отрицания  и оператора url: с произвольным значением.
К сожалению, найти альтернативный способ принудительной группировки разгруппированной выдачи без использования оператора отрицания мне не на данный момент удалось. Поэтому изначальную задачу построения следует решать без применения документных операторов url:, site:, host: и rhost:, дабы не разгруппировывать выдачу. Причем, необходимо построить выдачу с как можно меньшим количеством сайтов, так чтобы все ответы уместились на одной странице (максимально возможное количество ответов на поисковой странице в Яндексе составляет 50).
В этом случае можно взять по одной достаточно редкой фразе с каждой из главных страниц исследуемых сайтов. Конечно, в идеально, если это будут вообще уникальные фразы, но не всегда возможно найти таковые, да и сам поиск уникальных фраз на странице может стать весьма трудоемкой задачей. Однако, во многих случаях бывает достаточно взять содержимое тегов title.
Так, например, рассмотрим этот способ для сайтов, взятых в качестве примера аффилиатов в моей прошлогодней статье. Убеждаемся, что они главные страницы сайтов находятся в поиске по точной фразе, взятой из тега title:
Теперь компонуем обе точные фразы в одном запросе через пока еще остающийся документированным оператор | (логическое ИЛИ):
Мы видим оба сайта рядом на странице поисковой выдачи, а это явно свидетельствует о том, что они на данный момент не аффилированы. Хотя еще год назад они распознавались, как аффилиаты. Проверяем с помощью старого способа – всё верно, сайты уже не аффилированны:
Теперь возьмем для проверки другую пару сайтов, оба принадлежат одному информационному холдингу. Снова убеждаемся, что они главные страницы сайтов находятся в поиске по точной фразе, взятой из тега title:
Компонуем обе точные фразы в одном запросе через оператор | и видим в выдаче только один из двух сайтов:
Отмечу, что все результаты помещаются на одну страницу выдачи, разбитой по 50 результатов, так что в этом легко убедиться. Проверка старым способом подтверждает факт аффилирования данных сайтов:
Таким образом, предложенный способ можно применять, как альтернативу прежнему. Однако, стоит признать, что необходимость поиска подходящих фраз в контенте исследуемых страниц, существенно повышает его трудоемкость и ограничивает возможность его автоматизации.



вторник, 27 июня 2017 г.

Быстроботовская примесь не аффилируется

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

вторник, 2 мая 2017 г.

Алгоритм «Баден-Баден» – новый виток борьбы Яндекса с текстовой переоптимизацией

На фото – красная панда из зоопарка Карлсруэ близ Баден-Бадена (с легкой руки Андрея Липатцева из Google – собирательный образ борьбы поисковиков с текстовым спамом)


23 марта 2017 года в блоге Яндекса для вебмастеров появился анонс нового алгоритма, получившего название «Баден-Баден». И хотя в Яндексе в 2008 году решили давать новым поисковым программам названия российских городов, на этот раз ради того, чтобы подчеркнуть специфику нового алгоритма, он получил название немецкого города, состоящего из двух одинаковых слов. И намек, заключенный в названии, вполне прозрачен. Впрочем, справедливости ради стоит сказать, что иностранный город в семействе алгоритмов Яндекса уже встречался – Рейкьявик в 2011-м году, ознаменовавший алгоритм, связанный с языковыми предпочтениями пользователей.
В анонсе алгоритма сказано, что «результатом его работы может стать ухудшение позиций переоптимизированных страниц в результатах поиска». Что в общем-то подтверждает анализ сайтов, предположительно подвергнувшихся его воздействию – наблюдается ухудшение ранжирования отдельных страниц сайтов по отдельным запросам.
7 апреля в Минске на конференции «Неделя Байнета 2017» руководитель службы Яндекса по работе с вебмастерами Михаил Сливинский анонсировал второй этап алгоритма «Баден-Баден. «Неделя Байнета» уже традиционно является площадкой для анонса Яндексом знаковых нововведений. В 2014-м прямо на сцене отключали ссылочное ранжирование по отдельному классу коммерческих запросов, в 2015-м – запускали алгоритм борьбы с SEO-ссылками «Минусинск». Прошлый 2016-й год прошел без громких анонсов, однако в 2017-м традиция возобновилась.
Второй этап «Баден-Бадена» имеет характерную особенность – обещано, что санкции будут применяться ко всему сайту, а их наличие будет отображаться как нарушение «Переоптимизация» в сервисе Яндекс.Вебмастер. Михаил Сливинский пообещал, что санкции могут затронуть несколько тысяч сайтов.
В своем комментарии к анонсу первого этапа алгоритма «Баден-Баден» менеджер Яндекса Елена Першина дифференцирует его этапы на «Баден-Баден как алгоритм» (первый этап) и «Баден-Баден как нарушение» (второй этап). Вполне вероятно, что доменные санкции в виде пост-штрафа будут применяться к сайту в случае, когда у него накопится некоторая критическая масса страниц, получивших низкие оценки алгоритма. То есть второй этап – это не модификация собственно алгоритма, а более жесткие санкции к нарушителям, выявленным им.
Примечательно, что в анонсе первого этапа алгоритма «Баден-Бадена» сказано, что «он является частью общего алгоритма ранжирования». В то время как предыдущая версия алгоритма борьбы с переоптимизированными текстами образца 2011-го года была явной надстройкой и даже не удостоилась «именного» названия. Вообще наблюдается устойчивая тенденция перетекания антиспама в основное ядро алгоритма ранжирования. Так, например, в сентябре 2016-го года Google объявил о том, что алгоритм антиспама «Penguin» из отдельной надстройки стал обновляющейся в режиме реального времени частью ядра алгоритма.  
Включение алгоритмов антиспама в основное ядро значительно затрудняет их реверс-инжиниринг на предмет определения граничных значений срабатывания санкций. Ведь пороги срабатывания, к примеру, алгоритма текстового антиспама, могут зависеть не только собственно от значений текстовых характеристик, но и от других групп факторов. Как говорится, что русскому – здорово, то немцу – смерть. Неслучайно Михаил Сливинский, отвечая на вопросы слушателей во время своего выступления на «Неделе Байнета», подчеркнул, что текстовый анализ документов, попавших под санкции, равно как и документов, находящихся в топе выдачи, мало что даст тем, кто постарается найти технические пути обхода алгоритма.
Вообще, на мой взгляд, сама идея текстовых анализаторов, старающихся найти якобы идеальные текстовые характеристики для конкретного запроса путем усреднения значений отдельных текстовых факторов (как правило простейших, таких как количество употреблений термина или его плотность), замеренных у находящихся в топе выдачи документов, изначально провальна. Эта идея базируется на ложной предпосылке о том, что у находящихся в топе выдачи документов значения всех факторов близки к идеалу. Но дело в том, что это совершенно не обязательно так. Численное значение релевантности – это результирующая значений множества факторов и конкретный фактор может дать в нее, как плюс, так и минус. Да и абсолютные величины вклада могут быть совершенно разные. И вполне может оказаться так, что как раз-таки замеряемые текстовыми анализаторами факторы у конкретных находящихся в топе документов на самом деле дают минусовой вклад в релевантность, а высокое значение результирующей достигается за счет большого положительного вклада в неё других групп факторов. И если скопировать значения этих текстовых факторов и повторить их на другом документе на другом сайте, то эта манипуляция вместо того, что б вытолкнуть этот документ наверх, наоборот, уронит его вниз.
К тому же в топе выдачи могут быть не только органические результаты, но и различные примеси к «органике» - например, «спектральная» или «быстроботовская» (подробнее смотри в моей статье «Примеси к органической выдаче Яндекса»). И замерять значения факторов у «подмешанных» документов, чтоб постараться повлиять на органическую выдачу, вообще бессмысленно. В общем, по факту, на выходе текстовые анализаторы выдают не что, иное, как белый шум.
Текстовые анализаторы хоть как-то могли бы приблизиться к решению задачи нахождения идеальных текстовых характеристик в том случае, если бы можно было применить их к анализу выдачи, полностью очищенной от примесей и построенной с минимальным влиянием иных факторов, кроме текстовых. До недавнего времени, к примеру, можно было в выдаче Яндекса «обнулить» значения ссылочных факторов с помощью недокументированного оператора intext: (подробнее смотри в моей статье «Сеанс поисковой магии. Недокументированные операторы языка запросов Яндекса»). Однако, с недавних пор этот оператор, к сожалению, перестал функционировать.
На мой взгляд, действие «Баден-Бадена» направлено в первую очередь на технологию, получившую название «выжигание семантики». Это технология массового воздействия на выдачу, которую активно стараются автоматизировать различные SEO-сервисы. Сначала собирается максимально возможно семантическое ядро, потом оно кластеризуется на группы запросов, которые привязываются к отдельным страницам. Текстовые анализаторы на основе анализа топа выдачи по запросам выдают некие рекомендации по простейшим текстовым характеристикам. На основе этих рекомендаций изготавливаются SEO-тексты в массовых количествах, как правильно однотипные и недостаточно качественные, написанные в первую очередь, не для того, чтоб их читали люди, а для того, чтоб соблюсти поставленные текстовым анализатором перед копирайтером количественные рамки.
Думаю, что не ошибусь, предположив, что у подобной технологии в новых реалиях немного шансов на существование. Также, полагаю, не за горами пристальный интерес со стороны поисковиков и к другой ипостаси технологии «выжигания семантики», а именно к генерации большого количества вариантов листингов товарных предложений на основе использования фильтров по разнообразнейшим характеристикам. Нередко это приводит к тому, что количество разнообразных листингов на сайте может превышать собственно количество самих товаров.
В общем, Яндекс нам в очередной раз (после массовых санкций в декабре 2014 года за накрутку поведенческих факторов и ввода алгоритма «Минусинск» в мае 2015-го с санкциями за накрутку ссылочных) даёт понять, что массовые искусственные SEO-решения, не связанные напрямую с улучшением собственно качества сайта, имеют исчезающе мало перспектив в современных реалиях.


пятница, 28 апреля 2017 г.

Когда в выдаче Яндекса что-то сломалось… Лайфхак №2. Получаем текстовую сохраненную копию.

Вот уже несколько дней в выдаче Яндекса наблюдается очередная странность. Известно, что со страницы выдачи по ссылке «Сохраненная копия» можно попасть на страницу полной версии этой самой сохраненной копии:
На которой в свою очередь есть ссылка на текстовую копию:
Однако с недавних пор при переходе по ссылке «Посмотреть текстовую копию» ни на какую текстовую версию сохраненной копии мы не попадаем, а остаемся все на той же полной. То есть полная версия сохраненки ссылается сама на себя. Однако текстовую копию получить все-таки возможно. Для этого к адресу страницы полной версии сохраненной копии нужно добавить get-параметр &cht=1. Вуаля:
Возникает вопрос – баг это или фича? Текстовую сохраненку намеренно прячут или ссылку на нее просто потеряли?


вторник, 18 апреля 2017 г.

Лайфхаки к выдаче Яндекса. Узнаем возраст документа без get-параметра how=tm.

В связи с тем, что Яндекс в последнее время основательно взялся за урезание языка запросов и прочих возможностей исследования выдачи, всё чаще встречаю в профессиональных сообществах вопросы об альтернативах тем или иным утраченным возможностям. Поэтому решил открыть рубрику «Лайфхаки», где буду в лаконичной форме предлагать искомые альтернативы для некоторых случаев.
Итак, лайфхак #1. Одной из наиболее востребованных является задача установления возраста страницы в Яндексе. Раньше она решалась с помощью применения get-параметра к URL страницы поисковой выдачи Яндекса how=tm – сортировки выдачи по времени документа. В сниппете сформированной таким образом выдачи для каждого документа указывалась дата, которая и идентифицировалась, как возраст документа с точки зрения Яндекса. С некоторых пор индикация даты документа в выдаче с использованием такой сортировки отсутствует (за исключением стандартной индикации «свежести» документов из «быстроботовской» примеси), хотя, сама сортировка, судя по всему, продолжает осуществляться корректно.  

Однако альтернативная возможность узнать возраст документа с точки зрения Яндекса на данный момент имеется. Для этого нужно воспользоваться сервисом Яндекс.XML и извлечь значение параметра <modtime> для нужной страницы в формате YYYYMMDDThhmmss ISO 8601:2004:


пятница, 14 апреля 2017 г.

Безвременная кончина операторов intext и inlink

Яндекс планомерно закручивает гайки реверс-инжинирингу алгоритма ранжирования. На днях тихой сапой почили в бозе недокументированные операторы intext: и inlink:
Они в своё время были упомянуты только в документации к продукту Яндекс.Сервер  - приложению для поиска в корпоративных сетях и поиска по сайту. Тем не менее оператор intext: полноценно работал и в большом поиске по вебу. Он обнулял значения ссылочных факторов. Если еще и несколько модифицировать базовый запрос таким образом, чтоб обнулились и поведенческие факторы, то можно было получить выдачу, более-менее пригодную для анализа текстовых факторов ранжирования.
Что же касается оператора inlink:, то работал он с некоторыми ограничениями, и полноценно его использовать удавалось только по правую сторону от оператора << (неранжирующее И). Однако это позволяло решить ряд интересных исследовательских и прикладных задач, например, задачу поиска по анкор-файлу.
Сейчас же, единственный заметный эффект от применения этих операторов заключается, похоже, только в отрубании «спектральной» примеси.

понедельник, 20 марта 2017 г.

Поиск поддоменов сайта в индексе Яндекса и Google

В данной статье я хочу рассмотреть один из способов применения операторов языка запроса поисковых машин Яндекс и Google для решения полезной практической задачи – поиска поддоменов сайта, проиндексированных этими поисковыми машинами. Не редки случаи, когда разработчики сайта забывают закрыть от индексации поддомены сайта, на которых содержится бесполезная для поиска информация – копии текущей версии сайта, неактуальные версии сайта, отчеты анализаторов логов и прочая техническая и служебная информация. Захламление поискового индекса подобными данными в ряде случаев может негативно повлиять на позиции сайта. Поэтому желательно все подобные случаи выявить и запретить к индексации поисковыми роботами.
Решение задачи поиска поддоменов в поисковом индексе базируется на простой логической операции – последовательном отрицании при поиске по всему сайту уже известных нам поддоменов. Поиск по всему сайту и в Яндексе и в Google осуществляется с помощью одинакового оператора site:, для которого в качестве значения необходимо указать домен сайта. Например, site:yandex.ru или site:google.com.
Что же касается поиска по определенному поддомену, то в Яндексе это можно сделать с помощью документированного оператора host:. Необходимо иметь ввиду, что указание домена без www и c www дает разные результаты – проиндексированные страницы только с домена второго уровня и только с поддомена www соответственно :
Особенность оператора host: заключается в том, что он не чувствителен к виду протокола http или https, то есть с помощью этого оператора невозможно отделить в выдаче страницы с протоколами http и https друг от друга.
Таким образом, для поиска поддоменов сайта в Яндексе с помощью оператора отрицания ~~ на первом этапе убираем из поиска по всему сайту документы из корневого домена и/или поддомена www и получаем в выдаче документы с других поддоменов:
Отмечу, что здесь есть некоторая особенность. Дело в том, что, в случае достаточно большого количества поддоменов этот список может быть неполным (вообще связка операторов ~~ и host: весьма странным способом то ли группирует, то ли фильтрует результаты поиска), и его необходимо будет уточнять последовательным отрицанием имеющихся в списке поддоменов (при этом в выдаче могут появляться новые поддомены):
Соответственно возможности метода в общем случае ограничены вместимостью поисковой строки (на сегодня ограничение на длину поискового запроса в Яндексе составляет 400 символов).
Рекомендую использовать в URL страницы поисковой выдачи get-параметр &rd=0, который позволяет снять ограничение на показ документов с одинаковыми сниппетами (подробнее см. в моей статье «Параметры URL страницы выдачи Яндекса»).
В Google нет аналога яндексовскому оператору host:, однако поиск по конкретному поддомену там можно осуществлять с помощью недокументированного оператора inurl:, указав в качестве значения полный (включая протокол) адрес поддомена. Например: inurl:https://google.com или inurl:http://www.google.com. Здесь надо иметь ввиду, что оператор inurl: ищет вхождение заданной подстроки в URL документа:
Соответственно, данный способ подразумевает разделение в выдаче страниц с http и https протоколами. А если же указывать в качестве значения просто доменное имя без прокола, то нужного результата мы можем не добиться, т.к., к примеру, все поддомены в качестве подстроки будут включать в себя доменное имя.
Итого для поиска поддоменов сайта в Google с помощью оператора отрицания (минус) на первом этапе убираем последовательно из поиска по всему сайту документы из корневого домена и/или поддомена www по обоим проколам (в случае необходимости) и получаем в выдаче документы с других поддоменов:
В отличие от ситуации с Яндексом здесь какой-либо особой фильтрации результатов не замечено, кроме страндартной фильтрации результатов, которые «очень похожи на уже представленные выше». Стандартная фильтрация обходится добавлением в URL страницы выдачи get-параметра &filter=0 (подробнее см. в моей статье «Параметры URL страницы поисковой выдачи Google»). Равно как не замечено и группировок, поэтому также в случае большого количества поддоменов для большей информативности результатов будет полезно применение последовательного отрицания уже известных поддоменов, т.к. страницы с одного-двух поддоменов могут забить видимую выдачу.  Опять же, здесь мы, как и в случае с Яндексом, ограничены лимитом на длину поискового запроса, в Google он составляет 32 слова.
Кстати, в Яндексе есть также оператор inurl: (бывший некогда документированным, затем прошлым летом исчезнувший из официальной документации, но на данный момент корректно функционирующий) с точно такой же функцией поиска в адресе документа, но по причине того, что он в отличие от гугловского, полностью игнорирует заданный протокол (по сути вырезая его из подстроки), он не годится для решения поставленной задачи:


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