Автор: Сергей Людкевич - независимый консультант, супермодератор форума о поисковых системах Searchengines.Guru. Сфера профессиональных интересов - исследование алгоритмов ранжирования поисковых машин, разработка методик поискового продвижения сайтов.
Вот уже в четвертый раз мне приходится поднимать тему поиска надежного способа определения геозависимости запроса. Ибо с завидной регулярностью действующий вариант метода теряет свою работоспособность.
Напомню, последняя версия метода определения геозависимости базировалась на двух принципах:
Принцип первый. Для запросов, не содержащих топоним, соответствующий региону выдачи, этот топоним в сниппетах подсвечивается для геозависимых запросов и не подсвечивается для геонезависимых запросов.
Принцип второй. Добавление к исходному запросу через документированный оператор | («логическое ИЛИ») какого-либо достаточно редкого термина (т.е. имеющего достаточно большое значение IDF – обратной частоты встречаемости в коллекции документов) никак не влияет изменение геозависимости запроса.
И если первый принцип продолжает действовать, то второй, к сожалению, уже не соответствует действительности, в чем можно убедиться на следующем примере. Возьмем геозависимый запрос продвижение сайтов, в геозависимости которого легко можно убедиться по подсветке топонима Москва уже на первой странице выдачи для соответствующего региона (lr=213):
Однако добавление к исходному запросу через оператор | («логическое ИЛИ») любого термина, в том числе и очень редкого, меняет геозависимость нового запроса, делая его геонезависимым, что можно определить по исчезновению подсветки топонима:
Таким образом, подобную модификацию исходного запроса уже нельзя использовать для определения его геозависимости, что существенно снижает наши возможности.
Конечно, хорошо, когда топоним, соответствующий региону выдачи, встречается в сниппетах уже на первой странице выдачи (которую можно расширить до 50 результатов в браузерной выдаче и до 100 результатов в Яндекс.XML), как в нашем первом примере. И по наличию или отсутствию его подсветки можно легко определить геозависимость запроса. Но если искомый топоним в сниппетах не встречается на первой странице поисковой выдачи (что весьма характерно для геонезависимых запросов), то без дополнительных запросов не обойтись.
В этом случае было бы хорошо быстрее найти документ, релевантный исходному запросу, в заголовке сниппета которого показывался бы топоним, соответствующий региону выдачи. А затем, сузив выдачу по исходному запросу на этот документ, получить гарантированное наличие или отсутствие подсветки искомого топонима, по которой и определить геозависимость исходного запроса.
Для поиска такого документа я предлагаю модифицировать исходный запрос, добавив в его начало топоним, соответствующий региону выдачи. Причем, для повышения эффективности я рекомендую применить к этому топониму документированный оператор + («плюс»), предназначенный для поиска документов, в которых обязательно присутствует выделенное им слово. Для примера возьмем исходный запрос конхоида никомеда (для которого топоним, соответствующий региону выдачи, не встречается в первой сотне результатов), и модифицируем его предлагаемым способом. Искомый топоним находится в заголовке одного из сниппетов уже на первой странице выдачи:
Теперь сужаем исходный запрос на найденный нами документ (введя его адрес в поле «На сайте» формы расширенного поиска), и наблюдаем отсутствие подсветки топонима в сниппете, что свидетельствует о том, что исходный запрос геонезависим:
Также для сужения можно применить к исходному запросу документированный оператор url: (поиск по страницам, размещенным по заданному адресу), в качестве его значения задав адрес найденного на первом этапе документа.
При поиске подходящего документа нужно иметь в виду, что если исходный запрос состоит из одного слова, то желательно также и к нему применить оператор + («плюс»). Если этого не сделать, то в выдаче может быть довольно много документов, в которых этот термин из исходного запроса не встречается. Это обусловлено тем, что даже одно из слов двухсловного запроса (в данном случае — топоним) может проходить так называемый кворум. Желающих поподробнее разобраться в сути этого явления могу отослать к главе «Фильтрация по кворуму» эпохальной статьи «Яндекс на РОМИП-2004. Некоторые аспекты полнотекстового поиска и ранжирования в Яндекс».
Таким образом, в выдаче может встречаться много документов, релевантных топониму и не релевантных исходному запросу. А это может сильно затруднить поиск подходящего для дальнейшей проверки документа, который обязательно должен быть релевантен исходному запросу. Кстати, у использовавшегося мною в качестве примера исходного двухсловного запроса конхоида никомеда, первое слово в одиночку проходит кворум, что видно из последнего примера – найденный нами релевантный исходному запросу проверочный документ второе слово исходного запроса (никомеда) не содержит, и запросу, состоящему из него одного, нерелевантен.
Конечно, предлагаемый способ не так удобен, как потерявший работоспособность предыдущий, но, тем не менее, вполне позволяет решить задачу определения геозависимости запроса, пусть и с большим количество обращений к поиску. И остается только надеяться, что все используемые в нем документированные операторы языка запроса Яндекса будут работать корректно.
На мероприятии Google NYC сотрудник поиска Джон Мюллер рассказал, какие изменения ожидают вебмастеров в ближайшие месяцы. В частности, речь шла о Search Console, поиске по картинкам и переходе на mobile-first индексацию.
По статистике Яндекса, 83% пользователей уходит с сайтов без правильного SSL-сертификата. Потому что люди избегают опасных сайтов. Если на вашем сайте некорректный сертификат безопасности, пользователь видит в браузере соответствующее предупреждение.
Яндекс сообщает, что в будущем подобные предупреждения будут показываться пользователям не только в браузере, но и в поисковой выдаче.
В сентябре инженеры Google Chrome заявили, что работают над новым способом идентификации сайтов, который призван заменить традиционные URL-адреса.
На днях на конференции Bay Area Enigma руководитель команды Chrome Usable Security Эмили Старк рассказала о первых шагах, предпринятых в этом направлении.
Mail.Ru запустила бета-версию своей рекомендательной системы «Пульс», которая предлагает пользователям контент с учетом их интересов. Персонализация работает на базе технологий машинного обучения.
Алгоритм новой ленты анализирует большой объем информации, включая поведение пользователей в социальных сетях и на других сайтах, историю их кликов на сервисе, популярность источников и другие факторы. Система самостоятельно обучается, и чем чаще пользователь взаимодействует с сервисом, тем точнее будут рекомендации.
Комментариев нет:
Отправить комментарий