Що можна дізнатися про Googlebot із server logs?

Лог-файли вебсервера (або server logs) — це власний запис сервера про кожен отриманий запит, який фіксується безпосередньо в момент звернення. Вони є єдиним джерелом істини щодо реальної поведінки пошукових роботів, оскільки не симулюють її, а реєструють фактичні дії.

Кожен рядок логу (наприклад, у стандартному форматі Combined Log Format) зазвичай зберігає такі дані: IP-адресу клієнта ($remote_addr), точний час і дату запиту ($time_local), сам запит (HTTP-метод, URL-шлях і протокол — $request), HTTP-код відповіді сервера ($status), обсяг переданих даних у байтах ($body_bytes_sent), реферер ($http_referer), а також юзер-агент ($http_user_agent) та операційну систему.

1. Які поля в логах найважливіші саме для аналізу Googlebot?

Для SEO-діагностики пріоритетними є такі поля:

Client IP ($remote_addr): потрібне для верифікації бота через зворотний DNS-запит або зіставлення з офіційними CIDR-діапазонами Google, щоб відокремити справжнього Googlebot від шахраїв, які маскують свій User-Agent.

Request timestamp ($time_local): дозволяє оцінити частоту та рецидивність сканування.

HTTP status code ($status): показує помилки (4xx, 5xx), редиректи (3xx), успішне сканування (200) або відповідь без змін (304), яка зберігає бюджет сканування.

Request line ($request): дає змогу згрупувати запити за URL-шаблонами (наприклад, картка товару, фільтр, пагінація).

Response size ($body_bytes_sent): допомагає виявити роздутий код сторінок (payload bloat), який сповільнює сканування.

Response time (час відповіді сервера): якщо це поле активоване в конфігурації логів, воно критично важливе для відстеження навантаження на сервер та його впливу на швидкість краулінгу.

2. Як визначити, які URL Googlebot сканує найчастіше?

Для цього необхідно виконати три кроки:

Ізолювати справжніх роботів: відфільтрувати лог-файли так, щоб залишилися тільки записи із верифікованими IP-адресами Googlebot.

Групувати дані за URL-шшляхом: об'єднати запити за адресами (очистивши їх від динамічних параметрів, якщо потрібно оцінити шаблони сторінок) за допомогою зведених таблиць Excel, спеціалізованих програм (Screaming Frog Log File Analyser, Botify, OnCrawl) або бібліотеки Pandas у Python.

Сортувати за спаданням: вибудувати список URL-адрес за кількістю звернень робота, щоб отримати топ найпопулярніших сторінок.

3. Як знайти важливі сторінки, які Googlebot майже не відвідує?

Ця інформація виявляється через співставлення (cross-referencing) даних:

Потрібно взяти список усіх важливих та індексованих сторінок сайту зі статусом 200 OK (отриманий за допомогою звичайного парсингу сайту через Screaming Frog чи Botify або з Google Analytics).

Зіставити цей список із реальними запитами Googlebot у логах за аналізований період.

Виділити корисні URL-адреси, які взагалі відсутні в логах сканування або мають аномально низьку частоту обходу. Це дозволить знайти структурні проблеми або сторінки-сироти (orphan pages), на які не веде жодне внутрішнє посилання, через що краулер їх ігнорує.

4. Як за логами побачити помилки 404, 410, 5xx та інші проблемні відповіді сервера?

Необхідно застосувати фільтр до поля $status, виключивши успішні коди відповідей 200 та 304. Згрупувавши отримані помилки за URL та часом, можна визначити:

Помилки 404 (Not Found): свідчать про зламані внутрішні посилання або старі карти sitemap. Якщо сторінка видалена назавжди, краще повертати 410 (Gone) — це сильніший і швидший сигнал для Google виключити її з індексу.

Помилки 500/503 (Server Error): вказують на падіння чи перевантаження сервера. Якщо Googlebot постійно бачить помилки 5xx, він пропорційно знижує швидкість і частоту сканування всього сайту, щоб не перевантажувати систему.

«Мовчазні» помилки (silent errors): коли сторінка повертає 200 OK звичайному користувачу, але віддає 404 або 500 для Googlebot через помилки кешування, блокування юзер-агента системами безпеки або некоректний рендеринг JavaScript.

5. Що можна дізнатися з великої кількості 3xx redirects у запитах Googlebot?

Аналіз 3xx редиректів у логах виявляє серйозні інфраструктурні проблеми:

Марнування краулінгового бюджету: кожен крок у ланцюжку редиректів (наприклад, сторінка 1 -> сторінка 2 -> сторінка 3) розцінюється Googlebot як окремий додатковий запит. Це суттєво уповільнює сканування та розсіює бюджет.

Застаріла перелінковка: велика кількість редиректів свідчить про те, що внутрішні посилання на сайті ведуть на старі адреси, які змушують сервер робити зайву роботу, замість того щоб посилатися безпосередньо на кінцеві адреси 200 OK.

Невірна сила сигналів: ви можете перевірити, чи правильно налаштовані редиректи — 301/308 сприймаються Google як сильний сигнал перенесення ваги, тоді як 302/307 — як слабкий (тимчасовий) сигнал.

6. Як response time у логах допомагає оцінити, чи сервер нормально відповідає Googlebot?

Час відповіді сервера (включаючи TTFB та затримку) безпосередньо визначає ліміт ємності сканування (crawl capacity limit).

Якщо сервер відповідає швидко й стабільно, Google автоматично підвищує цей ліміт, дозволяючи роботу здійснювати більше паралельних з'єднань і сканувати більше корисного контенту.

Якщо сервер починає відповідати повільно (response time зростає) або повертає помилки 5xx та код обмеження частоти HTTP 429, ліміт ємності падає, і Googlebot починає сканувати значно менше, щоб не порушити працездатність сайту.

7. Як знайти технічні, параметричні або дубльовані URL, на які Googlebot витрачає зайві ресурси Crawling?

Необхідно проаналізувати структуру URL у полі $request за такими ознаками:

Шукати наявність символу ? в URL-адресах, який вказує на параметри сортування, сесійні ідентифікатори та фільтри фасетної навігації (faceted navigation).

Згрупувавши verified hits за шаблонами, ви зможете побачити, яка частка запитів припадає на корисний контент (статті, товари), а яка — на технічне сміття. На великих сайтах дубльовані параметричні сторінки фільтрів та пагінація можуть забирати від 30% до 50% усього краулінгового бюджету, не приносячи жодної користі для індексу.

8. Як server log analysis допомагає зрозуміти проблеми з crawl budget на великих сайтах?

Він дає змогу вийти за межі здогадок та розрахувати чіткі метрики:

Середній денний темп сканування (Daily Crawl Rate): ділення загальної кількості верифікованих запитів Googlebot на кількість днів у вибірці логів.

Вікно сканування (crawl window): визначає кількість днів, необхідних роботу для повного обходу сайту. Якщо воно завелике (наприклад, 15 днів), це вказує на високу затримку реакції пошуковика на ваші зміни.

Локалізація витоків: лог наочно демонструє, куди саме "витікає" бюджет (overcrawling сміттєвих розділів, нескінченна пагінація, soft 404 помилки або циклічні редиректи).

9. Чим дані server logs доповнюють Google Search Console і чому для глибокого технічного SEO варто використовувати обидва джерела?

Хоча Google Search Console є незамінною, вона відповідає на обмежене коло питань і має суттєві ліміти порівняно з сирими логами:

Спектр даних: GSC показує фінальний стан індексації або усереднені графіки, але її звіти базуються на канонічних адресах та містять лише репрезентативні приклади. Лог сервера фіксує кожен реальний запит до кожної унікальної URL-адреси.

Позасерверні помилки: GSC реєструє спроби обходу, які навіть не досягли сервера (наприклад, збої DNS-сервера або таймаути з'єднання), які ви фізично не зможете побачити в логах.

Джерело істини: GSC використовує вибірки та агрегацію даних, тоді як лог — це повний, нередагований та вільний від затримок запис усього, що відбувалося на вашій стороні.

Використання обох інструментів є золотим стандартом: GSC дає розуміння того, що Google проіндексував, а лог-файли показують, що Googlebot насправді робив на вашому сайті.