понедельник, 23 сентября 2019 г.

Летние изменения в поиске Яндекса

Несмотря на то, что лето традиционно является периодом отпусков, похоже, в поисковом департаменте Яндекса вовсю кипит работа. Ибо нововведения в поиске продолжают появляться одно за другим.
Начнем с того, что в начале июня в блоге разработчиков Яндекса устами Платона Щукина было заявлено об изменениях в учете директивы canonical, а именно, что "атрибут rel со значением canonical элемента link теперь рассматривается как указание на главное зеркало в группах зеркал сайтов с www и без www, а также с http и https". Вместе с тем Платон Щукин подчеркнул, что "межхостовый атрибут все ещё не поддерживается, поэтому, если отдельные страницы будут содержать атрибут с такими указаниями, как неканонические, они из поиска не выпадут". Да и на соответствующей странице Яндекс.Помощи указано, что "робот Яндекса не учтет канонический адрес, если: ... В качестве канонического адреса указан URL в другом домене или поддомене"
Однако мне удалось встретить в отчетах сервиса Яндекс.Вебмастер самое что ни на есть прямое подтверждение, что страница на одном поддомене признана канонической для страницы с другого поддомена:
Причем, здесь идет речь не о склейке поддоменов, а именно о консолидации отдельных страниц. Возможно, расширение функционала директивы canonical вызвало вот такие любопытные артефакты. Что ж, нововведение скорее положительное, а если еще и заработает междоменный canonical, то это будет однозначный плюс.
Но на этом Яндекс в изменении своего взгляда на директиву canonical не успокоился. В начале июля последовал анонс нового отношения Яндекса к директиве canonical, который я анализировал в своей предыдущей статье «Неканонический canonical». Вкратце – Яндекс заявил, что будет игнорировать директиву canonical в том случае, если сочтет, что контент страниц, указанных как каноническая и неканоническая, существенно различается. По горячим следам анонса я высказал надежду, что директива canonical будет игнорироваться только в случае, если неканоническая страница будет сочтена действительно полезной и качественной. Однако, увы, практика показала, что неканонические страницы запросто удаляются Яндексом из индекса как некачественные:
   
То есть по сути директива canonical перестала быть удобным инструментом для консолидации страниц, контент которых может различаться (например, страниц пагинации, сортировки, результатов фильтрации и т.п.). И если для конкретного сайта игнорирование директивы canonical с последующим признанием неканонических страниц некачественными будет носить массовый характер, то, на мой взгляд, будет целесообразным отказываться от использования этой директивы в пользу 301-го редиректа для индексирующих ботов. Так что данное нововведение представляется мне однозначно со знаком «минус», так как сильно ограничивает возможность управления консолидацией страниц сайта.
В середине августа произошло изменение в интерфейсе поиска Яндекса, не удостоившееся официального анонса. Тихо и незаметно из меню дополнительной информации сниппетов поисковой выдачи исчез пункт «Показать еще с сайта». Причем, на момент написания статьи упоминание об этом пункте еще сохраняется в соответствующем разделе Яндекс.Помощи. И пока еще можно увидеть, как это меню выглядело еще совсем недавно:
А вот как это меню выглядит в поисковой выдаче сейчас:
Вместо пункта «Показать еще с сайта» появились пункты «Информация о сайте» и «В избранное», не имеющие отношения к поисковому функционалу. 
О том, что это отнюдь не случайность, свидетельствует и исчезновение поиска по сайту из фильтров расширенного поиска:
Причем, в данном случае соответствующая страница Яндекс.Помощи это изменение зафиксировала оперативно.
В общем, в Яндексе отчетливо прослеживается тенденция к упрощению поискового функционала. Так сказать, возврат от сложных форм к простым. Можно это называть архаизацией, можно дебилизацией, но суть от этого не меняется. Времена Кубка Яндекса по поиску давно канули в лету, поисковые инженеры теперь думают над тем, как избавить пользователя от необходимости думать. Такое впечатление, что эволюция поискового интерфейса Яндекса медленно, но верно идет к аналогу легендарной гугловской кнопки «I’m Feeling Lucky» («Мне повезет»), но с той разницей, что она будет единственной и выдавать ответ будет с наиболее подходящего яндексовского сервиса.
Хотя, следует признать, что физически возможность поиска по сайту не исчезла, пока еще функционируют get-параметр site
и поисковый оператор site:
Исчезла только возможность воспользоваться этой функцией, используя интерфейс.
Что же касается Google, то у него также нет возможности поиска по сайту ни из сниппетов, ни из инструментов поиска на странице выдачи. Однако у него есть такая возможность на странице расширенного поиска, аналог которой в Яндексе на данный момент отсутствует. Конечно, пока функционал поиска по сайту в Яндексе физически существует, это нововведение нельзя считать сколько-либо значимым в плане ограничения возможностей для анализа поисковой выдачи, но сам по себе звоночек, на мой взгляд, тревожный.
И, наконец, 20 августа 2019 года Яндекс объявил об изменении правил работы с контентными зеркалами. Суть изменений заключается в том, что Яндекс теперь не будет склеивать полные дубли сайтов. Склейка зеркал сайтов будет осуществляться только через 301-й редирект. Таким образом Яндекс наконец-то прикрыл одну очень неприятную дыру в алгоритме склейки зеркал. Дело в том, что разместив на подконтрольном домене копию чужого сайта можно было рассчитывать на то, что при склейке зеркал Яндекс может назначить главным зеркалом именно ваш дубликат, а не чужой оригинал. Соответственно, весь поисковый трафик и все внешние поисковые сигналы оригинала перетекали при склейке к главному зеркалу, то есть подконтрольному злоумышленнику сайту. Ну, а как дальше распоряжаться полученным добром, это уже зависело целиком от его фантазии. Самое интересное, что когда владелец оригинала, обнаружив, что его сайт стал второстепенным зеркалом неподконтрольного ему дубликата, обращался в Яндекс, то он получал от Платона Щукина стандартный отлуп, о том, что "вручную расклеить сайты возможности нет, так как процесс автоматизирован", с предложением решать проблему с хостером сайта-дубликата или радикально изменить контент своего сайта, чтоб могла сработать автоматическая расклейка: 
В общем, данное нововведение Яндекса можно только всячески приветствовать как несомненно оздоравливающее поисковую экосреду. Здесь поисковым инженерам Яндекса можно поставить однозначный зачёт.


вторник, 6 августа 2019 г.

Неканонический canonical

4 июля 2019 года в блоге разработчиков Яндекса появилась заметка «Неканонические страницы в Поиске», в которой разработчики поисковой системы поведали о своем новом отношении к директиве canonical. Теперь они собираются выполнять ее только в том случае, если страница, которая ее содержит, несущественно отличается о той, которая указана в этой директиве как каноническая.
К слову сказать, Google также может проигнорировать директиву canonical, если содержимое канонической и неканонической страницы существенно различается. Причем я встречал курьезные случаи, когда не согласившись с канонической страницей, выбранной пользователем, Google не смог выбрать каноническую страницу сам, при этом все-таки выкинув неканоническую страницу из индекса:


У директивы canonical есть два неоспоримых преимущества. Во-первых, происходит так называемая консолидация URL, при которой объединяются нетекстовые факторы канонической и неканонической страниц. Так, например, Google в своей «Справке» упоминает об объединении ссылок и переходов. Что касается Яндекса, то о том, что факторы неканонической страницы учитываются для канонической, говорил сотрудник компании Александр Смирнов на Шестой Вебмастерской.
Во-вторых, несмотря на то, что неканоническая страница исключается из поискового индекса, поисковики знают о ссылках, которые на ней находятся, и включают ее в ссылочную структуру сайта. Так, например, собирательный сотрудников службы поддержки Яндекса Платон Щукин высказывался следующим образом: «При этом ссылки на товары, которые находятся на неканонических страницах, также будут известны индексирующему роботу».
Поэтому, на мой взгляд, использование директивы canonical – наиболее предпочтительный инструмент объединения страниц сайта, вписанных в ссылочную структуру сайта, хотя и не самый оптимальный с точки зрения оптимизации краулингового бюджета, о чем я писал в своей предыдущей статье.
Однако теперь с его помощью может не получится объединить страницы, содержание которых существенно различается. Порассуждаем, в каких случаях это может произойти.
Первое, что приходит в голову – это дубликаты одной и той же страницы с динамическим контентом, расположенные на разных URL. Поисковые боты сканируют эти URL в разные моменты времени и получают различный контент. В итоге в индексе может накопиться некоторое количество копий по сути одной и той же страницы.
Если URL дубликатов отличаются от канонического URL только наличием get-параметров, то для Яндекса можно воспользоваться директивой Clean-Param в файле robots.txt. Но этот метод не является универсальным, т.к. Google эту директиву не поддерживает. В случае Google можно будет воспользоваться инструментом «Параметры URL» в Google Search Console. Однако поисковые машины не уточняют, будет ли в данном случае происходить консолидация URL без параметров и URL с параметрами, сканирование которых запрещается. Поэтому данный способ я бы предпочел применять только в крайнем случае.
Консолидация URL произойдет, если поисковому роботу при посещении неканонической страницы отдать код статуса 301 Moved Permanently с редиректом на каноническую. Причем, обычным пользователям можно показывать неканоническую страницу с кодом статуса 200 ОК. Нарушением с точки зрения поисковых систем это не будет. Криминал возникает там, где поисковику показывают содержимое, отличное от того, что получает пользователь.  Здесь же поисковик не будет получать никакого содержимого.
Однако в отличие от директивы canonical, в данном случае у поисковика не будет информации о ссылках, ведущих с неканонической страницы. Поэтому данный метод я рекомендую использовать в тех случаях, когда неканонические страницы не вписаны в ссылочную структуру сайта, например, для страниц с get-параметрами в URL, не влияющими на ее содержимое – utm-метки, идентификаторы сессии. 
В случае же, когда неканоническая страница является достаточно важным элементом ссылочной структуры сайта, например, страницы пагинации или страницы с результатами фильтрации, то демонстрация поисковому роботу кода статуса 301, на мой взгляд, не будет оптимальным решением.
Так же как и практикуемый некоторыми SEO-специалистами способ, который заключается в размещении на странице мета-тега robots со значением ”noindex, follow”. В данном случае поисковик получит информацию о содержащихся на страницах ссылках, но исключит эту страницу из индекса без консолидации с каноническим URL. Да и к тому же со временем и информация о ссылках может перестать учитываться
Итого результаты анализа можно свести в небольшую таблицу:
Способ
Консолидация
Учет ссылок
canonical
+
+
Clean-Param / Инструмент «Параметры URL»
?
-
301 для ботов
+
-
<meta name="robots" content="noindex, follow">
-
+

Таким образом достойной альтернативы директиве canonical для страниц, вписанных в структуру сайту, не просматривается.  Остается только надеяться, что поисковик, проигнорировав эту директиву из-за существенных различий содержимого неканонической страницы с содержимым страницы, указанной как каноническая, будет считать в этом случае страницу действительно качественной. И что такие страницы не будут впоследствии удаляться из индекса как некачественные без консолидации URL и учёта ссылок с них, да еще и с негативным вкладом в «карму сайта». 

четверг, 4 июля 2019 г.

Оптимизация краулингового бюджета

На днях в новостной ленте промелькнула заметка о том, что сотрудник компании Google Гэри Илш в своем твиттере ответил, что URL, закрытые от индексации в файле robots.txt, не влияют на краулинговый бюджет этого сайта:

Вместе с тем в ответе на один из вопросов к этому посту в твиттере Гэри признал, что если запретить к индексации бесполезные страницы, то краулинговый бюджет будет «возвращен» («will gain back»), открытым для индексации полезным страницам:

Все эти «словесные кульбиты» натолкнули меня на мысль порассуждать на тему краулингового бюджета и его эффективного использования. Оговорюсь сразу, что тема оптимизации краулингового бюджета актуальна только для сайтов с достаточно большим числом страниц – счет должен идти на десятки, а то и сотни тысяч. Небольшим сайтам заморачиваться на эту тема смысла не имеет – поисковики их будут переиндексировать довольно шустро в любом случае.
Итак, вводные данные следующие. Мы определились, какие страницы на сайты мы считаем полезными для индексации, а какие – бесполезными, т.е. по сути мусором, который, находясь в индексе, может являться источником различного рода проблем. В терминах Google это называется low-value-add URL. И наша задача – убрать из индекса бесполезные страницы наиболее эффективным образом. В том числе и с точки зрения оптимизации краулингового бюджета. 
Для начала уточним, что же подразумевается под краулинговым бюджетом? Если коротко, то это число страниц с кодом статуса 200 ОК, которое индексирующий робот поисковой системы отсканирует за одну сессию. Это число (равно как и частота сканирования) зависит от различных факторов, например, таких как популярность сайта, уже имеющееся число страниц в индексе и т.п. 
Судя по всему, Гэри Илш, говоря, что запрещенные к индексации файлом robots.txt страницы никак не влияют на краулинговый бюджет, имел в виду то, что, так как поисковая система заведомо знает о том, что они запрещены к индексированию (а значит, индексирующему роботу не нужно их сканировать), то никоим образом не учитывает их при расчете краулингового бюджета. 
В ситуации же описываемой в последующем вопросе, когда осуществляется запрет к индексации уже известных поисковой системе страниц, на которые в том числе расходовался краулинговый бюджет, произойдет следующее – выделенный краулинговый бюджет начнет расходоваться только на страницы, которые не запрещены к индексации. Это Гэри Илш и называет «возвращением» бюджета полезным страницам, т.к. в вопросе явно указано, что происходит закрытие бесполезных страниц. Кстати, теоретически при закрытии страниц от индексации краулинговый бюджет в абсолютных цифрах может и уменьшиться, т.к. уменьшится число проиндексированных страниц на сайте, но он будет расходоваться более эффективно именно для полезных страниц.
Поэтому для оптимизации краулингового бюджета может быть действительно хорошим вариантом закрытие к индексации файлом robots.txt бесполезных страниц, имеющих код статуса 200 ОК. Однако здесь могут быть нюансы. Так, например, если какие-то их этих страниц имеют входящие ссылки или ненулевой целевой трафик, то исключение таких страниц из индекса повлечет исключение из ранжирования этих значений, что теоретически может негативно сказаться на расчетных показателях релевантности проиндексированных страниц сайта. В общем, запрет для индексации в файле robots.txt может быть хорошим решением только для тех URL, которые с точки зрения ссылочных и поведенческих факторов абсолютно неинтересны. 
Также следует иметь в виду, что запрет к индексации страниц с помощью мета-тега robots со значением noindex на оптимизацию краулингового бюджета существенно не повлияет.  Потому что этом случае закрываемая от индексации страница имеет код статуса 200 ОК, и поисковик исключит ее из индекса только после того, как индексирующий робот ее просканирует. И в последующем индексирующий робот будет все равно вынужден такие страницы переобходить. Единственное, на что можно надеяться – так это на то, что он это будет делать с меньшей частотой чем для страниц, которые не были запрещены к индексированию с помощью мета-тега robots. Ну, хотя бы по крайней мере для тех страниц, которые имеют такой запрет на индексацию на протяжении нескольких сканирований подряд. Хотя, на мой взгляд, подобные надежды основываются на очень зыбкой почве.
Поэтому, на мой взгляд, наилучший способ исключить бесполезные страницы из краулингового бюджета – это изменить для них код статуса с 200 ОК на 301 Moved Permanently с редиректом на разрешенную к индексации полезную страницу, имеющую отклик 200 ОК. В таком случае страница с кодом статуса 301 должна «подклеиться» к странице, на которую ведет редирект с нее, причем с передачей некоторых характеристик, которые относятся к нетекстовым факторам ранжирования (например, такие как ссылочные или поведенческие). Google называет это консолидацией URL. Запомним этот термин и будем его в последующем применять. Кстати, в случае Яндекса необходимо иметь в виду следующий нюанс – подклеить страницу к странице, расположенной на другом поддомене сайта, в общем случае не получится. 
Да, пожалуй, это было бы идеальное решение, оптимально закрывающее две задачи – избавления индекса от бесполезных страниц и оптимизации краулингового бюджета. Например, оно хорошо применимо для решения проблемы устаревших страниц, которые когда-то имели трафик и до сих пор имеют входящие ссылки. Но, к сожалению, оно применимо далеко не во всех случаях.  Есть масса вариантов, когда страница с точки зрения владельца сайта должна по той или иной причине иметь код статуса 200 ОК, но при этом с точки зрения поисковика ее можно считать бесполезной, например:
  • дубликаты четкие, например, отличающиеся только наличием get-параметров в URL, которые важны владельцу сайта с точки зрения веб-аналитики;
  • дубликаты нечеткие, например, результаты многокритериальной фильтрации листингов товаров интернет-магазина, по факту слабо отличающие друг от друга по набору удовлетворяющих различным значениям фильтров товаров;
  • страницы пагинации листингов товаров в интернет магазинах
и т.п.
С точки зрения склейки страниц с сопутствующей ей консолидацией тут есть прекрасный заменитель 301-му редиректу – директива canonical. Однако с точки зрения краулингового бюджета это не самый оптимальный вариант, т.к. неканоническая страница должна иметь код статуса 200 ОК
В этом случае краулинговый бюджет можно оптимизировать с помощью специальной обработки запросов от поисковика, имеющих заголовок If-Modified-Since. Алгоритм действий следующий – убедившись, что поисковик посчитал конкретную страницу неканонической (это можно сделать через сервисы Яндекс.Вебмастер и Google Search Console), необходимо запомнить дату, и в последствии на запросы индексирующего робота с заголовком If-Modified-Since, содержащим дату позднее запомненной, отдавать код статуса 304 Not Modified вместо 200 ОК. Страницы с кодом статуса 304 не будут расходовать краулинговый бюджет.
Кстати, тот же самый прием можно применить для оптимизации краулингового бюджета в случае, о котором я писал несколько выше – когда бесполезные страницы по той или иной причине закрываются от индексации с помощью мета-тега robots со значением noindex. В этом случае нам нужно запомнить дату, когда поисковик исключил запрещенную к индексации страницу из индекса, чтоб потом использовать ее при специальной обработке запросов от индексирующего робота с заголовком If-Modified-Since.
В общем-то, специальная обработка запроса If-Modified-Since очень полезна с точки оптимизации краулингового бюджета и для полезных страниц с сайта, для которых известна дата последнего изменения их контента. Всем запросам индексирующих роботов поисковых систем с заголовком If-Modified-Since, содержащим дату позднее известной нам даты последнего изменения контента страницы, следует отдавать код статуса 304 Not Modified. Однако тут тоже есть один нюанс – такие страницы лишаются возможности попадать в так называемую «быстроботовскую» примесь для свежих результатов. Поэтому для тех страниц, которые релевантны запросам, имеющим быстроботовскую примесь, все-таки я бы рекомендовал отдавать всегда код статуса 200 ОК. Ибо возможность попадания в топ выдачи как свежий результат намного важнее оптимизации краулингового бюджета.



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