Статистика сканирования в Search Console: как читать состояния хоста и структуру запросов
Статистика сканирования Google Search Console помогает понять, когда Google сталкивался с проблемами получения страниц и каких запросов стало больше. Начинайте с выбранного хоста, периода и конкретной группы ответов. Затем сверяйте наблюдение с журналами инфраструктуры. Один пик на графике не объясняет причину сбоя, а зелёное состояние хоста не подтверждает работу всех пользовательских функций.
Ниже — порядок чтения Crawl Stats report: от области отчёта до проверяемой задачи для разработчика или хостинга. Все числовые примеры и адреса учебные; они не описывают измерения какого-либо реального сайта.
1. Проверьте, какой ресурс и хост вы изучаете
По актуальной справке Crawl Stats, отчёт доступен в настройках Domain property и корневого URL-prefix; ресурс подпапки не подходит. Итоги URL-prefix включают HTTP и HTTPS, но примеры URL ограничены протоколом ресурса.
Например, https://example.com/ и https://example.com/catalog/ — разные области работы в Search Console. Если вторая не показывает нужный отчёт, сначала выберите подходящий ресурс с необходимыми правами. Не делайте вывод об отсутствии обхода только потому, что искали статистику внутри подпапки.
Описание отчёта в Google Search Central объясняет сводку нескольких хостов и историю состояния хоста за последние 90 дней. Перейдите от общей картины к нужному поддомену. У учебного магазина отдельные www.example.com и media.example.com могут обслуживаться разными системами, поэтому общая кривая способна скрыть локальную проблему.
Запишите ресурс, хост и фактические крайние даты выгрузки. Такой заголовок нужен каждому сравнению: иначе один сотрудник смотрит основной сайт, другой — доменную сводку, а их одинаково названные показатели оказываются несопоставимыми.
2. Разделите число запросов, байты и время ответа
Три верхних показателя отвечают на разные вопросы:
| Показатель | Смысл | Следующий вопрос |
|---|---|---|
| Всего запросов | Учтённые обращения и попытки обхода | Какая группа дала прирост? |
| Объём скачивания | Полученные при обходе байты | Изменился размер ответов или их количество? |
| Среднее время ответа | Среднее по получаемым ресурсам | Какие ответы изменили общую картину? |
Не называйте последний показатель временем загрузки сайта в браузере или TTFB без проверки методики. Пользователь дополнительно ждёт выполнения JavaScript, построения интерфейса и других этапов, которые эта подпись не измеряет. Среднее также скрывает распределение: одинаковый результат возможен при равномерных задержках и при небольшом числе очень медленных ответов.
Учебный расчёт показывает влияние состава запросов. Тысяча ответов по 100 мс и тысяча по 900 мс дают среднее 500 мс. Если быстрых ответов стало девять тысяч, а медленных осталась тысяча, среднее снизится до 180 мс: (9000 × 100 + 1000 × 900) / 10000. Медленная группа при этом не ускорилась.
Байты ресурсов вне области отчёта не учитываются. Поэтому показатель не равен всему трафику страницы, объёму диска или счёту провайдера. При сравнении с журналом отдельно уточняйте, какое поле размера записано, учитываются ли заголовки и сжатие. Не приписывайте Crawl Stats эти детали без подтверждённого определения.
Суточная сумма также не показывает пиковую интенсивность. В учебном интервале ровно 24 часа двадцать тысяч обращений дают около 0,23 запроса в секунду в среднем: 20000 / 86400. Однако заметная часть обращений могла прийти коротким всплеском. Для оценки одновременной нагрузки нужны более мелкие интервалы в журналах и показатели обслуживающих компонентов. Деление дневного итога на секунды не доказывает, что серверу хватало мощности в момент отказа.
3. Не превращайте запросы в количество страниц
Повторные обращения и запросы серверной цепочки перенаправлений учитываются отдельно. Данные относятся к запрошенным URL, а не перераспределяются на canonical. Также учитываются ресурсы страниц в области отчёта.
Представьте учебную карточку, которую Google запрашивал утром и вечером. Вместе с ней были нужны стили и изображения. По общему счётчику нельзя установить, сколько новых карточек обнаружено: часть активности относится к повторной загрузке и вспомогательным файлам. Для уникальных адресов нужен отдельный подсчёт с заранее определёнными правилами обработки параметров URL.
В итог могут входить потенциальные обходы, отменённые из-за недоступности robots.txt. Поэтому превышение числа запросов над строками access log не обязательно означает потерю записей.
Практическая проверка обхода Googlebot начинается с определения единицы: обращение, уникальный URL, документ или ресурс. Не сравнивайте число товаров в базе с общим числом обращений за день. Сначала выделите соответствующие маршруты и решите, считаются ли варианты параметров одной карточкой. Это правило вашей аналитики, которое нужно сохранить одинаковым в обоих сравниваемых периодах.
4. Используйте состояние хоста как направление расследования
Сводка различает отсутствие значимых проблем, прошлые проблемы и проблемы последней недели. Детализация разделяет robots.txt, DNS и соединение с сервером. Начните с категории, которая дала предупреждение, затем переходите к датам и отдельным случаям.
Это высокая степень обобщения. Короткий отказ мог затронуть несколько запросов или произойти между обращениями Google; он не обязан менять итоговую оценку. Поэтому сообщение покупателя о недоступности страницы нельзя отвергать только из-за зелёного значка. И наоборот, историческое предупреждение не доказывает, что сервер недоступен прямо сейчас.
В руководстве Google по DNS и сетевым ошибкам описаны отказы до получения HTTP-ответа: проблемы разрешения имени, таймауты и сбросы соединения. При таком событии полноценного статуса страницы может не быть. Проверяйте DNS и защитный слой, а не только обработчик приложения.
Формулировку «Googlebot: ошибки хостинга» полезно разложить на владельцев работ. За DNS отвечает команда управления доменом; за блокировку на CDN — администратор защитных правил; за отказ приложения — разработчик. Один красный статус не назначает виновного поставщика и не доказывает нехватку мощности.
5. Отличите отсутствие robots.txt от невозможности его получить
Согласно правилам обработки robots.txt Google, ответ 404 означает отсутствие файла ограничений. Это не то же самое, что 5xx, таймаут или сетевая ошибка. При серверных ошибках Google сначала приостанавливает обход, продолжая попытки получить файл; дальнейшее поведение зависит от сохранённой успешной версии и доступности сайта.
Поэтому наличие 404 в истории robots.txt само по себе не требует аварийного ремонта. Важнее выяснить, какой ответ действительно возвращался и был ли он ожидаемым. При этом успешная выдача файла не подтверждает правильность его правил: доступный документ может содержать ошибочное ограничение важных разделов.
Для учебного инцидента сравните ответ robots.txt на CDN и на исходном сервере за один интервал. Если приложение работает, но CDN периодически возвращает 503 именно на этом пути, исправление главной страницы не решит проблему. Передайте владельцу инфраструктуры адрес, время, код и сведения о слое, который сформировал ответ.
Не удаляйте ограничения автоматически ради зелёного индикатора. Сначала восстановите предсказуемую выдачу предусмотренного файла, затем отдельно проверьте смысл правил. Доступность документа и разрешённость конкретного обхода — разные вопросы.
6. Читайте четыре разбивки как разные срезы
Отчёт группирует активность по ответу, типу файла, цели и типу Googlebot. Открывайте нужную строку, смотрите её временной ряд и примеры. Не складывайте проценты из разных таблиц: один запрос одновременно относится к нескольким измерениям.
Доля типа файла считается по ответам, не по байтам. Discovery означает первое сканирование URL, Refresh — повторное. Page resource load относится к загрузке ресурсов страницы; изображение в этой роли не обязательно попадёт в группу Image.
Например, большое число обращений за CSS не доказывает, что стили занимают большую часть переданных байтов. Аналогично рост Discovery не показывает число успешно проиндексированных новых страниц. Название цели помогает выбрать направление анализа, но результат последующей обработки нужно проверять другими средствами.
Официальный перечень распространённых краулеров Google различает Googlebot для смартфонов и компьютеров, изображения и другие назначения. В самом отчёте могут встречаться также AdsBot и иные категории. Не переносите все изменения общей кривой на один поисковый обход HTML.
Если доля JavaScript равна 40%, а доля 5xx — 8%, их произведение не даёт долю ошибок JavaScript. Неизвестно, как эти группы пересекаются. Для ответа нужны связанные записи отдельных запросов. Эта оговорка особенно важна при обсуждении, какой отдел должен исправлять пик.
7. Оценивайте код вместе с назначением адреса
Google описывает 5xx и 429 как сигналы проблем обслуживания, которые способны замедлять обход. Успешный 2xx не гарантирует индексирования. Значит, рост ошибок требует разбора доступности, а большое количество успешных ответов ещё не доказывает полноту поискового представления сайта.
Обычный 404 у удалённого адреса может соответствовать правильной работе. Тот же код у действующего каталога после выпуска — уже другой случай. Возьмите примеры, уточните ожидаемое поведение и оцените затронутые разделы. Не ставьте цель убрать все 404 перенаправлением на главную: такой подход скрывает различия между реальными страницами и отсутствующими ресурсами.
Сохраняйте рядом абсолютное число и долю ошибок. Если неудачных ответов стало больше только потому, что существенно вырос общий объём, ситуация отличается от роста их вероятности. Если объём резко упал, маленькое число ошибок тоже может сопровождаться высокой долей. Для решения нужны обе величины и одинаковый период.
8. Разберите учебный пик без поспешного вывода о причине
Возьмём три равных суточных интервала одного хоста. Для простоты все учтённые обращения в этом примере получили классифицируемый ответ; отменённых попыток из-за robots.txt нет. Числа полностью вымышлены.
| Показатель | До пика | День пика | После изменения |
|---|---|---|---|
| Запросы | 10 000 | 20 000 | 12 000 |
| Ответы 5xx | 100 | 1 600 | 60 |
| Доля 5xx | 1% | 8% | 0,5% |
| Среднее время ответа | 250 мс | 700 мс | 280 мс |
Запросов стало вдвое больше, ошибок — в 16 раз. Доля выросла на 7 процентных пунктов: 1600 / 20000 × 100 = 8%. После изменения получаем 60 / 12000 × 100 = 0,5%. Это полезные наблюдения, но слово «после» ещё не подтверждает, что именно внесённое изменение исправило ситуацию.
Могли одновременно закончиться рекламная кампания, обновление каталога или сбой внешней зависимости. Сопоставьте версии приложения, инфраструктурные события и состав запросов. Снижение среднего времени тоже не доказывает ускорение каждой страницы: пример со смешением быстрых и медленных ответов показывает почему.
Для отчёта руководителю корректная формулировка такая: «В день пика выросли объём и доля 5xx; в следующем сопоставимом интервале показатели снизились. Причину проверяем по журналам и истории изменений». Она отделяет подтверждённый факт от гипотезы.
9. Найдите группу, которая дала основной прирост
Продолжим тот же учебный пример. По типам ресурсов распределение выглядит так:
| Группа | До пика | День пика |
|---|---|---|
| HTML | 6 000 | 7 000 |
| JavaScript и CSS вместе | 2 500 | 11 000 |
| Изображения | 1 200 | 1 600 |
| Остальное | 300 | 400 |
Суммы равны 10 000 и 20 000. Скрипты и стили дали 8 500 из 10 000 дополнительных запросов, то есть 85% прироста. Это повод проверить публикацию ресурсов, изменение их адресов и обращения к разным версиям файлов. Это ещё не доказательство, что именно эти запросы завершались ошибками.
Допустим, независимый разбор журналов обнаружил, что 1 200 из 1 600 ответов 5xx относились к HTML. Это 75% ошибок. Теперь видны две разные группы: прирост преимущественно у ресурсов, отказы преимущественно у документов. Возможная общая причина требует проверки; приписывать все ошибки новым файлам нельзя.
Сравните последовательность событий. Если ошибки приложения начались раньше роста запросов к ресурсам, версия «бот перегрузил сервер» нуждается в дополнительных доказательствах. Если выросло время ожидания одной зависимости, расследуйте её вклад. График помогает сузить поиск, но не заменяет технический разбор.
10. Согласуйте журналы, даты и границы наблюдения
Примеры URL в Crawl Stats неполны; отсутствие адреса в списке не доказывает отсутствие обхода. Google также предупреждает о неполном учёте части запросов. Используйте примеры как указатели для поиска, а не как выгрузку всего трафика.
Сначала согласуйте временные метки. Зафиксируйте даты отчёта, часовой пояс журналов и доступные обозначения в экспорте. Не приписывайте Crawl Stats универсальную задержку обновления или часовой пояс без подтверждения. Если границы не удалось установить, сравнивайте более широкий интервал и сохраняйте эту неопределённость в выводах.
В документации NGINX о журналировании предусмотрены разные форматы, буферизация и условная запись. Поэтому перед подсчётом уточните, включён ли нужный журнал, не исключает ли он успешные ответы и сохранились ли файлы после ротации. Неполный журнал нельзя считать эталоном полного потока.
Для сверки нужны время, хост, метод, URL, код, клиентский IP, User-Agent и доступные идентификаторы запроса. Различайте журнал CDN и origin: кешированный ответ может быть выдан на границе, не дойдя до приложения. Сетевой отказ до HTTP, напротив, ищут в других источниках наблюдения. Сопоставляйте записи одной попытки, избегая двойного подсчёта на двух слоях.
Передайте администратору узкий запрос на выборку: один хост, согласованный интервал, нужные статусы и несколько адресов из примеров. Попросите также описать фильтры и отсутствующие поля. Это полезнее просьбы прислать «все логи сайта»: ограниченный набор легче проверить, а результаты можно воспроизвести. Сохраняйте исходные названия полей и единицы времени, чтобы секунды одного источника не сравнить с миллисекундами другого.
11. Подтвердите, что записи действительно относятся к Google
Строку User-Agent может отправить любой клиент. Для проверки Googlebot в собственных журналах используйте официальную процедуру проверки запросов Google: обратное DNS-разрешение IP, проверку допустимого доменного имени, затем прямое разрешение этого имени с совпадением исходного IP. Альтернатива для автоматизации — сопоставление с опубликованными диапазонами соответствующей категории краулеров.
Проверяйте именно границу домена, а не наличие слова google в произвольном имени. Выбор диапазона должен соответствовать типу клиента: общий поисковый краулер и специальные загрузчики относятся к разным категориям. При работе через прокси также уточните, откуда получен исходный IP и каким доверенным узлом он записан.
В рабочей выборке удобно различать подтверждённые обращения, неподтверждённые строки с похожим User-Agent и остальных клиентов. Тогда подозрительный всплеск не попадёт автоматически в вывод «Google создал нагрузку». Такая классификация нужна для анализа журналов; статистика Search Console не становится от этого полным отчётом о всех роботах, посещающих сайт.
12. Завершите разбор конкретной задачей и повторной проверкой
Полезный результат анализа помещается в короткую карточку: хост, интервал, группа запросов, наблюдаемая проблема, подтверждающие записи и ответственная команда. Отдельно укажите, что известно, а что остаётся предположением. Например: «Рост 5xx подтверждён в журнале CDN; происхождение ошибок на участке до приложения ещё проверяется».
- Укажите ожидаемый результат исправления для затронутых маршрутов.
- Сохраните исходные показатели и условия сравнения.
- После выпуска проверьте ответы и ошибки в журналах, затем сопоставьте доступные новые данные Crawl Stats.
- Повторно оцените структуру запросов, чтобы изменение состава не выдать за исправление скорости.
- Пользовательские функции и индексирование проверяйте отдельными подходящими способами.
Не устанавливайте универсальную «хорошую долю» для любого сайта по одному примеру. Для удалённых адресов, публичного каталога и файлов оформления ожидаемые результаты различаются. Важен устойчивый, объяснимый ответ на конкретную проблему и отсутствие её повторения в сопоставимых условиях.
При приёмке проверяйте содержание исправленных ответов. Замена кода ошибки на 200 при сохранении аварийной заглушки улучшит распределение статусов лишь формально. У учебного каталога должны открываться предусмотренные документы, а у отсутствующего товара — сохраняться корректное сообщение и статус. Отдельно запишите период наблюдения после изменения и объём проверенной активности. Один удачный запрос подтверждает текущее наблюдение, но не отсутствие повторных отказов.
Подключите SiteGuard для внешнего контроля HTTP-доступности сайта. Crawl Stats и серверные журналы анализируйте отдельно.