Робота з доказами
Аналіз логів для SEO: як перевірити Googlebot і знайти прогалини в скануванні сайту
Спочатку визначте реєстр. Потім рахуйте перевірені запити. Стан індексації досліджуйте окремо.
Тисячі рядків зі словом Googlebot ще не відповідають на питання, чи бот дістався важливих сторінок. User-agent можна підробити, origin-лог може не охоплювати відповіді CDN, а у звіті лише за відвіданими адресами немає місця для пропущених. Нижче — методика, що починається з фіксованого реєстру сторінок і перевірених запитів. Ви оберете рівень збору, відтворите невеликий звіт і підготуєте висновок для дослідження обходу або індексації. Статуси відповідей тут не використовуються як заміна даним про індекс Google.
Скрипт · умовний CSV · 10 тестів · шаблон висновку
Визначте, що саме доводить запис у логах
Лог запитів відповідає на конкретне питання: що дійшло до рівня, де ведеться журнал, і яку відповідь там зафіксовано? З нього не видно, чи Google відрендерив сторінку, обрав її канонічною та включив до індексу. Навіть 200 підтверджує лише відповідь сервера, а не індексацію.
Джерела:[5] Google Crawling Infrastructure[6] Google Search Console Help
Почніть із рішення, на яке може вплинути перевірка. Після розширення каталогу потрібно з’ясувати, чи бот узагалі запитує нові категорії. Після міграції — чи звертається до старих адрес. Завдання «знайти марний обхід» надто розмите: великий лічильник легко сприйняти як проблему ще до того, як визначено бажану поведінку бота.
| Доказ | На яке питання відповідає | Чого не встановлює |
|---|---|---|
| Логи запитів | Чи є перевірений запит у вибраному проміжку? | Рендеринг, індексацію та події поза рівнем збору. |
| Crawl Stats | Чи бачить Google проблеми хоста або зміну складу обходу? | Повну історію запитів до кожного URL. |
| URL Inspection | Що збережено в індексі або чи доступний URL зараз? | Чи потрапить сторінка до індексу після live test. |
| Власний реєстр URL | Які сторінки цієї групи мали бути доступні? | Чи знає Google кожен URL і чи планує його обхід. |
Джерела:[3] Google Search Console Help[6] Google Search Console Help
Запит — лише одна ланка перевірки
Зберігайте запитаний URL як ключ зіставлення. Об’єднання з canonical має бути окремим, свідомим кроком.
- Зібрати
Один рівень логування та проміжок у UTC.
- Перевірити
IP за збереженим списком і точний токен бота.
- Зіставити
Унікальні запитані URL та власний реєстр.
- Дослідити
Індексацію й canonical перевірити окремо.
Джерела:[1] Google Crawling Infrastructure[6] Google Search Console Help
Відкрийте Search Console → Settings → Crawl stats для звірки, а не як заміну сирому експорту. Приклади URL у звіті не є вичерпним списком. Розбіжність із логами — привід перевірити охоплення хостів, дати й повноту збору, а не одразу визнати одне джерело помилковим.
Джерела:[3] Google Search Console Help
Оберіть рівень збору до підрахунку запитів
Коли перед основним сервером працює CDN, спочатку визначте потрібний рівень спостереження. Для відповідей, які отримував бот, беріть доступний і достатньо повний edge-експорт. У наборі Cloudflare HTTP requests поле EdgeResponseStatus описує відповідь клієнту, а OriginResponseStatus — іншу ділянку запиту. Об’єднувати їх як два незалежні відвідування не можна.
Джерела:[7] Cloudflare Docs
Звіт лише з origin теж корисний, якщо прямо вказати це обмеження. Відсутній у ньому URL міг обслуговуватися на CDN. Вибірковий або неповний edge-експорт так само не доводить відсутності запитів. Поруч із файлом збережіть опис збору: хости, рівень логування, проміжок у UTC, семплювання, пропуски та фільтри експорту.
| Поле | Що воно має містити | Що перевірити |
|---|---|---|
| timestamp_utc | ISO 8601 із Z або явним часовим зсувом | Єдина домовленість про час: не змішуйте початок запиту із завершенням відповіді. |
| client_ip | Адресу клієнта з довіреного рівня логування | IP проксі або довільний forwarded-заголовок не підтверджує бота. |
| user_agent | Повне значення user-agent | Збережіть токен продукту. Не позначайте всі агенти Google як пошуковий Googlebot. |
| url | Повний запитаний HTTP(S) URL | Не втрачайте регістр шляху, query, протокол чи кінцевий слеш. Реєстр має використовувати той самий запис. |
| status / method | Код відповіді та HTTP-метод | Охоплення рахується за GET; HEAD відокремлено. |
| resource_kind | html, asset або other | Клас задається під час підготовки. Шлях без розширення сам по собі не доводить, що це HTML. |
| request_id | Глобально унікальний ID у межах цього рівня або порожнє поле | Прибирайте лише повторний експорт того самого запиту. Без надійного ID залишайте поле порожнім. |
Джерела:[7] Cloudflare Docs
Не додавайте тривалість до першої перевірки охоплення, доки не з’ясуєте одиниці та межі вимірювання. Наприклад, NGINX $request_time рахує секунди від перших байтів клієнта до запису в лог після надсилання останніх байтів відповіді. Назва «TTFB у мілісекундах» тут змінює і зміст величини, і її одиницю.
Джерела:[8] NGINX
Підготуйте вибірку, яку можна перевірити
Зафіксуйте групу сторінок
Вивантажте призначені для індексації URL, доступні на початку перевірки. Нові сторінки віднесіть до окремої групи або пізнішого проміжку.
Очікуваний результат: Відсутність запитів до ще не опублікованої сторінки не стає «прогалиною».
Звірте вихідні записи
Простежте один відомий запит від сирого експорту до CSV: час, хост, query, статус та ID. Узгодьте правила приховування чутливих значень.
Очікуваний результат: Нормалізований рядок позначає той самий запит і зіставляється з потрібним записом реєстру.
Перевірте повноту збору
З’ясуйте у відповідального за логи, чи є семплювання, пропущений кешувальний рівень або перебої збору.
Очікуваний результат: Опис охоплення збережено разом з експортом. Непояснені пропуски не дозволяють стверджувати, що обходу не було.
Перевірте Googlebot, не покладаючись лише на user-agent
Рядок user-agent зі словом Googlebot — це заява клієнта. Google попереджає, що її можна підробити. Для пакетного аналізу зіставте IP із опублікованими діапазонами звичайних краулерів, а потім визначте продукт за user-agent. Пошуковий Googlebot слід відокремити від ботів зображень і відео, AdsBot та інструментів перевірки, запущених користувачем.
Джерела:[1] Google Crawling Infrastructure[4] Google Search Central
Документація, перевірена 29 вересня 2026 року, посилається на common-crawlers.json. Збережіть копію, дату отримання й хеш. Аналізатор записує хеш та creationTime, щоб інший спеціаліст міг відтворити перевірку з тим самим списком, а не непомітно підставити новішу версію.
Перевірка IP, яку використовує аналізатор
python · VERIFIEDdef matches_ranges(address: str, networks: list[Any]) -> bool:
ip = ipaddress.ip_address(address)
return any(ip.version == net.version and ip in net for net in networks)Фрагмент log_audit.py. Потрібні імпорти ipaddress і typing.Any та мережі, завантажені load_ranges(). VERIFIED у тестах Python для IPv4, IPv6 і схожого текстового префікса. Окремо ця функція не є повним класифікатором Googlebot.
Джерела:[9] Python documentation
Для однієї сумнівної адреси скористайтеся процедурою reverse DNS із документації: отримайте hostname за IP, перевірте належність до дозволеного домену Google, виконайте пряме DNS-визначення hostname та звірте вихідну адресу. Наявності слова «google» у назві недостатньо. Збережіть команди й відповіді, а не лише позначку «так».
Зіставте перевірені HTML-запити з реєстром URL
Кількість запитів і охоплення URL відповідають на різні питання. Повторні звернення до однієї сторінки збільшують лічильник, але не охоплення. Починайте зі свого реєстру та приєднуйте відфільтровані запити через left join, зберігаючи адреси без збігів. Коли основою є сам лог, невідвідані сторінки просто зникають зі звіту.
У цій методиці охоплення дорівнює кількість придатних URL із хоча б одним перевіреним HTML GET / усі URL зафіксованої групи. Окремий показник успішного обслуговування вимагає відповіді 200 або 304. Це правила цього аудиту, а не пороги Google. Сторінку зі статусом 503 бот запитував, але перевірку відповіді вона не пройшла.
Тестова вибірка: три URL запитано, два успішно обслуговано
Знаменник — чотири цільові адреси. Повторні запити до A не додають нових охоплених URL.
- 200 / 304A · запитано
Три запити: 200, 304, 200. Перевірку відповіді пройдено.
- 503B · запитано
Є запит із 503. Перевірку відповіді не пройдено.
- 200C · запитано
Є 200. Повторний експорт того самого запиту прибрано.
- —D · не виявлено
У цьому проміжку немає запиту, який відповідає умовам.
Не об’єднуйте 304 з редиректами. Цей код дозволяє повторно використати кешоване представлення; категорія «марні редиректи» для всіх 3xx буде хибною. Водночас за 200 може ховатися сторінка з повідомленням про помилку, тому здоров’я шаблону потрібно підтвердити перевіркою вмісту відповіді.
Зафіксуйте правила ідентичності URL до зіставлення. Не видаляйте всі query-параметри й не зливайте адреси зі слешем та без нього лише заради більшої кількості збігів. Якщо експорт і реєстр по-різному записують кодування або хост, створіть явне відображення. Вихідну адресу збережіть, щоб можна було повернутися від групи до конкретного запиту.
Прочитайте закономірність до зміни правил обходу
Я б спочатку перевіряв збої відповідей, потім пропущені важливі сторінки й лише після цього небажані сімейства URL. Так несправна цільова сторінка не губиться за великим, але потенційно нешкідливим лічильником. У висновку мають бути названі група сторінок та альтернативне пояснення, а не просто найбільший стовпчик графіка.
| Що видно | Що перевірити перед зміною | Наступна дія та перевірка |
|---|---|---|
| Перевірені HTML-запити отримують 5xx або 429 | Той самий хост, рівень збору й проміжок; різницю edge та origin. | Дослідити збої або rate limiting. Повторно перевірити адреси та наступні відповіді боту. |
| Важливих URL немає | Дату публікації, ідентичність адрес, повноту збору, доступні посилання та правила доступу. | Перевірити одну гіпотезу щодо знаходження або доступу. Порівняти ту саму групу в наступному проміжку. |
| Переважає сімейство параметрів | Чи вирішує воно окреме завдання? Рахуються запити чи унікальні адреси? | Спочатку визначити політику URL. Перевіряти і небажану групу, і цінні цільові сторінки. |
| Бот запитує старі редиректні адреси | Постійне відображення адрес і внутрішні посилання через старі переходи. | Прибрати зайві внутрішні переходи, залишивши потрібні редиректи. Перевірити кінцеву відповідь. |
| Багато відповідей 304 | Умовні запити й валідатори для незміненого вмісту. | Не вважати це марними редиректами. Переконатися, що оновлений вміст уже не визначається як незмінений. |
Джерела:[2] Google Crawling Infrastructure[5] Google Crawling Infrastructure
Менше запитів до неважливих URL не доводить, що Google витратить різницю на обрані вами сторінки. У документації розділено місткість обходу та попит на нього; тимчасове блокування в robots.txt не рекомендовано як спосіб перерозподілу бюджету. Перш ніж ставити ціль за кількістю запитів, встановіть саме обмеження.
Noindex також не є командою економити обхід: Google має запитати доступну сторінку, щоб побачити директиву. Для надмірної кількості фільтрів є окрема методика керування фасетною навігацією. Якщо відповіді успішні, але проблема саме в індексі, переходьте до діагностики індексації, а не намагайтеся довести її стан логами.
Запустіть аналізатор на відтворюваному наборі
Набір для аналізу SEO-логів містить Python-скрипт без сторонніх бібліотек, нормалізований CSV запитів, реєстр із чотирьох адрес, явно умовний список мереж, тести та шаблон передачі результатів. База даних чи зовнішній сервіс не потрібні. Скрипт не обходить ваш сайт і не змінює правила доступу.
Відтворення тестового звіту
bash · VERIFIEDpython log_audit.py \
--logs requests.csv \
--inventory inventory.csv \
--ranges fixture-ranges.json \
--start 2026-09-01T00:00:00Z \
--end 2026-09-08T00:00:00Z \
--out results-fixture \
--allow-synthetic-ranges
python -m unittest -vВиконуйте в розпакованій папці з Python 3.10+; за потреби використайте команду python3. VERIFIED на доданій вибірці в Python 3.13. Папка результатів не повинна існувати. Початок проміжку включено, кінець — ні. Умовні діапазони призначено лише для вправи.
Очікуваний результат: 4 цільові URL, 3 запитані URL та 2 адреси з відповіддю 200 або 304. Серед шести перевірених HTML GET є один пошуковий URL поза реєстром. Запит до ресурсу не входить до HTML-охоплення. Підроблений user-agent, запит інструмента перевірки, дубль експорту й рядок поза проміжком не завищують результат. HEAD враховано окремо.
Перед coverage.csv прочитайте summary.json. У ньому записані фільтри та категорії відхилених рядків. CSV зберігає кожен URL реєстру, кількість виявлених й успішних запитів, перше та останнє спостереження і статуси. Якщо тестовий результат відрізняється, зупиніться та знайдіть зміну у вході або коді. Сам по собі високий відсоток нічого не перевіряє.
Для робочих даних замініть усі три входи: нормалізований експорт, власний реєстр і збережений офіційний список мереж. Приберіть --allow-synthetic-ranges, вкажіть потрібні дати й нову папку результатів. Скрипт навмисно відхиляє дублікати в реєстрі, некоректні рядки та суперечливі request ID. Виправте джерело й повторіть запуск, не приховуючи ці помилки автоматичним «очищенням».
Перевірте зміну на тій самій групі сторінок
До будь-якої зміни сформулюйте гіпотезу одним реченням. Наприклад: «Посилання на нові категорії з’являються лише після недоступної взаємодії; це може пояснювати відсутність запитів у повному edge-експорті». Відсутність записів — спостереження, пояснення — гіпотеза. Далі потрібно перевірити посилання й доступ, а не заявляти, що Google відхилив сторінки.
Закрийте знахідку набором доказів
Збережіть початковий стан
Зафіксуйте рівень збору, дати, хеш мереж, версію реєстру й проблемні URL. Додайте точну команду запуску.
Очікуваний результат: Інший спеціаліст відтворює підрахунок і розрізняє «не виявлено» та «невдала відповідь».
Змініть одну підтверджену причину
Виправте блокування, зайвий редирект, збій відповіді або відсутнє доступне посилання. Збережіть попереднє правило чи реліз для відкату.
Очікуваний результат: Пряма перевірка підтверджує потрібну відповідь або посилання; сторонні групи сторінок працюють як раніше.
Повторіть і дослідіть результат
Зіставте ту саму групу з описаним наступним проміжком. Перевірте запити та відповіді, а за потреби окремо — індексацію й canonical.
Очікуваний результат: У звіті зазначено, що змінилося, що не змінилося і чого логи все ще не доводять.
Не вимагайте однакової кількості запитів до та після виправлення. Нові матеріали, попит і зміни сайту можуть змінити склад обходу. Порівнюйте помилки відповідей та охоплення разом зі знаменниками, пояснюючи зміни в придатності сторінок. Неповний наступний проміжок слід позначити неповним, а не перетворювати пропущені запити на нібито покращення.
Перший корисний результат — невеликий список важливих URL, фактична поведінка яких суперечить їхньому призначенню. Почніть із нього. Логи допоможуть виділити проблему доступу або знаходження, але для повного SEO-висновку можуть знадобитися перевірки рендерингу й дані про індексацію. У передачі результатів ці висновки мають залишатися окремими.
Джерела та документація
Дати перевірки наведено біля джерел. Межі тестування коду — поруч із прикладами.
- Verify requests from Google crawlers and fetchersGoogle Crawling Infrastructure · Перевірено 29 вересня 2026 р.
- Crawl budget managementGoogle Crawling Infrastructure · Перевірено 29 вересня 2026 р.
- Crawl Stats reportGoogle Search Console Help · Перевірено 29 вересня 2026 р.
- GooglebotGoogle Search Central · Перевірено 29 вересня 2026 р.
- HTTP status codes and network errorsGoogle Crawling Infrastructure · Перевірено 29 вересня 2026 р.
- URL Inspection toolGoogle Search Console Help · Перевірено 29 вересня 2026 р.
- HTTP requests datasetCloudflare Docs · Перевірено 29 вересня 2026 р.
- Module ngx_http_log_moduleNGINX · Перевірено 29 вересня 2026 р.
- ipaddress — IPv4/IPv6 manipulation libraryPython documentation · Перевірено 29 вересня 2026 р.
Потрібно перейти від доказів обходу до виправлення?
Підготуйте групу URL, опис збору та відтворювану знахідку. Наступний крок — перевірити причину й змінити потрібну частину системи.
Обговорити аудит обходу та індексації