Аналіз логів сервера для SEO: що реально сканують боти

Аналіз логів сервера для SEO — це вивчення access-логів вашого вебсервера, щоб побачити, які URL насправді запитують Googlebot та інші краулери, як часто вони повертаються і які коди відповіді отримують. Інші SEO-дані або вибіркові, або надходять із затримкою, або змодельовані. Логи — це запис кожного візиту бота з першоджерела, тож вони показують, де сканування витрачається марно і які сторінки боти пропускають.

У цьому посібнику розповідаємо, як отримати логи й очистити дані, як перевірити, що запит «Googlebot» справді надійшов від Google, на які закономірності варто дивитися і як перетворити їх на конкретні виправлення.

Що таке аналіз логів сервера для SEO?

Це процес, у якому ви відфільтровуєте з access-логу сервера лише запити пошукових систем та AI-краулерів, а потім вимірюєте, що саме вони сканують. Отримане порівнюєте з тим, що ви хочете, щоб сканували, тобто з вашими індексованими важливими сторінками. Розбіжності між цими двома списками й стають переліком виправлень.

Кожен рядок access-логу — це один HTTP-запит. Типовий рядок у поширеному форматі «combined» виглядає так:

66.249.66.1 - - [28/Oct/2026:09:14:02 +0000] "GET /shoes/red-runner HTTP/1.1" 200 48213 "-" "Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/141.0.0.0 Mobile Safari/537.36 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"

З одного рядка ви дізнаєтеся IP клієнта, час запиту, метод і URL, код відповіді, розмір відповіді, реферер і user agent. Помножте це на кілька тижнів трафіку, і ви зможете відповісти на запитання, на які не відповість жоден краулер: чи забрав Google нову сторінку категорії? Скільки запитів пішло на URL фільтрів? Який бот натрапив на помилки 500 о третій ночі?

Що показують логи, чого не видно в Search Console і краулерах?

Логи показують, що боти зробили насправді, URL за URL. Search Console дає агреговані дані Google, а краулер сайту показує, що могло б бути проскановано. Логи ж містять точні запити, зокрема всіх ботів, крім Google, із часом і відповідями, які можна зіставити з вашим власним списком URL.

У документації звіту «Статистика сканування» Google перелічує доступні розбивки: загальна кількість запитів, обсяг завантажених даних, середній час відповіді, стан хоста, відповіді за кодами статусу, тип файлу, мета сканування (виявлення чи оновлення) і тип Googlebot. На тій самій сторінці Google навіть радить переглянути «логи вашого сайту», коли розбираєтеся зі сплесками частоти сканування. Тож ці джерела доповнюють одне одного: «Статистика сканування» дає швидкий огляд, а логи — детальну картину на рівні окремих URL.

Кому насправді потрібен аналіз лог-файлів?

Аналіз логів найбільше окупається на великих або сайтах, що швидко змінюються, на сайтах із фасетною навігацією та одразу після міграції. Сайту-візитці на 40 сторінок він рідко потрібен: там зазвичай вистачає Search Console і сканування сайту.

Посібник Google щодо краулінгового бюджету розрахований на сайти з понад 1 мільйоном унікальних сторінок, що змінюються приблизно щотижня, або з понад 10 000 сторінок, що змінюються щодня. Для решти сайтів, за словами Google, зазвичай достатньо підтримувати актуальну карту сайту й регулярно переглядати звіт «Індексування сторінок». Утім, логи допомагають і меншим сайтам у кількох випадках:

• Після міграції чи редизайну, щоб переконатися, що Googlebot проходить нові редиректи й доходить до нових URL.
• Коли сторінки висять у статусі «Виявлено, але наразі не проіндексовано» і ви хочете знати, чи Google узагалі коли-небудь їх запитував.
• Коли у «Статистиці сканування» з'являються серверні помилки чи уповільнення і вам потрібні точні URL та час.
• Коли ви хочете зрозуміти, як AI-краулери використовують ваш сайт, адже Search Console їх узагалі не показує.

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

Як отримати й підготувати логи сервера?

Попросіть хостинг-провайдера або розробника надати сирі access-логи щонайменше за 30 днів з усіх серверів і CDN, які віддають HTML. Потім відфільтруйте запити ботів, нормалізуйте URL і перевірте ботів. Чистий набір даних важить більше, ніж модний інструмент.

Де зберігаються логи

• Apache / Nginx: зазвичай файли access.log, які часто ротуються й архівуються в gzip щодня.
• Керований хостинг: часто це пункт «raw access logs» для завантаження в панелі керування. Деякі хостинги зберігають логи лише кілька днів, тож спершу увімкніть архівування.
• CDN або reverse proxy: якщо закешовані сторінки віддає CDN, ваш основний сервер цих запитів не бачить. Вам потрібні також логи CDN, інакше частина картини випаде.
• Конфігурації з балансуванням навантаження: об'єднайте логи з усіх вузлів.

Перевірте, чи записує лог реальний IP клієнта, а не IP проксі. Без реального IP перевірити ботів неможливо.

Очищення даних

1. Залиште лише потрібні поля: IP, час, метод, URL, статус, обсяг у байтах, user agent і, якщо є, час відповіді.
2. Відфільтруйте за токенами user agent (Googlebot, bingbot, GPTBot, OAI-SearchBot, ChatGPT-User тощо).
3. Перевірте IP-адреси (див. наступний розділ) і відкиньте підробки.
4. Нормалізуйте URL: переведіть хост у нижній регістр, визначтеся, як обробляти слеш у кінці, і збережіть query-рядки, бо саме в параметрах часто ховаються марні сканування.
5. Зіставте результат зі скануванням вашого сайту та XML-картою сайту, щоб кожен URL мав мітки на кшталт «індексується», «канонікалізовано», «є в карті сайту» та «має внутрішні посилання».

Для швидкого першого погляду, ще до налаштування будь-якого інструмента, на лозі у форматі combined спрацює однорядкова shell-команда:

grep "Googlebot" access.log | awk '{print $9}' | sort | uniq -c | sort -rn

Вона рахує запити Googlebot за кодами статусу. Сприймайте результат як грубу першу оцінку, бо дані ще не перевірені.

Як перевірити, що Googlebot — це справді Google?

Виконайте зворотний DNS-запит (reverse DNS) для IP, переконайтеся, що ім'я хоста закінчується на googlebot.com, google.com або googleusercontent.com, а потім зробіть прямий DNS-запит і підтвердьте, що він повертає той самий IP. Для великих обсягів зіставляйте IP з опублікованими Google файлами діапазонів IP-адрес.

Цей крок важливий, бо, як попереджає документація Google про Googlebot, заголовок user agent Googlebot «часто підробляють інші краулери». Скрейпери видають себе за Googlebot, щоб обійти блокування. Якщо пропустити перевірку, можна взятися «виправляти» закономірності сканування, яких Google ніколи не створював.

Посібник Google з перевірки описує обидва методи. Ручний — це чотирикрокова перевірка: спершу зворотний, потім прямий DNS-запит. Автоматичний — зіставлення IP у форматі CIDR зі списками JSON: common-crawlers.json для краулерів на кшталт Googlebot, special-crawlers.json для краулерів на кшталт AdsBot та окремі файли для фетчерів, які запускають користувачі. Більшість інструментів аналізу логів уміють робити цю перевірку самостійно. Увімкніть її і не вимикайте.

Очікуйте, що переважатиме мобільний краулер. Google пояснює, що оскільки індексує переважно мобільний контент, «більшість запитів сканування Googlebot надходитиме від мобільного краулера». Якщо більшість ваших перевірених звернень припадає на Googlebot Desktop, уважніше погляньте на мобільну версію сайту (див. наш чекліст для mobile-first індексування).

Які закономірності шукати в логах?

Шукайте чотири речі. По-перше, важливі сторінки, які боти сканують рідко або не сканують узагалі. По-друге, сканування, витрачене на URL, яких не мало б існувати: параметри, дублікати й редиректи. По-третє, помилкові та повільні відповіді. По-четверте, зміни обсягу сканування з часом. Кожна з них вказує на конкретний тип виправлення.

Чому помилки 5xx у логах такі важливі?

Серверні помилки не просто зривають один запит — вони ще й уповільнюють подальше сканування. У посібнику Google щодо краулінгового бюджету сказано, що коли сайт сповільнюється або «відповідає серверними помилками (коди статусу HTTP 5xx) чи сигналами обмеження частоти (наприклад, HTTP 429), ліміт знижується і Google сканує менше». Логи показують, коли саме це стається і на яких URL — часто під час пікового трафіку, резервного копіювання чи деплоїв. Згрупуйте відповіді 5xx за годинами та шаблонами URL. Поширена причина — одна повільна сторінка пошуку або товарний фід, що відвалюється за тайм-аутом. Виправлення одного такого ендпоінта може повернути обсяг сканування для всього сайту. Також перевірте різницю між даними «Статистики сканування» і ваших логів. На довідковій сторінці «Статистики сканування» Google пояснює: якщо у звіті запитів значно більше, ніж у ваших логах, це може означати, що Google не міг сканувати сайт, бо файл robots.txt надто довго був недоступний. Такі запити Google рахує як потенційні сканування, які насправді так і не відбулися.

Частота сканування й важливість сторінок

Відсортуйте URL за цінністю для бізнесу (сторінки, що приносять дохід, головні категорії, ключові статті), а потім додайте до кожного кількість перевірених звернень Googlebot. Якщо важливі сторінки скануються рідше, ніж URL фільтрів, це найпевніша ознака проблеми зі структурою сайту або внутрішньою перелінковкою. Щоб зрозуміти, які 404 справді мають значення, читайте статтю помилки 404 і SEO.

Логи показують, що робили боти. Щоб зрозуміти чому, потрібне сканування того самого сайту: які посилання ведуть на редиректи, які сторінки стали сиротами, що дозволяє robots.txt. Безкоштовний SEO-аудит від SEORecheck сканує ваші сторінки в реальному браузері й показує редиректи, биті посилання, проблеми з картою сайту та canonical, а також доступ AI-краулерів у robots.txt — із прикладами URL. Ці знахідки можна напряму зіставити з даними ваших логів.

Як аналізувати AI-краулерів у логах сервера?

Фільтруйте за задокументованим user agent кожного AI-постачальника, перевіряйте IP за діапазонами, які постачальник публікує, і розділяйте ботів за призначенням (пошук, запити користувачів або навчання). Потім переконайтеся, що потрібні вам боти отримують відповідь 200 на ваших важливих сторінках.

Документація OpenAI про краулери добре показує, чому ботів варто розділяти за призначенням. OAI-SearchBot використовується, щоб показувати сайти в пошукових функціях ChatGPT. GPTBot сканує контент для навчання генеративних AI-моделей. ChatGPT-User виконує дії, які запускають користувачі в ChatGPT, і OpenAI зазначає, що оскільки ці дії ініціюють користувачі, «правила robots.txt можуть не застосовуватися». Для кожного бота OpenAI публікує окремий список IP (searchbot.json, gptbot.json, chatgpt-user.json), тож перевіряти їх можна так само, як Googlebot.

У Google усе влаштовано так само. Його огляд краулерів відокремлює звичайні краулери, які «завжди дотримуються правил robots.txt під час автоматичного сканування», від краулерів особливого призначення та фетчерів, які запускають користувачі. Якщо логи показують, що пошуковий AI-бот отримує 403 через правило файрвола, хоча robots.txt його дозволяє, блокування стоїть на вашому сервері, а не в robots.txt. Як налаштувати правила для кожного бота, пояснюємо в нашому посібнику з robots.txt.

Логи показують, чи завантажують AI-краулери ваші сторінки. Але вони не показують, чи ці сторінки цитують. Жоден постачальник не документує зв'язку між обсягом сканування та цитуваннями.

Як часто проводити аналіз логів?

Проводьте повний огляд раз на квартал і цільову перевірку після кожної міграції, великого деплою чи раптової зміни у «Статистиці сканування». Для великих сайтів налаштуйте дашборд зі сповіщеннями про сплески 5xx і падіння кількості перевірених звернень Googlebot до ключових шаблонів.

Практичний розклад:

• Щотижня (великі сайти): перевірені звернення Googlebot за день, частка відповідей 5xx і 429, найчастіше запитувані шаблони параметрів.
• Після релізу: порівняйте 7 днів до і після. Шукайте нові 404, нові звернення до редиректів і нові шаблони URL — разом із вашими SEO-регресійними тестами.
• Щокварталу: частота сканування проти важливості сторінок, URL-сироти, доступ AI-краулерів за призначенням.

Додавайте кожне виправлення до плану з відповідальним і терміном. Потім через 30–60 днів знову перевірте логи, щоб переконатися, що картина змінилася: наприклад, менше звернень до параметричних URL і більше — до сторінок категорій, на які ви поставили посилання.

Головне

• Логи сервера — єдиний повний запис того, що Googlebot та AI-краулери насправді запитують на вашому сайті.
• Перевіряйте ботів через зворотний/прямий DNS-запит або опубліковані діапазони IP ще до будь-якого аналізу, бо user agent Googlebot часто підробляють.
• Збирайте логи з усіх рівнів, що віддають сторінки, зокрема з CDN, і зберігайте їх щонайменше 30 днів.
• Зосередьтеся на чотирьох закономірностях: важливі сторінки, які рідко скануються, марні сканування параметрів і редиректів, помилки 5xx/429 та зміни обсягу.
• Поєднуйте логи зі скануванням сайту. Логи показують, що робили боти, а сканування — чому.
• Розділяйте AI-краулерів за призначенням (пошук, запити користувачів, навчання). Дані сканування нічого не кажуть про цитування.

Щоб побачити, як аудит перетворює результати сканування на пріоритизовані виправлення, перегляньте приклад звіту.