четверг, 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 нельзя быть уверенным в том, что версия страницы, показываемая в сохраненной копии, используется для ранжирования. И этот факт обязательно необходимо учитывать при анализе поисковой выдачи дабы избежать ложных выводов.

пятница, 1 марта 2019 г.

Яндекс стал учитывать кросс-доменный canonical?

Сегодня получил документальное подтверждение об учете Яндексом кросс-доменной директивы canonical. По одному из проектов пришло вот такое письмо от сервиса Яндекс.Вебмастер:
Все бы ничего, но сработал canonical со страницы, находящейся на одном поддомене (m.),  на страницу, расположенную на другом поддомене (www.)
В документации же Яндекса до сих пор можно найти, что "робот может не использовать указанный вами адрес, если: ... в качестве канонического адреса указывается URL в другом домене или поддомене".
Ну да ладно, «может» - не «должен», но заметим, что речь идет о директиве canonical, указывающей со страницы мобильной версии, находящейся на отдельном поддомене, на соответствующую ей страницу десктопной версии на основном поддомене. В полном соответствии с требованиями другой поисковой системы – Google, второй по значимости на отечественном рынке.
Впрочем, и собирательный образ сотрудника службы поддержки пользователей Яндекс Платон Щукин в своем блоге так комментировал ситуацию с директивой canonical, указывающей с мобильной версии страницы на десктопную: "Атрибут rel="canonical" использовать необязательно, робот его проигнорирует в случае, если он указан на мобильном поддомене для страниц основного сайта."
Однако, как видим, робот этот атрибут не проигнорировал, и владелец сайта оказывается в ситуации слуги двух господ, не зная, как одновременно угодить каждому из них. Если оставить canonical, то Яндекс выкинет страницы мобильной версии из индекса как неканонические, если убрать его, то нарушится требование Google.  

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