среда, 13 декабря 2017 г.

Новая логика работы операторов языка запросов Яндекса. Документные операторы

В своей предыдущей статье я проанализировал работоспособность операторов языка запросов Яндекса из группы «Морфология и поисковый контекст», о прекращении поддержки которых было официально объявлено Яндексом в январе 2017 года. Нововведения объяснялись «рядом важных изменений, направленных на увеличение производительности поиска, а именно изменением формата поискового индекса и связанным с ним изменением механизма разбора поисковых запросов». Вместе с тем изменения замечены и в работе другой группы операторов языка запросов Яндекса, а именно «Документные операторы». 
Несмотря на то, что в документации языка запросов указано, что документные операторы используются для уточнения поискового запроса, ограничивая область его применения, раньше все операторы этой группы корректно работали и при их прямом применении (или, другими словами, в связке с пустым поисковым запросом). Теперь же эту способность сохранили только операторы url:, site:, host:, rhost:, domain: и date: (назовем их документными операторами 1-го типа). Операторы же mime:, lang: и cat: (назовем их документными операторами 2-го типа) при прямом применении работоспособность явно потеряли:
Документные операторы 2-го типа работают корректно только в связке с непустым запросом, причем, как справа, так и слева от него. Правда, при использовании этих операторов слева от непустого поискового запроса в выдаче могут возникать любопытные артефакты:
Есть также одно исключение, когда эти операторы корректно работают в случае пустого запроса – в связке с документным оператором site:, причем, только справа от него:
При использовании же слева от оператора site: документные операторы 2-го типа просто игнорируются:
Точно также документные операторы 2-го типа игнорируются и в случае пустого запроса в связке с операторами url:, host:, rhost:, domain: и date:, не зависимо от расположения справа или слева от них.
В случае же непустого запроса и нескольких документных операторов, порядок следования запроса и операторов роли не играет. 
Представляется интересным также исследовать текущую работоспособность документных операторов, когда-либо упоминавшихся, но в разное время исчезнувших из официальной документации языка запросов.
Так, летом 2016-го года из раздела Яндекс.Помощи «Документные операторы» без каких-либо объявлений исчезли два оператора, сохранив, однако, на тот момент свою работоспособность:
  • title: – оператор поиска по заголовкам документов (тег title);
  • inurl: – оператор поиска по страницам, в адресе которых есть заданный фрагмент.
Сейчас оператор title:  явно перестал выполнять заявленную функцию, такое впечатление, что он просто игнорируется, не зависимо от того, используется ли он с пустым или непустым поисковым запросом:
А вот оператор inurl:, в отличие от него, свою работоспособность сохранил. Так же, как и документированные документные операторы 2-го типа, он не работает при применении с пустым поисковым запросом 
и работает в связке с непустым:
О других недокументированных операторах я в своё время писал в своих статьях «Сеанс поисковой магии. Недокументированные операторы языка запросов Яндекса» и «Недокументированные операторы языка запросов Яндекса. Продолжение сеанса поисковой магии». К сожалению, самые из них интересные операторы intext: и inlink: потеряли свою работоспособность в апреле 2017-го года, а операторы linkint: и anchorint: – еще раньше.
Из числа недокументированных работоспособными на текущий момент остаются только гораздо менее интересные для решения аналитических задач документные операторы:
  • idate: – оператор поиска по дате последней индексации документа;
  • style: – оператор поиска по адресам файлов таблиц стилей (значение атрибута href тега link c атрибутом stylesheet);
  • profile: – оператор поиска по адресам профилей метаданных (значение атрибута profile тега head)

Все эти операторы имеют свойства документных операторов 2-го типа. 

четверг, 2 ноября 2017 г.

Новая логика работы операторов языка запросов Яндекса. Морфология и поисковый контекст.

В начале 2017 года Яндекс объявил о прекращении поддержки ряда операторов языка запросов. Я подробно писал об этом в своей статье «Кастрация языка запросов Яндекса». Отказ от поддержки ряда операторов объяснялся сотрудниками Яндекса изменением формата поискового индекса и связанного с ним изменением механизма разбора поисковых запросов. По прошествии некоторого времени хотелось бы проанализировать, какие изменения на самом деле произошли в логике работы операторов языка запросов Яндекса. 
Самый неприятный итог изменений – это то, что все указанные в анонсе операторы из группы «Морфология и поисковый контекст», а именно &, &&, <<, ~, (), !!, на данный момент действительно перестали работать (возможно, за исключением малоинтересного с точки зрения аналитики оператора !!). Эти операторы оказывали неоценимую помощь при исследовании поисковой выдачи, позволяя конструировать разнообразнейшие запросы для решения широкого спектра аналитических задач. Теперь же они явно не поддерживают свои функции.
Оператор ~ теперь является аналогом документированного оператора (минус), который осущствляет поиск документов, в которых отсутствует заданное слово, хотя раньше работал с точностью до предложения, т.е. позволял искать документы, в которых заданное слово не содержится в одном предложении со словом, указанным до оператора. Также аналогом оператора (минус) сейчас является и оператор ~~, почему-то не упомянутый в анонсе Яндекса о прекращении поддержки операторов, но исчезнувший из официальной документации. Раньше с помощью оператора ~~ можно было исключать из поиска целые поисковые фразы, а также страницы и сайты (т.е. он работал с документными операторами), а теперь он применим только к отдельным ключевым словам. Впрочем, аналогия простирается лишь на случай, когда операторы применяются к последним словам запроса. Если же использовать их в середине, то получившиеся результаты поиска могут разниться и осмысленной логике не поддаются:
Оператор &, призванный искать слова в пределах одного предложения, определенно этого не делает. В приведенном ниже примере, на сайте, по которому идет поиск, нет предложений, где бы встречались оба указанных слова, но тем не менее, выдача не пуста:
Оператор поиска в пределах документа && тоже не выполняет своих функций. В приведенном примере на сайте, по которому идет поиск, нет документов, в которых встречаются оба слова из запроса. Тем не менее в выдаче фигурируют документы, где они встречаются поодиночке:
Оператор << (неранжирующее И) перестал ограничивать выдачу документами, релевантными запросу, находящемуся по правую сторону оператора. На приведенном примере справа находится «абракадабра», которая вообще не встречается ни в одном документе. Тем не менее, это не оказывает никакого влияния на число найденных документов:
Проверим работу оператора группировки слов при сложных запросах (). Возьмем два запроса поиска по сайту с пустой выдачей:
И сгруппируем их с помощью оператора () и документированного оператора | (логическое ИЛИ). Если группировка работает корректно, то выдача должна быть пуста. Однако это не так:
Что же касается оператора поиска слова по начальной форме !!, то проверить его корректную работоспособность очень трудно. По крайней мере, можно убедиться, что применяя его к словам, которые сами по себе не являются начальной формой, можно найти документы только с точными вхождениями этих слов. А вот для слов, которые являются начальной формой слов, ищутся документы, где нет точного вхождения, но есть формы этого слова. С другой стороны, очень похоже на то, что начальная форма слова в запросе теперь учитывается по умолчанию (пищу для размышления привожу ниже на скриншотах, хотя никакой практической ценности я в этом факте не вижу). 


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

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

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


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

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


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

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

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


Нередки ситуации, когда поисковые системы индексируют на сайте большое количество страниц, не несущих с их точки зрения полезной информации – четкие или нечеткие дубликаты страниц, технический мусор, служебные страницы и т.п. Эти страницы могут стать препятствием для своевременной переиндексации и корректного ранжирования сайта, поэтому очень желательно минимизировать их количество в индексе. Сделать это можно разными способами, которые можно разбить на две большие группы: запрет к индексации и склейка с другими страницами сайта. Рассмотрим особенности каждого из способов и предпочтительные варианты их применения.
Основное различие запрета и склейки заключается в том, что в случае склейки нетекстовые характеристики подклеиваемой страницы (назовем ее неканонической), такие как значения ссылочных, поведенческих и временных факторов, будут суммированы со значениями соответствующих факторов целевой страницы (назовем ее канонической). В случае же запрета индексации вся эта информация будет просто потеряна. Поэтому запрещать к индексации в первую очередь имеет смысл те страницы, которые не имеют сколько-либо значимых значений нетекстовых характеристик, например, отсутствуют ссылки, ведущие на них, а количество трафика на этих страницах пренебрежимо мало. Как правило, это служебные страницы, например, 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, в свою очередь является неканоническим. В подобных случаях поисковик может просто проигнорировать директивы.

Blog Archive

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