Аналіз логів Googlebot показує, які запити підтвердженого робота потрапили до вибраного журналу, які адреси він запитував і які відповіді зафіксувала система. За цими записами не можна встановити, що сторінку було відрендерено, включено до індексу або показано користувачеві.
Для корисного звіту заздалегідь визначте період, рівень збирання та очікувані групи сторінок. Потім перевірте походження запитів, збережіть початкові URL й окремо підрахуйте повторні звернення, коди та час відповіді. Відсутність запису означає лише те, що його немає в доступній вибірці.
Що попросити у розробника
Спочатку сформулюйте робоче запитання. Наприклад: чи звертався Googlebot до нових карток після імпорту або які параметри каталогу трапляються в його запитах? Для відповіді попросіть журнал за погоджений період і перелік опублікованих сторінок на дату перевірки. У реєстрі зазначте мови, типи шаблонів, дату появи та очікувану роль адрес.
Уточніть, на якому рівні записуються події: CDN, балансувальник чи основний сервер. Якщо CDN відповідає з кешу і запит не доходить до основного сервера, в origin-лозі його не буде. За наявності кількох джерел опишіть охоплення кожного, можливу вибірковість і пропущені проміжки. Не додавайте два записи одного запиту як два незалежні візити, якщо їх вдалося пов’язати за ідентифікатором; за відсутності такого зв’язку не вигадуйте об’єднання.
Попросіть опис полів і способу експорту. Для перевірки потрібні час, хост і повний шлях із параметрами, метод, код відповіді, User-Agent, IP джерела з довіреного рівня та, за наявності, ідентифікатор запиту. Для аналізу швидкості знадобляться значення, одиниці та визначення вимірюваного інтервалу. Отримуйте лише необхідні дані та зберігайте вихідні журнали в погодженому захищеному місці: параметри URL і заголовки можуть містити відомості про відвідувачів.
Приведіть час і поля до однієї схеми
Збережіть оригінальний файл і створіть робочу копію з описом перетворень. Уточніть часовий пояс кожного джерела, переходи часу та те, чи стосується позначка початку запиту або запису відповіді. Для зіставлення переведіть час в одну шкалу й зафіксуйте межі періоду. Без цього сплеск помилок після релізу може виявитися помилкою порівняння часу.
Не втрачайте протокол, хост, регістр шляху, кінцевий слеш і параметри до перевірки їхньої ролі. /chairs/ і /chairs/?sort=price можуть належати до однієї товарної групи, але це різні запитані адреси. Збережіть обидві форми: початковий URL для перевірки й окрему мітку групи для звіту. Не підставляйте canonical замість запитаної адреси без окремого правила та джерела.
Переконайтеся, що до вибірки потрапляють потрібні методи й типи ресурсів. Запит сторінки, зображення та файлу sitemap відповідають на різні запитання; HEAD не слід без пояснення змішувати з GET. Під час повторного експорту видаляйте лише доведені дублікати однієї події, а не два реальні звернення до однієї адреси в різний час.
Перевірте, хто зробив запит
Рядок User-Agent можна підробити. Спочатку виділіть кандидатів за потрібним позначенням робота, потім перевірте IP за відповідною процедурою Google. Для окремих адрес використовують зворотний DNS-запит, перевірку отриманого доменного імені та прямий DNS-запит: отриманий IP має збігтися з початковим. Для основного Googlebot звіряйте ім’я з актуальною маскою Google, наприклад crawl-*.googlebot.com або geo-crawl-*.geo.googlebot.com. Одного слова Google всередині довільного домену недостатньо. Для масової перевірки можна використати опубліковані Google діапазони відповідної категорії роботів.
Не називайте будь-яке звернення з інфраструктури Google пошуковим Googlebot: різні роботи та завантажувачі, які запускає користувач, мають різне призначення. Збережіть метод, дату перевірки та версію списку діапазонів. Для старого журналу враховуйте, що поточний список або DNS не завжди відтворює попередній стан. Непідтверджені рядки залиште окремо, а не включайте до підсумку як встановлений обхід.
Під час роботи через проксі перевірте, чи справді поле містить адресу початкового клієнта. Довільний заголовок пересилання та IP самого CDN не доводять походження запиту. Технічну перевірку виконують на вихідних даних з обмеженим доступом; у звіті зазвичай достатньо агрегованих результатів і методу без публікації IP.
Розберіть умовні записи та повторні звернення
Нижче – вісім вигаданих запитів GET до магазину example.com за один короткий проміжок. Для прикладу вважаємо, що походження кожного вже підтверджено і всі записи отримано на одному рівні збирання. Час наведено в UTC, тривалість – умовний інтервал відповіді в секундах за одним визначенням. Це не дані клієнта й не репрезентативна вибірка обходу.
| Час UTC | Запитаний шлях | HTTP | Тривалість, с |
|---|---|---|---|
| 09:00 | /ru/chairs/ | 200 | 0,20 |
| 09:05 | /ru/chairs/ | 304 | 0,08 |
| 09:07 | /ru/chairs/?sort=price | 200 | 0,30 |
| 09:08 | /ru/chairs/?sort=price | 200 | 0,34 |
| 09:10 | /ru/chairs/?color=black | 200 | 0,28 |
| 09:12 | /ru/chair-a/ | 200 | 0,25 |
| 09:14 | /ru/chair-b/ | 503 | 1,20 |
| 09:16 | /ru/old-chair/ | 301 | 0,09 |
Два звернення до сортування залишено як дві події, хоча URL збігається. Відповідь 304 не дорівнює серверній помилці: вона повідомляє, що для умовного запиту версія не змінилася. Код 301 у старої адреси потребує перевірки кінцевої цілі; одна відповідь 503 у картки B – привід дослідити доступність і журнали поблизу цього часу, а не доказ постійної відмови.
Згрупуйте результати та збережіть знаменник
Для прикладу об’єднаємо події за призначенням адреси, не видаляючи початкові рядки. У таблиці зазначено середню тривалість лише за показаними запитами; вона не є швидкістю завантаження сторінки у відвідувача або показником TTFB. Округлення до сотих виконано після розрахунку.
| Група URL | Підтверджені запити | Коди | Час відповіді | Період | Дія |
|---|---|---|---|---|---|
| Основна категорія | 2 звернення до одного URL | 200 і 304 | Середнє 0,14 с | 09:00–09:16 UTC | Зберегти обидві події; перевірити реєстр потрібних категорій |
| Параметри категорії | 3 звернення до двох URL | Три відповіді 200 | Середнє 0,31 с | 09:00–09:16 UTC | Уточнити призначення сортування та відбору за кольором; оцінити довший період |
| Картки A і B | 2 звернення до двох URL | 200 і 503 | Середнє 0,73 с | 09:00–09:16 UTC | Дослідити відповідь 503 і стан картки B |
| Стара адреса картки | 1 звернення | 301 | 0,09 с | 09:00–09:16 UTC | Перевірити кінцеву адресу та призначення перенаправлення |
Перевірка суми: 2 + 3 + 2 + 1 = 8 подій. Для параметрів середнє становить (0,30 + 0,34 + 0,28) / 3, тобто близько 0,31 секунди. Для карток (0,25 + 1,20) / 2 = 0,725 секунди, або 0,73 після округлення. Чотири групи та їхні частки описують лише цей умовний фрагмент.
Для оцінки охоплення зіставте список очікуваних опублікованих URL з унікальними запитаними адресами за однаковий період. Сторінки без знайденого звернення зберігайте окремими рядками, а не прибирайте зі знаменника. За неповного origin-логу пишіть «не знайдено в цьому журналі», а не «робот ніколи не відвідував сторінку».
Перетворіть спостереження на перевірювані дії
У звіті вкажіть мету, джерело, рівень збирання, період і часовий пояс, охоплення хостів, метод підтвердження робота, правила групування та відомі пропуски. Додайте знеособлені приклади запитів із помилками та вкажіть, хто перевірить сервер, шаблон або джерело посилань. За великої кількості параметрів спочатку розберіть їхнє призначення; окремий матеріал пояснює, як обмежити технічні URL фільтрів.
Порівняйте висновки з доступним звітом про статистику сканування Search Console, враховуючи різницю джерел і періодів. Для важливих сторінок окремо запросіть відомості про індексацію: перевірка великого каталогу потребує власного плану й не замінюється логами. Якщо після виправлення змінюється кількість запитів, врахуйте одночасно інші зміни та не обіцяйте автоматичного зростання індексації або трафіку.
Потрібна допомога з вашим проєктом?
Залиште ім’я та номер телефону. Зв’яжуся з вами, щоб обговорити завдання, обсяг робіт і наступний крок.
