Глава 33
Серверні журнали: реальна поведінка сканера замість припущень
Серверні журнали не пояснюють, чому Google ранжує сторінку. Вони показують інше, не менш важливе: які URL бот насправді запитував, коли, з яким статусом відповіді та з якими витратами ресурсів сервера.
В експорті даних сканера ми бачимо, що може обійти наш сканер. У Search Console — агреговані дані телеметрії Google. У серверному журналі — конкретний HTTP-запит. Саме тому серверні журнали незамінні для великих сайтів, міграцій, діагностики сканування та випадків, коли «Google чомусь не бачить сторінки».
Але аналіз серверних журналів легко може створити ілюзію точності. User-Agent можна підробити, зворотний проксі-сервер може приховувати IP-адресу клієнта, CDN може використовувати інший формат записів, а запити, оброблені кешем, можуть не потрапляти до журналів вихідного сервера. Перед аналізом треба з’ясувати, на якому саме рівні інфраструктури записуються запити.
33.1Перевіряйте справжність Googlebot
Google прямо попереджає, що інші сканери часто імітують User-Agent Googlebot. Найнадійніші підходи — перевірка через зворотний DNS-запит або зіставлення IP-адреси з опублікованими діапазонами IP-адрес Googlebot.[1]
33.2Мінімальний набір полів
Для SEO потрібні часова мітка, IP-адреса клієнта, метод HTTP, ім’я хоста, URL або шлях із рядком параметрів запиту, статус відповіді, розмір відповіді в байтах, час відповіді та User-Agent. Адреса джерела переходу корисна не завжди, але я зберігаю її, якщо вона є. Якщо CDN додає статус кешування або дані про затримку на периферійному чи вихідному сервері — ще краще.
33.3Частота сканування
Кількість звернень сама по собі не є метрикою «важливості». Частота залежить від актуальності вмісту, попиту на сканування, сигналів, потужності сервера та багатьох внутрішніх рішень. Але в межах одного сайту розподіл звернень корисний: сторінки яких шаблонів отримують 60% запитів, до яких нових URL бот не звертається, які старі URL зі статусом 404 запитуються місяцями.
33.4Розподіл статусів відповіді
Статус 200 свідчить про успішне отримання вмісту, але не гарантує індексації. Статуси 301/302 показують додаткові витрати на перенаправлення; 404/410 — видалені URL; 429 і 5xx можуть сигналізувати про перевантаження або збій. Google рекомендує 500/503/429 як тимчасовий екстрений спосіб різко знизити інтенсивність сканування, але це грубий інструмент, і тривалі помилки можуть призвести до випадання URL з індексу.[2]
33.5Час відповіді та спроможність сервера обробляти сканування
Повільний сервер не означає автоматичного «штрафу в ранжуванні», але допустима інтенсивність сканування пов’язана зі здатністю хоста відповідати без перевантаження. Якщо затримка зростає і з’являються серверні помилки, інтенсивність сканування може змінюватися.
33.6Зайві витрати на сканування URL із параметрами
Серверні журнали добре показують, чи витрачаються ресурси сканування на URL із параметрами сортування, відстеження, ідентифікаторами сесій, комбінаціями фасетних фільтрів і внутрішнього пошуку. Я виділяю провідні параметри запиту за кількістю звернень та унікальних URL. Потім перевіряю, звідки бот може виявити ці URL: із внутрішніх посилань, старих зовнішніх посилань, файлів sitemap чи JavaScript.
33.7Виявлення нових URL і повторне сканування
Корисно умовно розділяти перші звернення до URL і повторне сканування вже відомих URL. Якщо під час запуску додано 50 000 нових товарів, але за три дні Googlebot уперше звернувся лише до 5 000, проблема радше у виявленні URL або попиті на сканування. Якщо бот уже звернувся до всіх URL, але вони не проіндексовані — це проблема іншого рівня.
33.8Моніторинг міграції
Після міграції серверні журнали показують фактичне повторне сканування старих URL, переходи через перенаправлення, запити до нових URL і помилки. Я формую групи: старі URL із найбільшим трафіком, URL із найвагомішими зовнішніми посиланнями, категорії та сторінки на великій глибині вкладеності.
33.9Чого серверні журнали не показують
Серверні журнали не показують, чи проіндексовано URL, яку позицію він має, чи цитують його системи ШІ, який намір користувача або яка «оцінка бюджету сканування». Запит — це лише запит. Тому серверні журнали треба поєднувати з переліком URL, отриманим під час сканування, даними Search Console, а також даними про статуси та канонічні URL.
33.10Зберігання та вибірковий аналіз
Обсяг серверних журналів великого сайту може сягати терабайтів. Я зберігаю необроблені дані в недорогому сховищі, а для аналізу використовую секціоновану таблицю з потрібними полями. Для регулярно оновлюваної аналітичної панелі достатньо добових агрегованих даних; необроблені дані потрібні для детального розбору збоїв.
Це скорочений виклад: у книзі кожна глава має повний розбір, таблиці й приклади. Завантажити книгу або почати зі вступу.