Звіт Crawl Stats показує, як Googlebot запитував сайт, але не підтверджує індексацію кожної важливої сторінки. Читайте його послідовно: перевірте доступність хоста, швидкість і помилки сервера, склад запитів і лише після цього обговорюйте попит на сканування. Такий порядок не дозволяє перетворити звичайне коливання графіка на вигадану проблему.
У посібнику розібрано статистику сканування 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 ефективно отримувати корисний вміст і чи потребує зміна дій.