В новом аудиоподкасте №383 Николай Шмичков рассказал про то, что Noindex не спасет.
Google Учитывает Скорость Загрузки на Закрытых страницах.
Текстовая версия выступления:
«Всем привет!
Вы на канале SEOquick.
Меня зовут Николай Шмичков.
И это обзор свежих новостей и свежей онлайн прессы, относительно Google Core Web Vitals.
Того самого фильтра, который выходит буквально вот-вот скоро.
На самом деле, по поводу него идут огромные споры.
И первый же вопрос который задали, действительно, у всех был на слуху, но его никто не задавал.
Крутился, как говорится, на языке.
Это: “А если у меня страница медленная и я её закрою от индексации – это улучшит мое ранжирование?
Да или нет?”
На самом деле Core Web Vitals может принимать во внимание не индексируемые странице.
Google утверждает, что не индексируемые страницы по-прежнему можно использовать для оценки Core Web Vitals, которые вскоре действительно станут факторами ранжирования в поиске.
Иными словами: страницы, которые намеренно вы исключили из поискового индекса, могут быть использованы для оценки показателей, которые влияют на ваш рейтинг в выдаче.
Конечно же, это нормальная причина для беспокойства.
Потому что, мы же скрываем часто от индексации какие-то внутренние тяжелые страницы, которые находится внутри нашего сайта.
И оказывается, что это будет влиять на рейтинг.
И как же с этим бороться?
Этот вопрос задали Джону Мюллеру 4 декабря и он на него ответил, буквально недавно.
Задали вопрос, связанный с использованием в Google агрегированных данных для измерения Core Web Vitals.
Google берёт страницы группы, анализирует их, использует данные для расчета Core Web Vitals вашего сайта, представляющих весь сайт.
И его спросили в таком формате.
Core Web Vitals учитывает не индексированные страницы и объекты, заблокированные в robots.txt.
Выходит, что страницы, которые попадают в индекс анализа Search Console, получаются довольно-таки обширные.
И некоторые из них могут попадать туда, даже заблокированные для robots.txt.
И, собственно, Джон Мюллер ответил, что он считает что не индексированные страницы являются частью вашего веб сайта.
Поэтому, если вы используете какие-то дополнительные функции, которые не индексируются, люди по-прежнему видит их как часть вашего веб-сайта.
Говорят, что этот ваш сайт медленный или же сайт быстрый.
На самом деле, User Experience Google считает на основе данных, которые он берёт основываясь на тех страницах, которые попали на его анализ.
Вероятно, эти страницы будут проиндексированы в будущем.
Либо эти страницы не проиндексированы по какой-то ошибке.
И поэтому эти данные Google берёт в основу.
Самое обидное, получается, что просто закрыться robots.txt или тегом noindex для того, чтобы скрыть медленную страницу, у вас попросту не выйдет.
Обоснования нужны для изменения восприятия страницы.
Потому что, таким образом пользователь должен знать, что есть внутренние страницы, которые находятся на вашем сайте.
И на которые он может попасть, уже переходя из той страницы, которая находится в индексе.
И таким образом Core Web Vitals сказывается в целом и на весь сайт, а не только по страничным факторам ранжирования.
Поэтому, я бы выделил Core Web Vitals все-таки алгоритмом, который является не постраничным, а именно частично их остовом.
Потому что, общий показатель сайта будет сказываться в зависимости от того, как Google просканирует и ваши внутренние страницы.
Что делать дальше?
Я бы прогнал весь ваш сайт на анализ PageSpeed.
Прогнал бы все страницы, которые у вас есть, на скорость загрузки.
Сделал бы это как-то массово.
Проверил бы медленные страницы и, действительно, занялся их исправлением.
Я понимаю, что в Search Console можно вытащить данные по пейджспиду, и по мобильным ошибкам.
Но иногда, эти данные могут приходить не вовремя и недостаточно их просто проверять для сайта, который ещё не вышел в индекс.
Поэтому, я бы в этом плане посоветовал воспользоваться какими-то сторонними сервисами анализа PageSpeed.
Мы сейчас разрабатываем аналогичный, словно знали куда смотреть, где подстелить.
И вы можете воспользоваться нашим инструментом “Веб-сайт аудит”.
Вскоре он будет доступен для массового анализа PageSpeed для списков страниц, которые вы ему скормите.
Следующее, на что я хотел бы обратить внимание – это то, что индексируемый контент, который вы отдаете в Google на анализ PageSpeed, иногда им могут манипулировать.
Могут сделать страницы заглушки.
Вам могут показывать красивый PageSpeed, просто за счет того, чтобы вставлять пару строчек кода, которые обманывают пользователя.
Я побоялся бы сейчас экспериментировать с такими трюками, по одной простой причине.
Google может всерьез взяться за этот метод обмана.
Побанить те сайты, которые пользовались таким методом обхода его собственного алгоритма PageSpeed.
Поэтому закрывать не индексируемый контент массово каким-то дешевыми методами, я бы точно не советовал.
Лучше сделать хороший, грамотный технический аудит.
Именно уделить внимание скорости загрузки.
Всем этим ключевым 6 показателям, который я обсуждал в прошлом видео, по поводу скорости сайта.
И действительно выписать список ошибок программисту.
У вас фактически три месяца на закрытие всех этих проблем.
Почему?
Потому что, я уверен что Core Web Vitals выкатят в следующем апдейте ядра.
Про него сейчас в основном идут только разговоры.
А как мы знаем, раз Google ведет какие-то разговоры – он это выкатывает в следующем большом, либо через одно, обновлении.
А про Core Web Vitals мы уже говорим полгода.
Значит, если считать, условно говоря, что декабрьский вышел апдейт.
Январь, февраль, март…
У нас получается будет, вероятно, мартовский или апрельский апдейт.
Вот он примерно выйдет в тот период.
Формально, у вас три месяца на то, чтобы улучшить показатели скорости своего сайта.
Нужно смотреть не только индексируемые странице, но еще и те, которые находятся внутри.
Это касается странички регистрации, оформления заказа, внутреннего личного кабинета, и всего контента, который доступен только после регистрации.
Всему контенту нужно будет уделить внимание: он должен быстро загружаться.
И я видел сайты, который снаружи выглядят быстрыми, а после регистрации – начинают жутко тормозить и долго прогружаться.
Это действительно проблема, с которой Google будет бороться.
Если вам понравился разбор этих новостей, то напишите, что вы думаете по поводу этой новости в комментариях.
Хотелось бы услышать ваше мнение.
Мое мнение, что в целом идея достаточно разумная.
Но, конечно, несправедливая для тех сайтов, у которых куча технических багов.
Потому что они могут очень сильно посыпаться, если у них есть внутренние страницы, которые они забыли позакрывать, поудалять.
Которые являются не индексируемыми, но являются старыми.
Допустим, глюки темы после переезда, какие-то глючные страницы после загрузки.
Их всех нужно, получается, выкопать и изучить.
Оптимальный вариант, как выкопать список страниц, которые находятся не в индексе.
Зайти в собственной webmaster, посмотреть какие там страницы находятся.
Выкачать список этих страниц из Google Вебмастера.
Он будет ориентироваться, в первую очередь, только на них.
И конечно же разобраться с ними: либо убить, либо редиректить.
Сделать с ними что-то такое, чтобы те страницы, которые являются бесполезными…
А чаще всего такой мусор бесполезный там и находится – его нужно как-то убрать.
Именно из-за него могут быть у вас и большие проблемы в следующем обновление ядра.
Делайте технический Аудит.
Вовремя исправляйте.
Берете в команду толковых программистов.
И, как говорится, первых мест вам и органики из Google.
Всем спасибо и с наступающими праздниками!»
