Аналіз лог-файлів (Log File Analysis)
Вивчення журналів доступу сервера: які URL запитували роботи, коли і з якою відповіддю.
Перевірив Олександр Яровенко · Оновлено: 2026-10-04
Аналіз лог-файлів — вивчення журналів доступу вебсервера, щоб побачити, які URL пошукові роботи справді запитували, коли і з якою відповіддю. На відміну від обходу сайту SEO-інструментом, журнал показує, що роботи реально робили на сайті. Він не показує, чи проіндексована сторінка і як вона ранжується: запит — це лише запит.
Що це і де проходить межа
Кожен запит до сервера записується в журнал: час, адреса, URL, код відповіді, розмір і user agent. Відфільтрований до перевірених роботів Google, цей файл — єдиний первинний запис обходу, яким ви володієте. Звіт Search Console «Статистика сканування» — та сама ідея з боку Google, але він обмежений вибраним доменом і розрахований на досвідчених користувачів. Жодне з них не каже, що сталося після завантаження сторінки.
Чим відрізняється від схожих термінів
| Поняття | Джерело | На що відповідає |
|---|---|---|
| Аналіз лог-файлів | ваш сервер | які URL запитували і що відповів сервер |
| Статистика сканування | Search Console | запити Google, відповіді та проблеми доступності |
| Аудит доступності для обходу | інструмент, що обходить сайт | що міг досягти робот, а не що зробив Google |
| Краулінговий бюджет | поняття з посібника Google | скільки Google може і хоче сканувати |
Навіщо це потрібно
Для великого або такого, що часто змінюється, сайту журнали показують, куди йде обхід: на цінні сторінки, дублі з параметрами, редиректи чи помилки. Google пише, що повільні відповіді та помилки сервера знижують ліміт сканування, а сторінки soft 404 і далі скануються та витрачають бюджет. Для невеликого сайту звіт «Статистика сканування» названо непотрібним приблизно до тисячі сторінок, тож журнали там — діагностика останньої черги.
Що читати в рядку журналу
Типовий рядок виглядає так:
66.249.66.1 - - [03/Oct/2026:09:14:02 +0000] "GET /catalog/pans?page=2 HTTP/1.1" 200 18342 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"У ньому записано адресу того, хто запитав, час, URL, статус (200), розмір і user agent. User agent лише заявляє особу. Документація Google радить перевіряти зворотним DNS-запитом за IP, який має розвʼязуватися в googlebot.com, google.com або googleusercontent.com, потім прямим запитом, що повертає той самий IP, або звіряти IP з опублікованими списками Google.
Як застосовувати
- Отримайте сирі журнали доступу за період у кілька тижнів, включно з CDN чи балансувальником, якщо вони стоять перед сервером.
- Залиште лише запити, чий IP проходить перевірку зворотним і прямим DNS або входить в опубліковані діапазони Google.
- Згрупуйте URL за шаблонами: категорія, товар, стаття, варіанти з параметрами, файли.
- Порахуйте запити й коди відповіді за групами; шукайте помилки, довгі ланцюжки редиректів і soft 404.
- Порівняйте обійдені URL з мапою сайту: важливі URL без запитів і запитувані URL, яких ви не вказували.
- Усуньте причини (посилання, редиректи, час відповіді, правила robots.txt) і повторіть на наступному періоді.
Практичний приклад
Журнали магазину за чотири тижні після перевірки групуються так:
| Шаблон | Спостереження | Дія |
|---|---|---|
| /catalog/…?sort=, ?page= | більшість запитів іде на варіанти сортування | перевірити внутрішні посилання, canonical і правила robots |
| /product/… | нові товари вперше запитуються через тижні | перевірити lastmod у мапі сайту та внутрішні посилання |
| /old-section/… | запити закінчуються ланцюжком редиректів | вести посилання одразу на кінцевий URL |
Кожен рядок — гіпотеза для перевірки, а не вирок: журнал показує запити, а не їхній вплив на індексацію.
Часті помилки
- Вірити user agent: перевіряйте IP; один рядок не доказ.
- Вважати запит індексацією: просканована сторінка все одно може не потрапити в індекс; перевіряйте сторінку в Search Console.
- Пропустити шар CDN: журнали лише вихідного сервера можуть приховати запити, обслужені кешем.
- Аналізувати один день: обхід коливається; беріть кілька тижнів.
- Застосовувати метод до крихітного сайту: Google пише, що звіт не потрібен до тисячі сторінок; витратьте час на контент.
- Рахувати переходи редиректу за один: звіт Google рахує кожен запит у ланцюжку окремо, як і журнали.
Як перевірити результат
Після виправлення порівняйте ті самі групи шаблонів за наступний період: менше запитів до зайвих варіантів, менше відповідей із помилками та редиректами, раніші перші запити до нових сторінок. Підтвердьте у звіті «Статистика сканування», що помилки сервера й проблеми доступності скорочуються. Не чекайте зміни позицій лише від змін обходу.
Ще питання
Чи можна обійтися Search Console?
Частково. Звіт показує запити Google, відповіді та доступність, але лише для вибраного домену й у зведенні. Журнали показують кожен URL і кожного робота.
Більше обходу — вищі позиції?
Документація цього не стверджує. Сканування — умова індексації, а не фактор ранжування.
Чи потрібна спеціальна програма?
Для кількох тижнів журналів вистачить скрипта або таблиці. Спеціалізовані інструменти допомагають із дуже великими файлами.
Наступний практичний крок
Пройдіть урок Аудит сканування, потім вивантажте журнали за тиждень і згрупуйте їх за шаблонами.
Повʼязані поняття
- Краулінговий бюджет — скільки Google сканує на сайті.
- Глибина обходу — кількість кліків до сторінки.
- Помилки сканування — невдалі запити.
- Ланцюжок редиректів — кілька переходів до кінцевого URL.
- Google Search Console — статистика сканування та звіти про індексацію.