Аналіз лог-файлів для SEO: читаємо серверні логи та усуваємо втрати краулінгового бюджету

Швидкий тест

Чи підходить вам SEO і з чого почати?

Питання 1 з 425%

Чи шукають люди в Google те, що ви продаєте?

Так, думаю, що такНі, це щось нове або дуже нішевеНе знаю

Що записує лог сервера і чому він важливіший за інші дані

Щоразу, коли щось запитує файл із вашого сервера, сервер записує один рядок у свій лог доступу. Більшість серверів використовують формат, близький до "combined" формату Apache. Запит Googlebot виглядає так:

66.249.66.1 - - [13/Nov/2026:08:14:22 +0100] "GET /products/red-running-shoes HTTP/1.1" 200 18342 "-" "Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; Googlebot/2.1; +http://www.google.com/bot.html)"

Читайте його зліва направо: IP-адреса, мітка часу, HTTP-метод і URL, код стану (тут 200), кількість надісланих байтів, реферер і user agent. Тут є кожен запит, включно з тими, що ніколи не з'являються як перегляд сторінки в вашому аналітичному інструменті: зображення, CSS-файли, редиректи та помилки 404.

Ваші інші джерела даних бачать лише частину цього. Звіт «Статистика сканування» в Search Console є агрегованим і охоплює лише сканери Google. Аналітичні інструменти фіксують лише відвідувачів, чий браузер виконує ваш JavaScript. Краулер сайту, наприклад Screaming Frog, показує те, що він може досягти, переходячи за вашими посиланнями, а це не те саме, що Google вирішив запросити. Лише лог сервера фіксує те, що справді сталося.

Навіщо потрібен аналіз логів: краулінговий бюджет простими словами

Краулінговий бюджет являє собою набір URL, які Google може і хоче сканувати на вашому сайті. Google описує його через два фактори. Перший фактор: ліміт потужності сканування: скільки з'єднань сканери Google можуть тримати відкритими до вашого сервера, не перевантажуючи його. Цей ліміт зростає, коли сайт працює стабільно, і падає, коли відповіді сповільнюються або повертають помилки 5xx чи 429. Другий фактор: попит на сканування, який залежить від розміру сайту, частоти зміни контенту, його якості та популярності сторінок.

Google подає цю тему як просунутий посібник для великих сайтів. Його приблизні пороги: сайти з 1 мільйоном і більше унікальних сторінок, контент яких змінюється приблизно раз на тиждень, та сайти з 10000 і більше унікальних сторінок, контент яких змінюється щодня. До сфери уваги потрапляють і сайти, де багато URL у статусі «Discovered - currently not indexed». Менші сайти зазвичай обходяться актуальною картою сайту та регулярною перевіркою звіту «Індексування сторінок». Це не означає, що логи для них марні. Коли з скануванням щось не так, лог: найшвидший спосіб побачити, де саме.

Якщо ваш сайт потрапляє в цей діапазон, питання вже не в тому, чи читати логи, а в тому, як часто. Разовий аудит показує втрати сьогодні. Щомісячне вивантаження показує, чи змінили ваші виправлення те, на що Googlebot витрачає час. Для базових понять корисна стаття глосарію про краулінговий бюджет, а посібник про статус Discovered, currently not indexed пояснює статус, який зазвичай запускає такий перегляд.

Метод крок за кроком

Наведений нижче порядок роботи підходить для будь-якого сервера й будь-якого інструмента. Наступні розділи детально пояснюють кожен крок і дають команди, які можна запустити на сирому лог-файлі вже сьогодні.

Беріть логи з правильного рівня

Попросіть розробника або хостинг-провайдера надати сирі логи доступу веб-сервера (Apache, Nginx або IIS). Перед початком перевірте три речі: формат логів, часовий пояс і строк зберігання. Залежно від налаштувань старі логи можуть ротуватися через кілька днів або тижнів, тому запросіть вивантаження зараз, а не пізніше.

Рівень важливіший, ніж багато хто думає. Якщо CDN відповідає на запит зі свого кешу, origin-сервер цей запит ніколи не бачить. Googlebot може сканувати URL, якого немає в логах origin, тому вивантаження лише з origin занижує активність сканування кешованого контенту. Вивантажте також логи CDN і порівняйте два джерела для кількох URL, перш ніж довіряти якомусь підсумку.

Фільтруйте і рахуйте Googlebot кількома командами

У лозі формату combined код стану стоїть у 9-му полі, а шлях URL у 7-му. Ці два стовпці відповідають на більшість перших питань. Ця команда рахує запити Googlebot за кодами стану:

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

Ця команда виводить 20 шляхів, які Googlebot запитує найчастіше, з вилученим рядком запиту, щоб варіанти фільтрів групувалися разом:

grep "Googlebot" access.log | awk '{print $7}' | cut -d '?' -f1 | sort | uniq -c | sort -rn | head -20

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

Перевіряйте Googlebot так, як його описує Google

Власний метод Google, що дає змогу підтвердити, що відвідувач є Googlebot, використовує DNS. Виконайте зворотний DNS-пошук IP-адреси з логу, переконайтеся, що ім'я хоста закінчується на googlebot.com, google.com або googleusercontent.com, потім виконайте прямий пошук за цим іменем і перевірте, що він повертає початкову IP. У документації Google використано такий приклад: 66.249.66.1 зворотно розв'язується в crawl-66-249-66-1.googlebot.com:

host 66.249.66.1

Пряму перевірку виконує друга команда, і вона має повернути ту саму IP:

host crawl-66-249-66-1.googlebot.com

Якщо ви обробляєте мільйони рядків, DNS-запити стануть повільними. Google також публікує JSON-файли з діапазонами IP своїх сканерів, зокрема common-crawlers.json для Googlebot. Зіставлення з цими діапазонами швидше, а офіційний посібник з перевірки описує обидва методи в посібнику Google з перевірки Googlebot.

Групуйте, вимірюйте і читайте результати

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

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

Сім сигналів, захованих у логах

Коли рядки Googlebot перевірені й згруповані, сім сигналів пояснюють більшість проблем зі скануванням. Таблиця вказує шаблон, який варто шукати, і типове виправлення. Кожне виправлення є зміною сайту, тож підтвердіть його в наступному вивантаженні.

Сигнал	Що показують логи	Що робити
Втрати на скануванні	Звернення Googlebot до фільтрів, порядків сортування, внутрішнього пошуку та URL сесій	Консолідуйте через canonical, приберіть внутрішні посилання на ці URL і блокуйте безглузді варіанти в robots.txt там, де їх не можна консолідувати
Редиректи	Звернення до відповідей 301 або 302 і ланцюги з двох і більше переходів	Посилайтеся напряму на кінцевий URL. Посібник про 301 проти 302 допоможе обрати правильний тип редиректу
Помилки	Повторні звернення до 404 або 410 і сплески відповідей 5xx	Відновіть або перенаправте сторінки, які досі важливі, і виправте помилки сервера, бо відповіді 5xx зменшують обсяг сканування Google
Пропущені сканування	Важливі URL, яких за період жодного разу не відвідав Googlebot	Перевірте внутрішні посилання, записи в карті сайту та правила robots.txt, які можуть не пускати до них сканери
Дублікати	Той самий контент відкривається за різними URL: із закінчувальним слешем, великими літерами або параметрами	Оберіть один канонічний URL і посилайтеся на нього всюди
Час до першого сканування	Час між публікацією та першим зверненням Googlebot до нової сторінки	Посилайтеся на нові сторінки з тих, які вже часто скануються, і тримайте карту сайту в порядку
Час відповіді	Повільні відповіді на шаблони, які Googlebot відвідує найчастіше	Прискорте ці шаблони насамперед, бо Google каже, що повільні відповіді змушують його сканувати менше

Рядок про пропущені сканування часто пропускають, а він нерідко найдорожчий. Сторінка, яку ви ніколи не бачите в лозі, не може ранжуватися ні за чим, навіть коли контент чудовий. Якщо URL є у вашій карті сайту, але ніколи не з'являється в логах, сторінка, імовірно, доступна лише шляхом, яким сканери не ходять. Посібник про статус Crawled, currently not indexed охоплює іншу сторону цієї ситуації, коли Googlebot відвідує сторінку, але все одно її не індексує.

Три способи провести аналіз, порівняно

Аналіз логів можна виконувати скриптами, настільною програмою або платформою. Кожен варіант підходить для різного обсягу і різної команди. Вибір залежить менше від розміру сайту, ніж від того, як часто потрібна відповідь і хто її читатиме.

Командний рядок: grep, awk і Python

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

Приклад: команди з розділу про метод, запущені раз на місяць на тому самому вивантаженні, дають розподіл кодів стану та найчастіші шляхи Googlebot. Короткий Python-скрипт може зробити те саме і додати DNS-перевірку, яка повільніша, але точніша.

Настільний інструмент: Screaming Frog Log File Analyser

Принцип: ви імпортуєте сирі логи в настільний проєкт, а інструмент групує ботів, перевіряє їхню ідентичність і малює графіки. Коли використовувати: консультант або внутрішній аналітик, який працює з сайтом із десятками тисяч URL. Переваги: він читає логи Apache, IIS і Nginx у форматі W3C Extended, перевіряє пошукових ботів і позначає великі або повільні сторінки. Обмеження: безкоштовна версія обмежена, а обсяг даних, які можна завантажити, залежить від жорсткого диска.

Перед покупкою прочитайте сторінку Screaming Frog про Log File Analyser. Для повного огляду парного краулера дивіться наш посібник зі Screaming Frog SEO Spider. Аналізатор логів виконує завдання, яке краулер не може: показує, що боти справді запитували, а не те, що підказують ваші посилання.

Платформа: безперервний моніторинг логів

Принцип: платформа отримує ваші логи за розкладом, часто від CDN або сервера, і поєднує їх зі скануванням вашого сайту та даними індексації. Коли використовувати: великі інтернет-магазини або корпоративні команди, які щотижня відстежують сканування на кількох ринках. Переваги: масштабується на дуже великі логи, зберігає історію, і кілька команд можуть ділити дашборди. Обмеження: коштує дорожче, потребує часу на впровадження, а прив'язка до постачальника реальна, тож перш ніж зобов'язуватися, перевірте, як експортувати дані. До цієї категорії належать Oncrawl і Botify, і варто запитати кожного постачальника, як він перевіряє ботів.

Критерій	Командний рядок	Настільний інструмент	Платформа
Вартість	Безкоштовно	Безкоштовно до 1000 подій логу, £99 на рік за повну ліцензію	Передплата, ціна залежить від обсягу
Налаштування	Скрипти пишете й підтримуєте ви	Встановити, імпортувати, запустити	Конектори та онбординг
Обсяг	Обмежений вашою машиною	Обмежений жорстким диском і ліцензією	Створено для дуже великих логів
Перевірка ботів	Вручну, через DNS або перевірку діапазонів IP	Вбудована	Запитайте постачальника
Найкраще для	Разових перевірок і невеликих сайтів	Консультантів і середніх сайтів	Корпоративних команд і інтернет-магазинів з щотижневим моніторингом

Звіт «Статистика сканування» від Google: корисний, але недостатній

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

Його обмеження пояснюють, чому логи досі важливі. Звіт доступний лише для властивостей домену та префіксів URL кореневого рівня. Він охоплює лише сканери Google, тож GPTBot, ClaudeBot та інші боти в ньому відсутні. Він групує дані замість того, щоб перелічувати кожен URL, тому може показати, що запити сканування впали, але не скаже, які шаблони їх втратили. Використовуйте його, щоб помітити зміну, а логи, щоб з'ясувати, що саме відбулося.

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

Усунення втрат на скануванні, коли ви їх побачили

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

Фасетна навігація. Фільтри та порядки сортування створюють багато URL з майже однаковим контентом. Консолідуйте їх через canonical, де можливо, і приберіть внутрішні посилання на варіанти без пошукової цінності. Там, де варіант не можна консолідувати і він має залишатися поза скануванням, заблокуйте його в robots.txt. Рекомендація Google тут конкретна: не використовуйте для цього noindex, бо Google усе одно має запросити сторінку, перш ніж побачить тег. Ось приклад правила, яке варто перевірити:

User-agent: Googlebot
Disallow: /*?sort=
Disallow: /*?color=

Тримайте зміну robots.txt у міру. Google каже, що блокування URL не вивільняє краулінговий бюджет для інших ваших сторінок, якщо сайт уже не досяг ліміту потужності. Блокування призначене для URL без цінності, а не для перенаправлення бюджету на найкращі сторінки. Наша стаття глосарію про robots.txt пояснює, як читається файл.

Ланцюги редиректів. Якщо сторінку перенесли двічі, сканер щоразу проходить обидва редиректи. Оновіть внутрішні посилання так, щоб вони вели на кінцевий URL, а старі редиректи залиште для зовнішніх посилань. Вибір між постійним і тимчасовим редиректом важливий з тієї самої причини, і посібник про 301 проти 302 розглядає його детально.

Видалені сторінки. Повертайте 404 або 410 для сторінок, які видалено назавжди. Google каже, що м'які 404 продовжують скануватися і марнують краулінговий бюджет, тож повідомлення «сторінку не знайдено», віддане зі статусом 200, гірше за справжню 404.

Час відповіді та кешування. Google каже, що повільні або збійні відповіді змушують його сканувати менше. Підтримуйте відповіді 304 (Not Modified), щоб незмінені сторінки віддавалися з кешу. Потім подивіться на шаблони, які отримують найбільше звернень Googlebot, і прискорте їхні відповіді насамперед.

Помилки, які коштують найдорожче, і як їх уникнути

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

Довіра рядку user agent

Що це: підрахунок кожного запиту, який називає себе «Googlebot», як сканування Google. Як розпізнати: звернення Googlebot з IP-адрес, які не розв'язуються назад у імена хостів Google, або різкий стрибок з однієї адреси. Як виправити: виконайте перевірку з розділу про метод, перш ніж щось рахувати, і тримайте неперевірені звернення в окремій групі, щоб і далі бачити активність скраперів.

Читання лише відповідей 200

Що це: фокус на сторінках, які повертають 200, і ігнорування решти. Як розпізнати: у вашому звіті немає розділу для 3xx, 4xx чи 5xx, або розподіл кодів стану ніколи не обговорюють. Як виправити: завжди починайте з розподілу кодів стану. Зростання звернень до 404 може вказувати на зламане внутрішнє посилання, а зростання звернень до 5xx вказує на проблему сервера, яка сповільнює все сканування.

Блокування сторінки, яку хочете вивести з індексу

Що це: додавання правила robots.txt до сторінки, на якій також є тег noindex. Як розпізнати: сторінка залишається в індексі, а в логах немає звернень Googlebot, бо сканер не може її запросити. Як виправити: зніміть блокування, щоб Google міг прочитати тег noindex, дочекайтеся, поки сторінка випаде з індексу, і лише потім поверніть блокування, якщо воно ще потрібне. Посібник про Blocked by robots.txt пояснює статус Search Console, який з'являється в цьому випадку.

Порівняння вікон різної довжини

Що це: порівняння 3-денного вивантаження до виправлення з 30-денним вивантаженням після нього. Як розпізнати: підсумки сильно рухаються, а частка за шаблонами лишається незмінною. Як виправити: порівнюйте однакову кількість днів, за можливості в той самий період року, а коли обсяг змінюється, порівнюйте частки, а не сирі підсумки.

Вимірювання звернень замість цінності

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

Де AI-боти опиняються в тих самих логах

Ті самі логи показують, що роблять AI-краулери на вашому сайті, і метод той самий: групуйте, перевіряйте там, де постачальник дає таку можливість, і читайте коди стану. Наш посібник про логи AI-краулерів пояснює, яких ботів шукати і чим вони відрізняються від Googlebot. Ця стаття детально розглядає метод для Googlebot, а розділ про AI нижче показує, як поєднати обидва в одному звіті.

Тип бота	Приклади	Що перевіряти в логах	Детальніше
Пошуковий краулер	Googlebot	Звернення за шаблонами, розподіл кодів стану, час до першого сканування нових сторінок	Розділи вище в цій статті
Краулер навчання	GPTBot, ClaudeBot, CCBot	Чи запитують вони взагалі ваш контент і чи дотримуються вони вашого robots.txt	Robots.txt для AI-краулерів
Краулер вилучення	ChatGPT-User, PerplexityBot	Короткі сплески відвідувань, пов'язані із запитаннями користувачів, і сторінки, до яких вони доходять	Логи AI-краулерів

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

Якщо ви хочете бачити трафік Google і трафік AI поруч, поки впроваджуєте ці виправлення, дашборд GEO / SEO від Sorank показує обидва в одному вигляді. Використовуйте його, щоб перевірити, чи зміни, зроблені за логами, рухають трафік, а не лише змінюють кількість сканувань.