вторник, 22 октября 2019 г.

«Кошелек или жизнь?» – как понравиться асессорам Google

5 сентября 2019 года вышла очередная версия Руководства Google для асессоров. Ну, а 24 сентября стартовал очередной апдейт алгоритма ранжирования – September 2019 Core Update. Уже стало традицией, что обновления этого Руководства непременно предшествуют скорому знаковому обновлению алгоритма ранжирования. Так, например, предыдущее обновление случилось 16 мая 2019-го года, а уже в начале июня выдачу по многим тематикам основательно перетряхнул June 2019 Core Update. А предшествовавшее ему обновление Руководства от 20 июля 2018-го года ознаменовалось в начале августа 2018-го знаменитым Medic Update
Эти явно неслучайные совпадения заставляют подходить к изменениям в Руководстве Google для асессоров с большим вниманием. Да и сотрудник Google Дэнни Салливан в свое время заявлял, что руководство для асессоров является ключом к обновлениям основного алгоритма. Лично мне показались заслуживающими пристального внимания изменения в следующих разделах.
Во-первых, значительно обновился раздел 2.3 Your Money or Your Life (YMYL) Pages. Указанные в нем категории были изменены, изменился также и порядок их представления.  


Первое место заняла категория «Новости и текущие события» («News and current events»), что может означать, что Google повысил приоритет этой категории среди других источников YMYL контента. Сразу же вспоминается нашумевшая в западном SEO-сообществе история про то, как после последнего июньского апдейта алгоритма (June 2019 Core Update) сайт английской газеты Daily Mail потерял половину трафика из Google. Обращает на себя внимания также тот факт, что собственно новости выделены из более общей категории «Новостные статьи или публичные/официальные страницы, важные для информирования населения» («News articles or public/official information pages important for having an informed citizenry»).
Оставшаяся без новостей часть этой категории вместе с категорией «Правовая информация» («Legal information pages») сформировали новую категорию «Гражданское право, правительство и закон» («Civics, government, and law»), расположившуюся на втором месте списка. Кстати, июньский апдейт Google вместе с новостными ресурсами основательно «потрепал» и информационные сайты правовой сферы.
Категория «Покупки и финансовые операции» («Shopping or financial transaction pages») превратилась просто в «Покупки» («Shopping»). Судя по новому описанию этой категории, информационный контент, связанный с потребительской сферой, также является YMYL контентом наряду с онлайн-магазинами и другими страницами, где совершаются финансовые онлайн-операции.  Думаю, этот факт стоит учесть владельцам информационных ресурсов в этой сфере – обзорников, отзовиков и т.п.
Категория «Медицинская информация» («Medical information pages») оказалась переименована в «Здоровье и безопасность» («Health and safety»). Налицо явное расширение профессиональной медицинской темы на более общую информационную тему о здоровье в общем. Сразу же вспоминается нашумевший «медицинский» апдейт («Medic Update»), и не исключено, что можно ожидать повторения, затрагивающего большее количество информационных ресурсов данного направления.
Ну, и внизу списка появилась новая категория «Группы людей» («Groups of people»), судя по ее описанию, затрагивающая информационный контент, связанный с различными социальными группами. Есть повод задуматься владельцам различных «сообществ по интересам».
Также обращает на себя внимание тот факт, что в качестве носителя контента YMYL в новой редакции Руководства указаны не только страницы («pages»), но и темы («topics»), что может означать то, что страница может быть признана носителем YMYL контента в том случае, когда под определение YMYL попадает только часть ее содержимого, не являющееся основной целью страницы.  
Собственно, из всего вышеперечисленного можно сделать вывод, что количество ресурсов (особенно информационных), попадающих под определение носителей YMYL контента, может значительно увеличиться, а, значит, их владельцам придется основательно задуматься о соответствии их ресурсов обозначенным в пункте 3.2 Expertise, Authoritativeness, and Trustworthiness (E-A-T) Руководства Google для асессоров принципам E-A-T («Экспертность, Авторитетность и Надежность»). 
Анонимный или скопированный без указания авторства контент, размещенный на ноунейм сайтах теперь, похоже, будет иметь ничтожно мало шансов на хорошее ранжирование в YMYL темах. У контента должны быть обозначены конкретные авторы, равно как у сайта – владельцы. Даже если на сайте преобладает user-generated контент (форумы, Q&A сайты и т.п.), пользователи, его генерирующие, должны иметь индивидуальные профили, и чем больше в профиле будет информации, подтверждающей экспертность пользователя в данной теме, тем лучше. 
Не случайно абзац, добавленный в пункт 5.2 Very Positive Reputation Руководства Google для асессоров свидетельствует о достаточно высоких требованиях к уровню экспертизы создателей контента, особенно в профессиональных областях, таких как медицина:




Кроме того, о качестве и актуальности контента тоже придется позаботиться. Собственно, раскрытию понятия высококачественного основного контента (Main Content или МС) как раз посвящено еще одно значимое изменение в Руководстве Google для асессоров – значительное увеличение информации в пункте 5.1 Very High Quality MC:
 


В обновленной версии появилось описание признаков качества для новостного, художественного и информационного типов контента. Подчеркнуты важность оригинальности, точности, полноты, соответствия профессиональным стандартам, а также упоминания первоисточников в случае необходимости. 
В общем, чтобы не стать жертвой очередного апдейта Google, многим сайтам, похоже, придется основательно позаботиться о качестве своего контента и об авторитетности его авторов. Ну, или продолжать уповать на то, что прошлогодние слова сотрудника Google Джона Мюллера от том, что Google не смотрит на репутацию авторов контента при ранжировании сайта все еще остаются актуальными. Впрочем, апдейт покажет.

понедельник, 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.