Отчёт Crawl Stats показывает, как Googlebot запрашивал сайт, но не подтверждает индексацию каждой важной страницы. Читайте его в строгом порядке: проверьте доступность хоста, затем скорость и ошибки сервера, состав запросов и только после этого обсуждайте спрос на сканирование. Такой порядок не позволяет превратить обычное колебание графика в выдуманную SEO-проблему.
В руководстве разобрана статистика сканирования Google Search Console и предложена собственная лестница доказательств для расследования инцидентов. Определения метрик и ограничения сверены с официальной справкой Google о Crawl Stats.
На какие вопросы отвечает отчёт
Отчёт отвечает на эксплуатационные вопросы об активности Googlebot за доступный период. Он показывает общее число запросов, суммарный объём скачанных данных и среднее время ответа. Таблицы делят запросы по коду ответа, типу файла, цели сканирования и типу робота. Состояние хоста сообщает о проблемах получения robots.txt, разрешения DNS и подключения к серверу.
Отчёт полезен после миграции, серверного сбоя или резкого изменения активности робота. Это не отчёт о позициях. Ровный график не доказывает, что конкретный адрес был просканирован, отрисован, проиндексирован или выбран каноническим. Для этого нужны доказательства на уровне адреса.
Где найти Crawl Stats и когда его смотреть
Откройте Search Console, выберите нужный ресурс, перейдите в «Настройки» и откройте «Статистика сканирования». Google называет его расширенным отчётом и отмечает, что небольшим сайтам обычно не нужно следить за ним постоянно. Доменный ресурс может показывать дочерние хосты, а ресурс с префиксом ограничен своей областью. Перед сравнением всегда фиксируйте ресурс и хост.
График отвечает на вопрос «как часто Google сканирует мой сайт» только историей наблюдений, а не расписанием. Частота зависит от допустимой нагрузки и спроса на обход. Универсальной нормы запросов нет: сравнивайте сайт с его собственным обычным режимом.
Четыре уровня доказательств
Наша модель разделяет четыре причины, которые часто смешивают. Переходите к следующему уровню, только если предыдущий выглядит здоровым. Это собственная методика статьи, собранная из доступных в отчёте измерений.
| Уровень | Вопрос | Доказательство | Следующее действие |
|---|---|---|---|
| 1. Доступность | Мог ли Google достучаться до хоста? | Состояние хоста, DNS, robots.txt, подключение | Сначала устранить инфраструктурный сбой |
| 2. Производительность | Стал ли сервер медленнее или нестабильнее? | Время ответа и доля ошибок сервера | Проверить журналы, лимиты и тайм-ауты |
| 3. Состав запросов | Какие именно запросы изменились? | Ответы, файлы, цель и тип робота | Найти затронутый шаблон или ресурс |
| 4. Приоритет | Изменился ли спрос на полезные адреса? | Обнаружение, обновление, карты сайта, ссылки | Усилить сигналы и проверить выбранные адреса |
Одинаковое падение запросов может означать противоположные вещи. После закрытия дублирующих фильтров оно бывает полезным. Падение вместе с ошибками DNS и ростом времени ответа означает инцидент. Один график эти ситуации не различает.
Сначала постройте базовую линию
Выберите несколько обычных недель с сопоставимыми условиями работы и релизами. Зафиксируйте медиану дневных запросов, среднее время ответа, основные коды и соотношение обнаружения с обновлением. Отметьте на шкале релизы, миграции, простои и изменения robots.txt.
Рассмотрим иллюстративный расчёт, а не отраслевую норму. Если обычный уровень равен 900 запросам в день, а сопоставимый период показывает 540, изменение составляет (540 − 900) ÷ 900 = −40%. Число описывает масштаб, но не причину. Причину проверяют по лестнице доказательств.
Не сравнивайте будний пик с выходным минимумом, а новый домен — со зрелым. Сохранённые снимки и строки таблиц полезны для истории инцидента, однако выборка адресов в интерфейсе не является полным журналом сервера.
Как расследовать падение активности
1. Начните с состояния хоста
Откройте каждый хост отчёта. Предупреждение около даты падения переносит расследование к DNS, доступности robots.txt и соединению с сервером. Руководство Google по ошибкам сканирования объясняет влияние сбоев доступности. Подтвердите событие журналами хостинга и CDN.
2. Сопоставьте время ответа и ошибки
Если время ответа растёт, а запросы падают, сервер мог ограничить доступную мощность обхода. Проверьте ошибки 5xx, код 429 и тайм-ауты. Сканер сайта воспроизводит внутреннюю навигацию и ответы, но не является доказательством действий Googlebot. Найдите им закономерность и подтвердите журналами.
3. Найдите изменившуюся группу запросов
При стабильной производительности сравните HTML, изображения, JavaScript и другие типы файлов. Затем сопоставьте обновление с обнаружением и смартфонного робота с остальными. Выборки — примеры, а не полный перечень адресов. Всплеск редиректов проверьте инструментом проверки редиректов и разберите по справочнику HTTP-кодов.
4. Проверяйте важные адреса отдельно
Если общие показатели здоровы, а нужные страницы не появляются в поиске, проверьте отдельные адреса, карту сайта, внутренние ссылки, canonical и директивы robots. Аудитор адресов GSC помогает организовать проверку. Общая статистика не заменяет инспекцию адреса и журналы.
Как читать срезы отчёта
| Срез | Полезный сигнал | Ошибочный вывод |
|---|---|---|
| По ответу | Изменение успешных ответов, редиректов и ошибок | Каждый 404 тратит бюджет |
| По типу файла | Доминирует шаблон или группа ресурсов | Все ресурсы нужно закрыть |
| По цели | Обнаружение и обновление движутся по-разному | Ошибочно считать обнаружение подтверждением индексации |
| По типу робота | Изменился состав смартфонного или другого робота | Доля робота является фактором ранжирования |
Проценты требуют контекста. Большая доля 404 может относиться к удалённым адресам, которые Google перепроверяет. Редиректы ожидаемы во время миграции. Важно понять, соответствует ли изменение запланированному релизу и остаются ли доступными полезные группы страниц.
Чего отчёт не доказывает
Данные не содержат полный журнал запросов, фиксированный бюджет или историю каждого адреса. Они не доказывают успешную отрисовку, индексацию, выбор канонической версии, позиции или переходы. В справочнике API Search Console перечислены Search Analytics, Sitemaps, Sites и URL Inspection, но отдельной точки доступа Crawl Stats нет.
Для крупных и быстро меняющихся сайтов используйте рекомендации Google по бюджету сканирования. Для небольшого сайта обычно полезнее устранить проблемы обнаружения и индексируемости, чем пытаться увеличить число запросов.
Контрольный список инцидента
- Запишите ресурс, хост, период и точный симптом.
- Сравните с репрезентативной базовой линией.
- Проверьте доступность хоста до анализа объёма.
- Сопоставьте время ответа и долю серверных ошибок.
- Найдите изменившийся срез ответов, файлов, целей или роботов.
- Сверьте дату с релизами и инфраструктурными событиями.
- Отдельно проверьте несколько важных адресов.
- Запишите вывод как доказательство с границами уверенности.
Цель анализа — не заставить линию расти, а понять, может ли Googlebot эффективно получать полезный контент и требует ли изменение действий.