понедельник, 15 апреля 2019 г.

Исследуем новые операторы before: и after: в Google

9 апреля 2019 года Google в официальном твиттере разработчиков поиска порадовал неожиданной новостью – вводом новых операторов поиска before: и after:.
В последнее время, что в Google, что в Яндексе, наблюдается отчетливая тенденция на урезание поискового функционала (вспомнить хотя бы недавнюю отмену Google оператора info:), а тут вдруг случается его расширение. Новые операторы по сути являются некоторыми аналогами яндексовского оператора date: и позволяют фильтровать поисковую выдачу в определенные временные периоды по дате последнего изменения документов (в терминах Google, причем довольно непрозрачных, как мы убедимся далее). Подобные фильтры бывают полезны при решении ряда задач SEO-аналитики, и, в целом, отрадно, что в Google теперь тоже есть подобная возможность.
Однако, к моему сожалению, в данном случае не произошло унификации поисковых функционалов двух крупнейших поисковиков Рунета, и, хотя с помощью операторов before: и after: в Google и date: в Яндексе можно решать аналогичные задачи, однако логика применения операторов все-таки различается. Так, например, для того, чтобы найти релевантные запросу документы за определенную дату в Google, в отличие от Яндекса, придется сооружать конструкцию из двух операторов. И, как мы убедимся далее, все равно не получается найти корректного решения.
В данной статье я постараюсь исследовать некоторые свойства новых операторов Google, взяв в качестве «подопытного кролика» сайт своего SEO-блога.
На момент написания статьи Google показывает в выдаче 63 страницы с этого сайта, причем, в силу небольшого числа страниц это число нетрудно проверить, просто сосчитав количество результатов на странице, с настроенной выдачей по 100 результатов:
Однако применение к результатам поиска операторов before: или after: с заведомо покрывающими все возможные результаты значениями, оставляет в выдаче только по 40 результатов:
И действительно, можно найти проиндексированные страницы с сайта, применение к которым операторов before: и after: дает пустую выдачу. Например:
Получается, что не все страницы имеют дату с точки зрения операторов before: и after: (а в данном случае это без малого четверть страниц с сайта), даже не смотря на наличии даты в сниппете. Этот факт следует учитывать при анализе выдачи с использованием данных операторов.
Теперь попробуем составить конструкцию для поиска документов в Google за определенную дату.   Для главной страницы исследуемого сайта Google показывает на момент написания статьи в сниппете дату 11 февраля 2019 года (что хорошо видно из первого сниппета статьи). Главная страница находится в выдаче, если в эту дату взять в качестве значения как для оператора before:, так и для оператора after:
Если же для оператора before: дату уменьшить на один день, а для оператора after: дату увеличить на один день, то главная страница исчезает из выдачи, что явно свидетельствует о том, что ее дата с точки зрения этих операторов – именно 11 февраля 2009:
Причем, отметим, что количество страниц выдачи в обоих случаях уменьшается на две (в первом – с 35 до 33, во втором – с 7 до 5). Логично предположить, что с датой 11 февраля 2019 года на сайте по мнению Google должно находиться две страницы.
Попробуем сконструировать запрос, скомбинировав оба оператора с одинаковым значением 2019-02-11. Ожидаемо видим в выдаче главную страницу, однако здесь что-то явно не так. На втором месте страница с другой датой в сниппете, а всего результатов 63 – как если бы операторы к запросу не применялись:
Получается, что подобная конструкция (когда значения операторов совпадают) является некорректной. Ведь такая же картина наблюдается, если выбирать такие значения операторов before: и after:, которые задают пустой временной промежуток:
Каким же тогда должен быть запрос, которым можно найти выдачу в Google за определенную дату? Искомый результат получаем, если увеличить на один день значение оператора before: или же увеличить на один день значение оператора after:, то есть расширив фильтр с одного дня на два. И вот они, те самые два искомых документа от 11 февраля 2019 года:
Однако, в данном случае, нам просто повезло, что на сайте нет документов, датированных днем ранее или днем позже, которые тоже должны были попасть в эту расширенную на два дня выдачу. В чем мы можем убедиться, изменив границы двухдневного окна на период, когда есть документы, датированные идущими подряд днями:
Итого имеем, что на текущий момент задачу поиска документов за определенный день в Google с помощью новых операторов решить корректно, увы, нельзя. В отличие от Яндекса, где на подобную задачу как раз и ориентирован оператор date:.
И в заключение хочется обратить внимание на довольно странную логику определения даты документа в Google. Так, главная страница исследуемого сайта на момент написания статьи имеет дату 11 февраля 2019, что показывается в сниппете и подтверждается выдачей, сформированной с помощью операторов before: и after:. Однако в том же сниппете мы видим фрагмент текста, который относится к новости с гораздо поздней датой:
Почему же Google выбрал в качестве даты страницы дату новости двухмесячной давности при том, что страница явно проиндексирована не далее, как несколько дней назад, причем ее контент не один раз за это время изменился, остается только догадываться.
В общем, в сухом остатке имеем, что данное нововведение Google несомненно достойно того, чтоб его приветствовать, однако при его использовании для задач SEO-аналитики необходимо учитывать определенные нюансы.

пятница, 5 апреля 2019 г.

Гипотетический поисковик от Ahrefs - Вебальта №2?

С неделю назад промелькнула новость о том, что глава компании Ahrefs Дмитрий Герасименко заявил о том, что они делают свою поисковую систему, призванную создать конкуренцию Google. Среди конкурентных преимуществ нового поисковика заявлялось, в частности, разделение прибыли между поисковиком и авторами проиндексированного им контента.
Всё это мне очень напомнило историю тринадцатилетней давности (2006 год) о запуске российского поисковика Webalta, создатель которого поднявшийся на перепродаже трафика Алексей Гурешов заявлял о намерении занять за год 30% поискового рынка Рунета. Тогда было тоже много громких слов о том, что Яндекс зажрался, повернувшись к вебмастерам, а в особенности к сеошникам, исключительно задом, а Вебальта повернется к ним передом, будет с ними дружить и сотрудничать, помогать вебмастерам зарабатывать на своем контенте, а сеошники будут помогать ей улучшать качество поиска (ага, пусти козла в огород :) ). В общем, эдакий свойский поисковик для вебмастеров и сеошников «с блэкджеком и шлюхами». В итоге никакой доли рынка Вебальта не отжала, а через некоторое время была замечена на том, что без ведома пользователя стала устанавливаться на его компьютере в качестве стартовой страницы браузера, по сути став банальным вирусом. Как говорится, благими намерениями вымощена дорога в ад.

вторник, 2 апреля 2019 г.

Google запатентовал поведенческие факторы

Исторически Google, в отличие от Яндекса, никогда официально не признавал использование в ранжировании поведенческих факторов. Более того, устами своих сотрудников он открыто отрицал это, объясняя свое решение низким качеством этих сигналов.
Так, в 2014-м году на московской конференции Cybermarketing-2014 во время телемоста с европейской штаб-квартирой Google в Дублине сотрудник отдела качества поиска Андрей Липатцев недвусмысленно заявил, что поведенческие и социальные факторы с точки зрения разработчиков алгоритма ранжирования Google являются очень плохими и слишком шумными сигналами и поэтому не учитываются в алгоритме. Эта мысль постоянно звучала затем в многочисленных видеоконференциях сотрудников Google, как русско-, так и англоязычных, в частности Джона Мюллера.
И вот 18 марта 2019 года американский SEO-специалист Билл Славски обнаружил свеженький, датированный 12 марта 2019 года, патент Google под названием «Modifying search result ranking based on implicit user feedback» («Изменение ранжирования результатов поиска на основе неявной обратной связи с пользователем»).
Итак, что же подразумевается под «неявной обратной связью с пользователем»? Как оказалось, старые добрые поведенческие факторы. В частности, в патенте упоминаются следующие сигналы:
  1. Запрос, заданный пользователем, результаты поиска, предоставленные поисковой системой, документ, выбранный пользователем из числа результатов поиска, его позиция в порядке представления результатов поиска (“a query submitted by the user, one or more search results presented by the search engine in response to the query, a document selected by the user from among the search results, an ordinal position in a presentation order of the search results of the search result selected by the user”). То есть речь идет о так называемых «кликовых» поведенческих факторах, непосредственно связанных с поведением пользователя на странице поисковой выдачи. Замечу, что Яндекс вот уже 10 лет (начиная с алгоритма «Арзамас», запущенного в апреле 2009-го года) учитывает кликовые факторы (в свое время я достаточно подробно писал о кликовых факторах ранжирования в Яндексе).
  2. Время, проведенное пользователем на выбранном документе (“a time the user spent on the document”). Так называемая «длина клика». Далее поясняется, что под временем, потраченным пользователем на документ, подразумевается время, прошедшее от клика на документ в результатах поиска до возвращения к результатам поиска и выбора в них нового документа.
  3. Язык, используемый пользователем, и страна, где пользователь с большой долей вероятности находится (“a language employed by the user, and a country where the user is likely located”). Что свидетельствует о дифференцированном подходе к учету поведения пользователей в зависимости от их языка и страны. В общем-то, вполне логично, что разноязычные пользователи, равно как и пользователи, живущие в разных странах, могут иметь различные предпочтения в выдаче по одному и тому же запросу.
Информация по длине кликов в выдаче по определенному запросу от различных пользователей взвешивается на основе длины клика по срезам:
  1. запрос-документ
  2. запрос-документ-язык
  3. запрос-документ-язык-страна
По длине клики классифицируются на короткие, средние и длинные (причем, дифференциация по этим категориям на основе длины клика зависит от запроса), также выделяется категория «последнего клика». Каждая категория имеет соответствующий вес. В качестве примера приводятся следующие весовые коэффициенты. Короткий клик может считаться признаком плохой страницы и, следовательно, получает малый вес (например, 0,1). Средний клик может считаться показателем потенциально полезной страницы и, следовательно, получает несколько больший вес (например, 0,5). Длинный клик может считаться показателем хорошей страницы и, таким образом, получает гораздо больший вес (например, 1,0). Последний клик (когда пользователь не возвращается на страницу с результатами поиска) может считаться вероятным показателем хорошей страницы и, следовательно, иметь достаточно большой вес (например, 0,9).
При взвешивании кликов предлагается назначать меньший вес кликам тех пользователей, которые почти всегда выбирают высоко ранжируемые документы, по сравнению с кликами пользователей, которые чаще их выбирают документы с более низкими позициями. В общем-то, на мой взгляд, вполне логично понизить вес «голосов» пользователей, занимающихся тупым перебором всех подряд элементов в списке, не обращая внимание на сниппеты.
Также предлагается разделять пользователей на определенные типы. Указывается, что более опытным пользователям требуется меньше времени на получение информации, таким образом при учете кликов определенного пользователя может использоваться весовой коэффициент в зависимости от его индивидуального поведения в сети, например, учитывающий среднюю продолжительность сессии или частоту переходов между документами.
Кроме того, пользователь может быть определенным образом классифицирован на основе его потока запросов. В частности, предполагается, что пользователь, который задает много запросов по определенной теме, может иметь высокий уровень знаний по ней, и данные о его кликах могут быть соответствующим образом взвешены для будущих запросов от данного пользователя по данной теме.
В качестве «меры релевантности» предлагается использование составных показателей, таких, например, как отношение числа длинных кликов к коротким или отношение числа длинных кликов ко всем кликам для конкретного документа по конкретному запросу (доля длинных кликов). Причем, к отношениям может быть добавлен в качестве защиты от шума параметр сглаживания, обладающий следующим свойством – если общее количество кликов невелико, то результат будет стремится к нулю. Благодаря составным показателям документы, получающие относительно небольшое количество кликов, но в большинстве своем длинные, в итоге могут получить больший вес, чем документы, находящиеся на более высоких позициях и получающие за счет этого большее количество кликов, но имеющие относительно небольшую долю длинных кликов. То есть, как говорится, не CTR’ом единым…
Также параметры сглаживания могут варьироваться в зависимости от языка или страны пользователей. Примечательно, что в качестве примера географического источника запросов, среди которых исторически генерировалось больше спам-активности и которые потому требуют более жесткого сглаживания, указана Россия.
Упоминается и о возможности учета дополнительной информации, такой как позиции, численные значения релевантности и сниппеты как выбранных пользователем документов, так и показанных ему, но не выбранных им.
В итоге вычисленные значения меры релевантности в явном или преобразованном виде предлагается применять в качестве повышающего коэффициента к значениям релевантности, вычисленным алгоритмом ранжирования.
В тексте патента также провозглашается необходимость обеспечения защиты пользовательских данных от накруток. Что ж, вещь, несомненно, весьма актуальная, особенно для исторически спам-активной в этом плане России. Интересно, насколько эффективно ее будет решать Google, если дело дойдет до реализации заявленных в патенте положений.
Резюмируя, можно отметить, что ничего революционного в патенте не содержится. Всё вертится вокруг доли длинных кликов, как основной меры активности пользователя, и нюансах взвешивания данных от различных категорий пользователей. В хорошо известных статьях сотрудников Яндекса шести-семилетней давности на тему учета кликовых факторов «Session-based Query Performance Prediction» и «Through the looking glass: utilizing rich post-search trail statistics for web search» содержится информация о гораздо более разнообразных сигналах.
Ну, и не следует забывать, что наличие патента еще не означает непременной реализации указанных в нем вещей в «боевом» поиске. Но в любом случае мы получаем еще одно подтверждение, что задача удержания пользователей на сайте является одной из основных.


четверг, 28 марта 2019 г.

Кончина оператора info: в Google

«Иных уж нет,
А те – далече…»
А. С. Пушкин




Буквально неделю назад Google объявил о прекращении поддержки директивы prev/next, и вот еще одна новость прекращение поддержки оператора info: (“With this change, we’re also retiring the info: command”). Оператор уже отключен. Вместо него предлагается использовать Инструмент проверки URL (URL Inspection tool) сервиса Google Search Console. Однако воспользоваться этим инструментом можно только для страниц на сайте с подтвержденными правами. Таким образом, Google лишает нас по сути единственного инструмента быстрой проверки индексации конкретного URL с любого сайта. Операторы site: и inurl: для этой цели не совсем подходят, так как осуществляют поиск по маске. Более-менее эту задачу сможет решить оператор cache:, но, к сожалению,  он не предоставляет информацию о страницах, для которых поисковикам запрещен показ сохраненной копии мета-тегом robots со значением noarchive.
Что сказать, довольно печальная новость – минус один рабочий инструмент из арсенала SEO-специалиста.


четверг, 21 марта 2019 г.

Google прекратил поддержку директивы prev/next

Сегодня, 21.03.2019, в официальном твиттере Google Webmasters появилось сообщение о том, что Google официально прекратил поддержку директивы rel=prev/next:
В поиске еще находится страница со статьей из Справочного Центра Google Search Console об использовании атрибутов rel="next" и rel="prev" для того, чтоб сообщить Google о связях между страницами пагинации:
Однако, с сайта Google эта статья уже исчезла:
Хотя ее сохраненную копию (датированную 17 марта 2019 16:17:47 GMT) еще можно лицезреть в кэше поисковика:

В общем, не один Яндекс урезает функционал, но в принципе, я нахожу эту новость скорее положительной, так как она способствует унификации функционалов Google и Яндекса, данную директиву никогда не поддерживавшего. Если б еще Google дал бы добро на использование атрибута rel=canonical, указывающего на первую страницу пагинации, для последующих страниц, как это некогда сделал Платон Щукин, и было бы совсем замечательно.

среда, 13 марта 2019 г.

Сохраненные копии страниц – это не то, что находится в индексе

Издавна SEO-специалисты используют сохраненную копию страницы в поисковике для анализа индексации произведенных на странице изменений. Однако еще четыре года назад я заметил, что в Яндексе сохраненная копия может не совпадать с той версией страницы, которая реально находится на данный момент в поисковом индексе и используется в ранжировании. Сегодня мне хотелось бы проверить, можно сейчас ли доверять сохраненной копии Яндекса. Ну, и заодно посмотреть, как с этим обстоят дела у его основного конкурента на отечественном рынке поиска – Google.
Для анализа мне понадобится страница, на которой публикуется текущая дата. Сопоставляя дату, которая находится в сохраненной копии с датой, по которой эта страница находится в поисковике, и которая может показываться при этом в ее сниппете, можно сделать вывод о соответствии версии страницы, демонстрируемой в сохраненной копии и версии страницы, находящейся в поисковом индексе. Для нашей цели как нельзя подойдет главная страница Яндекса.
Итак, анализируем сначала ситуацию в самом Яндексе, найдя главную страницу Яндекса с помощью документированного оператора url: запросом url:yandex.ru и открыв ее сохраненную копию. Находим в ней дату (на момент анализа – это «25 февраля, понедельник, 22:23»):
Итак, попробуем найти по точной текстовой фразе с этой датой в Яндексе его главную страницу. Увы, но сделать этого не удалось. Мы получаем сообщение, что точного совпадения не нашлось:
Получается, в поисковом индексе находится версия главной страницы Яндекса от другой даты. С помощью несложных манипуляций с изменением даты в поисковой фразе убеждаемся, что в индексе содержится более ранняя версия главной страницы Яндекса. К сожалению, Яндекс не соизволил нас порадовать показом текстового соответствия в сниппете (видимо, считая данный текст служебным и малозначимым), однако отсутствие фразы «Точного совпадения не нашлось» красноречиво свидетельствует о том, что именно данная фраза содержится в той версии страницы, что находится на данный момент в поисковом индексе:
Более того, можно убедиться в том, что сохраненная копия в Яндексе может иметь несколько версий, показываемых попеременно. Так, обновляя страницу с сохраненной копией главной страницы в Яндексе, мы можем время от времени увидеть другую ее версию с другой датой (в моем случае – «24 февраля, воскресенье 22:37»), но все равно не совпадающей с той, по которой страница находится в индексе:
Итак, ситуация в Яндексе не изменилась. Сохраненная копия по-прежнему не совпадает с той, что находится в индексе и участвует в ранжировании.
Ну, а что же по этому поводу думает Google? Сохраненную копию страницы можно посмотреть напрямую с помощью оператора cache. Делаем в Google запрос cache:yandex.ru, получаем сохраненку и находим в ней дату:
К сожалению, оператор site: в Google в случае его применения к главной странице сайта показывает выдачу по всему сайту, и по запросу по дате без времени мы получаем достаточно много страниц с сайта в выдаче (с сервиса Яндекс.Погода и т.п.), что затрудняет анализ. Но добавив в запрос время, убеждаемся, что по точной фразе выдача пуста:
Для того, чтоб облегчить нахождение даты версии, находящейся в индексе, воспользуемся одним интересным приемом. Есть в Google оператор получения сведений о странице info:, который показывает сниппет указанной страницы в случае наличия ее в индексе. К сожалению, этот оператор не желает корректно работать в связке с поисковым запросов, т.е. не является аналогом оператора site:. Однако, если справа от этого оператора использовать какой-либо термин, то в случае наличия его точного вхождения в тексте страницы, мы можем увидеть сниппет с подсветкой этого термина. Используя в качестве такого термина название текущего месяца в соответствующем падеже, получаем отображение даты в сниппете, и убеждаемся в том, что она не совпадает с той, что содержится в сохраненке:
Проверим с помощью запроса по точной фразе, что в поисковом индексе действительно находится версия страницы с указанной датой:
Любопытно, что в Яндексе версия анализируемой страницы в сохраненной копии свежее версии в индексе, а в Google – наоборот.
Итого в результате несложного анализа убеждаемся в том, что ни в Яндексе, ни в Google нельзя быть уверенным в том, что версия страницы, показываемая в сохраненной копии, используется для ранжирования. И этот факт обязательно необходимо учитывать при анализе поисковой выдачи дабы избежать ложных выводов.

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