Статистика сканирования в Google Search Console: где найти и что смотреть

Открываете Search Console — и сразу тянетесь к «Эффективности». Клики, показы, знакомый ритуал. А отчёт, который показывает, что Googlebot реально делал на сайте последние примерно 90 дней, лежит не в сайдбаре. Он спрятан в Настройках. Ирония в том, что именно оттуда часто быстрее видно: сайт «тормозит» для бота, сыпется в 404 или просто не отдаёт новое.

Ниже — как открыть «Статистику сканирования», что читать в блоках и какую короткую проверку делать раз в месяц. Без культа «краулингового бюджета» как магической цифры. Скрины — пример с реального проекта; цифры на графиках смотрите сами, в текст их как «норму для всех» переносить нельзя.

И да: этот отчёт не заменяет логи сервера. Покрытие запросов у Google может быть неполным. Длинной истории как у «Эффективности» здесь нет — важные срезы лучше сохранять скринами.

А где это вообще?

Путь короткий, если знать куда ткнуть: ресурс в GSC → Настройки → блок Сканирование → Статистика сканирования → Открыть отчёт.

На экране отчёт сидит рядом с robots.txt, а не рядом с кликами. Рядом — не значит «одно и то же»: robots отвечает «можно ли», статистика сканирования — «что бот уже сделал».

Нюанс по типу ресурса. Отчёт есть у доменного свойства и у URL-префикса на корне хоста. Добавили в GSC только подпапку — пункта может не быть. Тогда смотрите домен или префикс вида https://example.com/.

Что на верхних карточках

Сверху — сводка примерно за 90 дней: запросы на сканирование, объём скачивания, среднее время ответа. Ниже график и статус хоста — были ли проблемы с доступностью с точки зрения обхода.

Красивая пила на графике сама по себе мало что говорит. Смотрите связки. Время ответа растёт, а запросов становится меньше — Google мог начать обходить осторожнее. Тогда копают нагрузку, TTFB, бэкенд и доступность, а не заголовки H1. В статусе хоста были сбои — сначала чинят инфраструктуру. SEO-тексты на недоступном сайте работают примерно как зонтик в серверной.

Чужие цифры со скрина не тащите в свой KPI-отчёт клиенту. У витрины, СМИ и огромного каталога «норма» разная. Важны динамика и ваши релизы.

А если сыпятся коды?

Дальше — распределение запросов по ответу: сколько ушло в успешный ответ, сколько в 404, редиректы и 5xx.

Всплеск 404 после чистки раздела или кривого редиректа — классика. Всплеск 5xx — сначала сервер и приложение, метатеги подождут. Редиректы 301/302 сами по себе не приговор, но если их внезапно стало много относительно вашей обычной картины, спросите: бот не бегает ли по цепочкам?

Нуля не-200 ответов ждать наивно. Смотрите всплески относительно своей базы и дат выкладки.

На что уходит обход

Рядом блок по типу файла: HTML, картинки, CSS, JavaScript и прочее.

Если картинки и служебные ресурсы раздуваются, а HTML стоит на месте, стоит проверить: не кормите ли вы бота тяжёлым «не-HTML» там, где для индекса это лишнее. Иногда помогает точечно пересмотреть robots и структуру URL. «Закрыть всё подряд» — плохая идея. Картинки и CSS не равны проблеме сами по себе. Проблема — когда перекос совпадает с тем, что важные страницы обходят хуже.

Новое или опять старое?

Блок по цели делит обход на Обновление (Refresh) и Как обнаружено (Discovery). Refresh — бот вернулся к уже известному. Discovery — взял URL как новое.

Публикуете регулярно, а Discovery около нуля месяцами? Чаще виновата не «дыра в бюджете», а обнаруживаемость: слабые внутренние ссылки, sitemap без нового, новые URL висят в стороне от сильных разделов. Высокий показатель обновления на спокойном сайте без частых новинок — нормальная история. Паниковать из-за одной доли Обновление не нужно.

Тип робота Googlebot на том же экране — полезный контекст, но для ежемесячной проверки важнее тройка: время ответа, коды, Discovery/Refresh.

Что проверить за 15 минут

Раз в месяц хватает короткого прогона:

• открыть отчёт на домене или корневом URL-префиксе и глянуть статус хоста;

• сверить запросы и среднее время ответа: нет ли связки «медленнее отвечаем — меньше обходят»;

• проверить всплески 404 и 5xx после релизов;

• оценить типы файлов и Discovery/Refresh на фоне плана публикаций;

• сохранить скрин — окно короткое, длинного архива нет;

• если сигнал тревожный — взять примеры URL и копать точечно, а не спорить про «бюджет» абстрактно.

Чего лучше не делать

Не путайте отчёт с «Эффективностью»: кликов здесь нет. Не обещайте рост позиций от одного графика запросов. Не раздувайте «краулинговый бюджет» без данных — сначала время ответа, хост, 4xx/5xx и то, как находятся новые URL. Не судите по одному дню. И не копируйте проценты чужого проекта как «норму».

Если симптом уже есть, идите глубже: для одного URL — Проверка URL и взгляд «глазами» робота; для массовых таймаутов — логи и мониторинг; для «бот не видит новое» — sitemap и перелинковка. Статистика сканирования хорошо показывает куда смотреть. Саму починку она за вас не сделает.

Что в итоге

Отчёт в Настройках — не секретный рычаг ранжирования. Это спокойный срез: как сайт отвечает боту, чем заканчивается обход и находит ли Google новое. Раз в месяц откройте его, пробегите связки выше — и только потом спорьте о текстах и ссылках.

Если на проекте уже видно устойчивый рост времени ответа, всплеск ошибок или «тихий» Discovery при живых публикациях, это повод для технического разбора.

Контекст по теме уже есть в опубликованных материалах: сайт глазами Googlebot и технический аудит.