понедельник, 2 октября 2017 г.

Лайфхак №4. Альтернативный способ определения геозависимости запроса в Яндексе

Немногим более года назад я опубликовал в своём блоге довольно любопытный способ определения геозависимости выдачи Яндекса одним запросом. Вообще традиционный способ определения геозависимости подразумевает минимум два запроса – надо сравнить выдачи для разных регионов. Там, где они совпадают, делается вывод о геонезависимости. Однако, в последнее время выдача даже в одном и том же регионе по одним и тем же запросам, сделанным в разные моменты времени, может различаться вследствие различных причин, например, примеси «многорукого бандита». Что может привести к неверному выводу о геозависимости геонезависимого запроса. Таким образом, задача определения геозависимости выдачи именно одним запросом достаточно актуальна.
Способ, предложенный мною год назад, в общем-то пока еще является рабочим (правда, с некоторых пор несколько ограниченно – только для запросов, где есть быстроботовская примесь), однако он использует операторы языка запроса Яндекса, которые больше не содержатся в официальной документации и о прекращении поддержки которых было официально объявлено в январе этого года. Идея этого способа заключалась в том, что геозависимые запросы имеют в сниппетах подсветку жирным шрифтом топонима региона выдачи. Поэтому основная задача заключалась в том, чтобы сформировать выдачу таким образом, чтоб в сниппеты первых 50 результатов выдачи (максимальное количество результатов, которое можно получить одним запросом) входил топоним, чтобы по наличию или отсутствию его подсветки сделать вывод о геозависимости запроса. Тогда это удалось сделать с помощью двойного использования операторов отрицания ~~, а также оператора title: (поиск в заголовке документа) и оператора << (неранжирующее И), но именно этим операторам в числе прочих в последствии было отказано в поддержке. На момент написания статьи прежний способ работает весьма специфически – в выдаче показываются только документы из быстроботовской примеси, однако, по ним вполне можно сделать анализ. Однако нельзя гарантировать наличия быстроботовской примеси для конкретного запроса, да и нет никакой уверенности, что и быстроботовская примесь не исчезнет в любой момент, как исчезла органическая выдача, кстати, еще буквально пару недель назад имевшаяся в наличии по сформированному подобным образом запросу.
Таким образом, возникает потребность в более надежном способе, не использующем неподдерживаемые официально операторы языка запроса. При этом было бы логично, используя прежнюю идею, найти иной способ ее реализации, т.е. обеспечить наличие в топе результатов поиска гарантированного формирования сниппета с топонимом.
Изучая свойства геозависимости запросов, я обратил внимание на тот факт, что добавление к исходному запросу через документированный оператор | (логическое ИЛИ) какого-либо достаточно редкого термина (т.е. имеющего достаточно большое значение IDF – обратной частоты встречаемости в коллекции документов) никак не влияет изменение геозависимости запроса. Это наблюдение я и решил положить в основу альтернативного решения поставленной задачи формирования нужного сниппета.
Добавление к исходному запросу нового термина дает нам массу возможностей в этом плане. Достаточно найти релевантный этому термину сайт, содержащий в теге title своих страниц какой-нибудь топоним, и построить выдачу для соответствующего региона, суженную на этот конкретный сайт. Поясню на примере.
Возьмем в качестве исходных запросов примеры из прошлогодней статьи – доставка пиццы (как пример геозависимого запроса) и вкусный борщ (как пример геонезависимого). Убедимся, что пока еще работающиий старый способ это подтверждает. У первого запроса топоним Москва подсвечивается жирным шрифтом в московской выдаче (lr=213):
А у второго – нет:
В качестве дополнительного термина с большим IDF я взял термин arsenaltula – часть доменного имени официального сайта футбольного клуба «Арсенал» из города Тулы (arsenaltula.ru), т.к. в теге title главной страницы этого сайта содержится топоним Тула. И сформировал суженные на этот сайт (с помощью get-параметра URL страницы выдачи site) выдачи для региона Тула (lr=15) для исходных запросов с добавлением через оператор | (логическое ИЛИ) дополнительного термина. В первом случае ожидаемо получил подсветку жирным шрифтом топонима Тула в сниппете:
А во втором – подсветки топонима ожидаемо не обнаруживается:
Безусловный плюс данного метода – это возможность гарантированного формирования нужного сниппета практически для любого исходного запроса. Чего, кстати, в общем случае не мог гарантировать предыдущий метод. Однако есть и минус – все-таки нам приходится модифицировать исходный запрос, и гарантировать в общем случае, что такая модификация не повлияет на геозависимость исходного запроса, нельзя. Наиболее находящимися в зоне риска мне представляются запросы, содержащие термины с большим IDF. Однако на данный момент мне случаев смены геозависимости запроса вследствие его подобной модификации обнаружить не удалось. Так что пока что я склонен считать данный метод вполне рабочим. И что, самое главное – очень удобным.
В заключении хотелось бы упомянуть об одном глюке поисковой выдачи Яндекса, который необходимо учитывать при применении методики. Оказывается, не для каждого региона осуществляется подсветка топонима в сниппете для геозависимых запросов. Так, к примеру, мне прислали пример, что этого не происходит в регионе Орёл (lr=10):


четверг, 7 сентября 2017 г.

Алгоритм «Королёв» - очередная порка сеошников откладывается

2017-09-07-1.jpg
Как никогда весь «сеошный» мир ждал запуска нового алгоритма ранжирования, анонсированного на 22 августа 2017 года. Ещё бы, подобные анонсы – вещь для Яндекса абсолютно нетипичная, обычно они предпочитают не распространяться о своих планах, и сообщают об очередном релизе алгоритма ранжирования постфактум. Из редких анонсов вспоминается, пожалуй, лишь только анонс на Yet another Conference on Marketing-2013 платформы «Острова», жизненный путь которой, впрочем, оказался весьма печальным – в итоге она так и не смогла выйти из режима бета-тестирования и через два года «мучений» была закрыта.
В общем-то, традиционно ничего хорошего сеошники от новых алгоритмов Яндекса не ждут. Еще слишком свежи в памяти раны, нанесенные алгоритмами «Минусинск» и «Баден-Баден». Поэтому одним из основных вопросов, витавшим в многочисленных дискуссиях в профессиональных сообществах, был вопрос о том, в какое место будет нанесен удар в этот раз.
Однако после презентации нового алгоритма, получившего наименование «Королёв» (напомню, что с 2008-го года новые алгоритмы ранжирования в Яндексе называют в честь городов), стало понятно, что сеошникам можно на некоторое время облегченно выдохнуть. Область применения нового алгоритма практически не затрагивает традиционные сеошные сферы интересов, в первую очередь к которым можно отнести коммерческую выдачу. «Королёв» оказался логическим продолжением алгоритма «Палех», представленного в ноябре 2016 года. И призван обслуживать длинный хвост микрочастотных запросов, как правило, задаваемых на естественном языке.  Особенностью таких запросов является то, что релевантные им документы могут не содержать многих из слов, входящих в запрос. Это ставит в тупик традиционные алгоритмы ранжирования, основанные на текстовой релевантности. Решение найдено в виде использования нейросетей, которые обучаются в том числе и на поведении пользователей. Здесь многое упирается в вычислительные мощности, но сотрудники Яндекса утверждают, что им удалось успешно справиться с этой задачей с помощью новых подходов к построению архитектуры нейронной сети.
Вообще подобный подход к решению задачи ранжирования длинного микрочастотного хвоста запросов не нов. Еще в 2015-м году стало известно о технологии, применяемой поисковой системой Google для поиска ответов на многословные запросы, заданные на естественном языке – RankBrain. Эта технология, так же основанная на машинном обучении, позволяет распознавать наиболее значимые слова в запросах, и анализировать контекст, в котором осуществляется поиск. Что позволяет находить релевантные документы, которые не содержат всех слов запроса.
У Яндекса же качество ответов на многословные микрочастотные запросы на протяжении долгого времени откровенно хромало. Судя по всему, понимая это, сотрудники Яндекса решили вплотную сосредоточиться на решении данной задачи. И придают этому решению настолько важное значение, что сочли новую технологию достойной для полномасштабной презентации.
Что же касается сеошников, то они, почувствовав, что новый алгоритм проходит мимо сферы их интересов, ищут развлечение в поиске примеров плохой выдачи по микрочастотному хвосту запросов на естественном языке. Полагаю, что на реальное широкомасштабное исследование качества такой выдачи мало кто не сподобится, но вот сопровождаемых ехидными комментариями примеров плохого качества выдачи по единичным запросам, похоже, будет сколько угодно. Собственно, эти примеры уже начали появляться, и SEO-специалисты, особенно из числа затаивших обиду на Яндекс за те или иные его действия, с удовольствием их тиражируют в соцсетях и обсуждают в профессиональных сообществах.
Впрочем, длинный хвост микрочастотных многословных запросов на естественном языке вполне может быть интересен «выжигателям» информационной семантики – создателям так называемых инфосайтов «на все случаи жизни». В общем-то, они и так стараются под как можно большее количество известных им запросов, которые удается заполучить с помощью различных методов сбора семантики, организовать точное вхождение в свои тексты. Там же, где точных вхождений не будет, т.е. для запросов, которые не всосал «семантический пылесос» создателей инфосайтов или для которых им не удалось обеспечить точных вхождений в контент, и начинается вотчина «Королёва», который призван искать соответствия между запросами и ответами в том случае, когда между ними мало пересечений по ключевым словам. В таких случаях "Королёв" несомненно повысит требования к качеству контента, и реально интересные читабельные статьи будут еще больше выигрывать у сборников вхождений ключевых фраз, разбавленных водой, т.к. именно в таких статьях могут содержаться полезные для нового алгоритма сигналы. Ну, а всем остальным сеошникам действительно можно расслабиться – очередная порка откладывается. Жертв и разрушений нет.

вторник, 15 августа 2017 г.

Чистка поискового индекса сайта

650891_original.jpg
Нередки ситуации, когда поисковые системы индексируют на сайте большое количество страниц, не несущих с их точки зрения полезной информации – четкие или нечеткие дубликаты страниц, технический мусор, служебные страницы и т.п. Эти страницы могут стать препятствием для своевременной переиндексации и корректного ранжирования сайта, поэтому очень желательно минимизировать их количество в индексе. Сделать это можно разными способами, которые можно разбить на две большие группы: запрет к индексации и склейка с другими страницами сайта. Рассмотрим особенности каждого из способов и предпочтительные варианты их применения.
Основное различие запрета и склейки заключается в том, что в случае склейки нетекстовые характеристики подклеиваемой страницы (назовем ее неканонической), такие как значения ссылочных, поведенческих и временных факторов, будут суммированы со значениями соответствующих факторов целевой страницы (назовем ее канонической). В случае же запрета индексации вся эта информация будет просто потеряна. Поэтому запрещать к индексации в первую очередь имеет смысл те страницы, которые не имеют сколько-либо значимых значений нетекстовых характеристик, например, отсутствуют ссылки, ведущие на них, а количество трафика на этих страницах пренебрежимо мало. Как правило, это служебные страницы, например, rss-лента, личные кабинеты пользователей или результаты поиска по сайту.
Запрет индексации страницы можно осуществить следующими способами:
  1. С помощью директивы Disallow в секции для соответствующего юзер-агента поисковика файла robots.txt.
  2. С помощью значения noindex директивы content мета тега robots.
В первом случае не будет расходоваться краулинговый бюджет, выделенный на переиндексацию страниц сайта, имеющих отклик 200 OK, т.к. индексирующий робот просто не будет обращаться к запрещенным в файле robots.txt страницам. Поэтому этот способ в общем случае более предпочтителен. Во втором случае робот будет скачивать страницы, и только после их скачки будет обнаружена запрещающая индексацию директива. Таким образом, краулинговый бюджет сайта будет частично расходоваться на постоянную переиндексацию подобных страниц. Частично эту проблему можно решить с помощью корректной настройки обработки запроса If-Modified-Since (подробнее см. в моей статье «Заголовки Last-Modified и If-Modified-Since»). Более того, во втором случае запрещенные к индексации страницы на некоторое время могут попадать в индекс. Причем это время может быть и не таким уж их краткосрочным, имеют место случаи, когда счет идет даже не на дни, а на месяцы. Поэтому второй способ целесообразно использовать только в следующих случаях:
  1. Если число таких страниц достаточно велико, а особенности их URL таковы, что не представляется возможным достаточно компактно перечислить их в директивах файла robots.txt с помощью правил стандарта исключений для роботов и поддерживаемых поисковиками его расширений (например, см. соответствующую документацию для Яндекса и Google). Так, Яндекс имеет ограничение на размер файла robots.txt в 32 кб, а Google - в 500 кб.
  2. Если запрещаемые к индексации страницы в силу каких-либо причин являются единственным источником внутренних ссылок на те страницы сайта, которые должны находиться в поисковом индексе. В этом случае директива content мета тега robots кроме значения noindex должна иметь также значение follow, разрешающее поисковому роботу переходить по ссылкам на странице.
Как уже было сказано выше, склейка страниц, в отличие от запрета к индексации, позволяет суммировать значения нетекстовых факторов подклеиваемой (неканонической) страницы с соответствующими значениями целевой (канонической) страницей. Склейку можно осуществить следующими способами:
  1. С помощью редиректа с откликом 301 Moved Permanently.
  2. С помощью директивы Clean-param в файле robots.txt (только для специальных случаев URL с динамическими параметрами).
  3. С помощью атрибута rel="canonical" тега link.
301-й редирект применим в тех случаях, когда содержимое неканонической страницы полностью идентично содержимому канонической, поэтому в этом случае пользователя можно просто перенаправить с одного URL на другой. В этом случае при обращении к неканоническому URL не происходит расхода краулингового бюджета, т.к. он имеет отклик, отличный от 200. Следует иметь ввиду, что в случае использования редиректа с откликом 302 склейки не произойдет.
Этот способ целесообразно применять, к примеру, при смене структуры URL сайта или для склейки дублей URL со слэшом на конце и без него. Если же по неканоническому URL необходимо отдавать пользователю содержимое, т.е. он должен иметь отклик 200, то в этом случае необходимо использовать два других способа склейки.
Использование директивы Clean-param в файле robots.txt ограничивается только страницами, имеющими в URL динамические параметры. Это могут быть как параметры, не влияющие на содержимое (например, идентификаторы сессий или рефереры), так и влияющие (например, режимы сортировки). Неканонический URL подклеивается к каноническому, который образован путем удаления указанных в директиве параметров. Естественно, что такой канонический URL должен иметь отклик 200, иначе никакой склейки не произойдет. Данный способ также не приводит к расходу краулингового бюджета, т.к. в этом случае поисковый робот просто не будет скачивать неканонический URL. Однако, надо иметь в виду, что по этой же причине поисковику будут неизвестны ссылки, находящиеся на неканоническом URL. Поэтому целесообразно применять этот способ в случаях, когда «обрезаемые» параметры не влияют на содержимое страницы либо значений этих параметров может быть достаточно много, чтоб оказать заметное влияние на расход краулингового бюджета (например, результаты поиска по сайту).
И, наконец, третий вариант, который мне представляется во многих случаях наиболее предпочтительным - это использование атрибута rel="canonical" тега link. К плюсам этого метода относится то, что, как и при любой склейке, происходит суммирование нетекстовых факторов неканонической и канонической страниц (что, кстати, непосредственно подтверждено сотрудником Яндекса Александром Смирновым на Шестой Вебмастерской) плюс происходит учет ссылок, находящихся на неканонической странице (что также было непосредственно подтверждено в блоге собирательного образа службы поддержки Яндекса Платона Щукина).
Единственный минус этого метода - это то, что неканонические страницы в силу того, что они имеют отклик 200, так же, как и в случае с noindex в мета-теге robots, будут выбирать краулинговый бюджет. И так же неканоническая страница может довольно продолжительное время находится в индексе до того момента, как будет склеена с канонической. Но тем не менее данный способ отлично подходит, например, для склейки страниц пагинации, различных вариантов сортировки, результатов применения фильтров к спискам и т.п., а также «обрезания» динамических параметров URL. Кстати, что касается пагинации, то сотрудники Google рекомендуют использовать атрибуты rel="next" и rel="prev" тега link. Однако Яндекс не поддерживает эти директивы. Поэтому я все-таки рекомендую использовать rel="canonical" для обоих поисковиков, тем более, что практика показывает, что эта директива прекрасно работает и в Google. Есть различие между Яндексом и Google и непосредственно в обработке директивы rel="canonical" - Яндекс, в отличие от Google, не поддерживает кросс-доменность этой директивы, то есть нельзя склеить страницы, находящиеся на различных поддоменах.

И в заключение хотелось бы отметить, что следует избегать многократного последовательного применения директив склейки. Например, цепочек редиректов или указания в качестве канонической страницы, которая сама содержит директиву rel="canonical" на с указанием третью страницу. Равно как и последовательно комбинировать различные методы склейки. Например, когда URL, получающийся в результате «обрезания» параметров с помощью директивы Clean-param, в свою очередь является неканоническим. В подобных случаях поисковик может просто проигнорировать директивы.

вторник, 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-решения, не связанные напрямую с улучшением собственно качества сайта, имеют исчезающе мало перспектив в современных реалиях.


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