Въедливый анализ отчетов Google Search Console: о чем не пишут в справке

Если история браузера не врет, за неделю я изучил 300 с лишним отчетов в Google Search Console. Это при том, что часть рутинной аналитики у меня давным-давно автоматизирована, многие важные данные выгружаются по API.

Панели вебмастера Google просто приходится уделять повышенное внимание – там есть важная для SEO информация, которую не получить из других источников. К сожалению, статистику из SC далеко не всегда можно использовать сразу, без уточнений и дополнительных проверок. Разберем несколько показательных примеров, которые помогут лучше понять логику работы Search Console и корректно интерпретировать ее отчеты.

Почему данные Search Console могут быть неполными?

В справке перечислены некоторые причины:

  • Чтобы защитить конфиденциальность пользователей, в отчете “Анализ поисковых запросов” показаны не все данные. Например, мы можем не отслеживать запросы, введенные всего несколько раз или содержащие личную информацию.
  • Различия в статистике могут являться следствием дополнительной обработки данных (например, для исключения дубликатов и посещений роботов). Однако эти расхождения обычно незначительны.
  • В различных инструментах понятие “ключевые слова” определяется по-разному. Например, инструмент подбора ключевых слов в Google AdWords показывает общее количество запросов по ключевому слову, сделанных пользователями всего Интернета. В отчетах “Анализ поисковых запросов” указываются только те запросы, по которым ваши страницы показывалсь в результатах Google Поиска.
  • Статистика для веб-мастеров обновляется с некоторой задержкой, хотя мы и собираем ее непрерывно. Обычно данные обновляются в течение двух-трех дней.
  • Необходимо учитывать часовой пояс. Дневные показатели для отчета “Анализ поисковых запросов” отслеживаются по тихоокеанскому времени (PDT). Если в ваших системах веб-аналитики используется другой часовой пояс, число просмотров за день в них может отличаться. Например, в Google Analytics время указано по часовому поясу веб-мастера.

(конец цитаты)

Больше всего статистика искажается из-за первого пункта. Практически все оптимизаторы сталкивались с ситуацией, когда консоль явно показывает не все поисковые запросы. Вот пример, найденный за пару минут:

Видим, что страница показывалась в выдаче и на нее были переходы, но в отчете нет ни одного поискового запроса. Впрочем, отсутствие информации по 9 показам – это ерунда. Недавно мне повстречался целый сайт, который месяцами получает вполне заметный трафик из Google – и имеет такую же девственно чистую таблицу поисковых запросов в Search Console.

Что еще может помешать правильно воспринимать отчеты?

Официальная справка объясняет только часть возникающих проблем. Есть более глобальная причина, по которой к целому ряду отчетов нужно относиться с осторожностью. Я попробую сформулировать ее коротко:

Сканирование, индексирование, ранжирование – сложные процессы, а Search Console использует небольшое число простых терминов и показателей. Это лишь одна грань работы поисковой системы. Иначе и быть не может: отдав владельцам сайтов слишком много информации о поисковых алгоритмах, Google слишком сильно усложнил бы себе задачу борьбы со поисковым спамом.

Рассмотрим совсем простой (на первый взгляд) вопрос.

Как определить количество проиндексированных в Google страниц?

Начинающие оптимизаторы применяют оператор “site:” (напоминаю: для оценки количества документов в индексе он вообще не предназначен).

Использовать данные Search Console более правильная идея. Вот только для начала не помешает разобраться, какую именно консоль использовать. На множестве сайтов показатели старой и новой панелей различаются.

Вот пример (обращаю внимание на всплывающую подсказку):

 

Сравните:

На одну и ту же дату старая панель показывает в два раза больше проиндексированных. Beta-версия SC отмечала вторую половину страниц как “Страница просканирована, но пока не проиндексирована”.

Под графиком старой панели есть ссылка на справочный материал. Цитирую:

Иногда данные на странице “Статус индексирования” могут лишь частично соответствовать тому, как ваш сайт представлен в результатах поиска. В ряде случаев при формировании результатов поиска Google применяет фильтры, которые препятствуют показу той или иной страницы. С их помощью можно удалять страницы по запросу веб-мастера или из-за нарушения ими законодательства, сайты, которые, по нашему мнению, в данный момент не работают, и сайты, к которым вручную применены меры за распространение спама.

Поскольку эти фильтры обычно применяются из-за временных неполадок на сайтах или по ошибке, в ряде случаев Google хранит отфильтрованные страницы в индексе в течение некоторого времени. Благодаря этому после устранения проблем URL таких страниц снова будут отображаться в результатах поиска (например, когда сайт вновь станет доступен).

В этом тексте есть два особенно любопытных места. Во-первых, употребляется слово “фильтры”, которое так не любят некоторые участники справочного форума для вебмастеров. Меня неоднократно пытались втянуть в спор о терминах, доказывая, что у Google, дескать, фильтров нет. Ну да, ну да. Видимо, справку им создают злые хакеры.

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

Если посмотреть на отчет новой консоли вместе с вкладкой “исключено”, то может показаться, что ситуация полностью ясна: старый отчет вроде бы должен объединять данные отчетов “Страница без ошибок” и “Страница просканирована, но пока не проиндексирована”.

Увы, все не так просто.

Со второй попытки нахожу сайт, где:

  • 2,82 тыс. страниц в статусе “пока не проиндексирована”;
  • 1,15 тыс. страниц в статусе “без ошибок”;
  • 2,9 тыс. страниц в индексе согласно старой версии.

Изучаем статус “Страница просканирована, но пока не проиндексирована” подробнее

Проблема несоответствия показателей в разных версиях Search Console давно уже меня интересовала. Я внимательно наблюдал за несколькими сайтами, где были страницы в статусе “пока не проиндексирована”.

3 июля я выгрузил 1000 страниц, которые показывались в этом статусе и проверил их нахождение в поиске с помощью оператора info:. Из 1000 url не найденными оказалось только 5 штук.

Сегодня консоль показывает следующую картину:

Спустя 11 дней большая часть этих страниц поменяла статус на “без ошибок”.

Значит ли это, что возможность быть найденной с помощью оператора info: – это один из этапов индексации? Сложно сказать. Зато очевидно, возможность быть найденной с помощью оператора info: и полноценное присутствие в поиске – разные вещи. По крайней мере согласно логике Search Console. Можем ли мы ей доверять? Давайте посмотрим.

Возьмем другой сайт и изучим результаты отчета “просканирована, но пока не проиндексирована” более детально. Откроем отчет и сделаем очень простую вещь: сравним результаты двух предлагаемых проверок:

Не составило труда найти 33 страницы, для которых:

  • “Просмотреть в поиске” (применение оператора info:) позволяет найти url.
  • “Проверить url” сигнализирует, что URL нет в индексе Google.

В то же время встречаются и такие, где info также не дает результата.

Мы получили еще одно подтверждение наличия разных этапов индексирования и/или разных степеней присутствия страницы в индексе Google. Пойдем дальше.

Посмотрим, как ранжируются эти страницы. Берем их title и забиваем в поиск. Результаты такие:

  • В одном случае 2 позиция.
  • В другом 20-я.
  • В 31 случае сайт не найден в ТОП-100.

Любопытно, что заключение поисковой фразы (напоминаю, это title документа) в кавычки только ухудшает результат: та же самая страница ищется на 2 месте, все остальные – за пределами ТОП-100.

Подытожим: страница в статусе “просканирована, пока не проиндексирована” может находиться в двух принципиально разных состояниях: полностью отсутствовать в индексе, либо ранжироваться с большим “штрафом”. Не исключено, что этих состояний больше.

На закуску разберем еще один отчет.

Насколько точны данные о последнем сканировании страницы?

Обнаружив такие явные расхождения в плане статуса страниц я усомнился и в других данных. В первую очередь меня заинтересовала дата последнего сканирования документа роботом. Знать ее весьма полезно для ряда аналитических задач.

На экспериментальном сайте нашелся 1 url, длительное время находящийся в статусе “Обнаружена, не проиндексирована”. Для этого ресурса меня есть полный access.log за все время его существования.

Если кто-то не в курсе, то следить за роботами в логах – одно из моих любимых развлечений. Частенько оно приносит пользу.

Search Console говорит, что робот вообще не посещал эту страницу.

Согласно лог-файлу, Googlebot посещал эту страницу 5 раз, последний – 24 января. Разумеется, я проверил IP визита через обратный DNS-запрос, робот действительно принадлежал Google.

Любопытно посмотреть заодно, что это за страница на самом деле. Это url, отдающий 404-ю ошибку. Он был удален с сайта и исключен из системы навигации, но остался в карте сайта (sitemap.xml). Так вот, робот Google действительно ни разу его не посещал с момента удаления из навигации. Еще одно подтверждение моего наблюдения, что роль sitemap.xml для Google сильно преувеличивают.

Конечно, единичный пример мало что доказывает. Посмотрим на страницы другого сайта.

Для страницы с датой последнего сканирования 26 мая в лог-файле были найдены следующие строки (оставил самое важное – дату и User-agent робота):

[24/May/2018:07:01:45 +0300] “Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2272.96 Mobile Safari/537.36 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)”
[26/May/2018:00:34:19 +0300] “Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)”
[26/May/2018:19:17:23 +0300] “Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2272.96 Mobile Safari/537.36 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)”
[28/May/2018:10:17:37 +0300] “Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2272.96 Mobile Safari/537.36 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)”
[29/Jun/2018:03:03:31 +0300] “Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)”
[02/Jul/2018:07:04:27 +0300] “Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)”

Таким образом, в логах зарегистрировано еще 3 визита робота после 26 мая.

Обращает на себя внимание тот факт, что первый из них очень близок по времени к дате к зарегистрированному в консоли. Возможно из-за этого (а также из-за отсутствия изменений в документе) он не учитывается.

С двумя другими  не отображаемыми в SC ситуация интереснее. Легко видеть, что это заходы десктопного робота. 3 июля (то есть уже после всех заходов) пришло письмо о переводе сайта на mobile-first индекс. Если предположить, что в Console отображаются только визиты Googlebot, обеспечивающие обновление индекса, то получается, что отсутствие письма “Mobile-first indexing enabled for” вовсе не означает, что для сайта не используется мобильный индекс.

Впрочем, все это только предположения. Зато можно с уверенностью сказать что Search Console не дает полной картины сканирования сайта роботом.

Основные выводы и зачем вообще нужно знать о нюансах Search Console

  1. Данные в Search Console зачастую являются неполными (Google сам об этом говорит).
  2. Причины искажений – желание защитить конфиденциальность пользователей, сложность и секретность поискового алгоритма, задержки в обновлении.
  3. Страница может быть представлена в поиске по-разному. Документы в статусе “пока не проиндексирована” зачастую находятся в с помощью оператора info:, однако испытывают существенные проблемы в ранжировании. Проверка индексации с помощью info: не позволяет отделять полноценно “работающие” страницы от тех, кто по факту не способен давать трафик из Google.
  4. Страницы, указанные только в sitemap.xml и не являющиеся акцепторами ссылок могут длительное время не посещаться роботом.
  5. Дата последнего сканирования, указанная в beta-версии Search Console, часто не учитывает ряд визитов Googlebot на страницу.

Как это все применять на практике? На самом деле странный вопрос – если уж вы дочитали до конца и не заснули, то должны знать пару-тройку вариантов (как минимум). Намекну для тех кто схитрил и просто пролистал до конца: например, имеет смысл поискать другие способы проверки индексации. Они есть.

Самое главное, что нужно понимать про неполноту и задержки в обновлении данных Search Console:

  • это проблема в плане ежедневной аналитики и большинства экспериментов, так как приходится перепроверять данные и привлекать дополнительные их источники, что замедляет процесс.
  • это возможность для изучения принципов, по которым работает Google. Нестыковки вроде описанных выше – отличная отправная точка для исследований.

Второй пункт особенно актуален сейчас, когда параллельно существуют две Search Console с внушительным разнообразием данных. Ловите момент!

5 комментариев

  1. Интересно, как тогда корреткно чекать индекс для большого ИМ на котором сотни страниц под ультра НЧ могут быть созданы (теги, листинги фильтров и т.д.). Ведь именно эти страницы могут быть жизненно важными для магазина и наиболее конверсионными.
    Если SC искажает данные, выходит, что только поможет терпение и только терпение, пока такие страницы зайдут в индекс?

    • Ну если Console показывает, что страница в индексе (то есть в “зеленом” отчете новой версии), то пока я не нашел оснований ей не доверять. В любом случае если страница в статусе “просканирована, но пока не проиндексирована” – с ней нужно разбираться (просто есть нюансы как именно). Проблемы возникают больше в плане изучения конкурентов.

  2. Алексей, ну так и что за другие способы проверки индексации?
    А, может, поделитесь и способами или сервисами загона в индекс?
    У меня проблем с индексацией моего сайта нет. Но есть проблемы с индексацией страниц со ссылками на него.

    • Алексей, ну так и что за другие способы проверки индексации?

      Должна же оставаться интрига 🙂 На самом деле все довольно просто, в статье есть подсказка.

      А, может, поделитесь и способами или сервисами загона в индекс?

      Насколько эффективны будут такие ссылки если страницы даже в индекс зайти не могут?
      По теме – строим ссылочную массу на доноров или как минимум загоняем на них робота с блогов/форумов. Сейчас, к сожалению Twitter работает не так хорошо, как раньше, но есть и другие площадки (стоит смотреть в сторону не особо известных и не особо заспамленных но активных ресурсов). В ленте пишут о новом сервисе который работает с помощью посещений страниц браузерами поисковиков (название не припомню), но там история скорее под Яндекс.

  3. Спасибо за статью! Актуально, т.к. у меня резко выпали в старой search console 900 страниц, и в целом из 2тыс страниц проиндексированных на сегодня всего 32.. Шок!
    В новой консоли – приндексировано 350, и 1700 со статусом “Исключено – просканировано, но не проиндексировано”.
    Похоже у Google снова серьезно меняются алгоритмы.
    Да и старую консоль отключают через неделю.

Оставить ответ