Анализ логов сервера: что видно про робота

Чем лог отличается от всего остального

Любой другой источник данных о сайте показывает результат. Лог показывает процесс.

Панель вебмастера сообщает, что страница «просканирована, но не проиндексирована». Из этой формулировки не видно, сколько раз робот к ней приходил, что получал в ответ и не тратил ли он в это же время половину обхода на адреса с параметрами сортировки. В журнале это видно построчно.

Системы веб-аналитики роботов не видят вовсе: их код исполняется в браузере, а робот скрипты не запускает так же, как человек. Поэтому в отчётах аналитики обхода нет в принципе — там только люди.

Отсюда область применения. Логи нужны, когда вопрос звучит как «куда девается бюджет обхода», «доходит ли робот до глубоких разделов», «что он получал в ответ во время аварии». На вопросы про позиции и релевантность журналы не отвечают.

Что записано в строке

Стандартная строка журнала в объединённом формате состоит из полей, разделённых пробелами. Для анализа нужны шесть из них.

Последнее поле — заявление, а не факт. Представиться роботом поисковой системы может любая программа, и в журналах крупного сайта таких обращений обычно немало. Поэтому анализ начинается с фильтрации по user-agent, но выводы делаются только после проверки подлинности.

Отдельно стоит смотреть на обращения краулеров, собирающих данные для языковых моделей: они присутствуют в тех же журналах и подчиняются тем же правилам файла robots.txt — их состав и назначение разобраны в материале про llms.txt.

Четыре вопроса, на которые отвечают только логи

На что уходит обход. Распределение запросов по разделам показывает, сколько ресурса достаётся каталогу, сколько — служебным адресам, сколько — параметрическим вариантам. Картина «две трети обхода на страницы фильтров» встречается регулярно и ни в одном другом отчёте не видна.

Что робот получал в ответ. Код 200 в браузере не означает, что робот получал то же самое. Всплеск 503 во время выкатки, 403 от защиты от ботов, цепочки переадресаций — всё это фиксируется по факту.

Доходит ли робот до глубины. Наличие в журнале запросов к страницам списка с большими номерами — прямое подтверждение, что маршрут вглубь работает; отсутствие — что он оборван. Механика разобрана в пагинации.

Что робот нашёл сам. В журнале появляются адреса, которых нет ни в карте сайта, ни в вашем представлении о структуре: старые версии страниц, комбинации параметров, следы прошлых движков. Это же основной способ обнаружить чужие страницы после взлома.

Пятый вопрос стоит особняком, потому что ответ на него меняется со временем: как часто робот возвращается к конкретной странице. Интервал между обращениями к одному адресу — косвенный признак того, насколько система считает страницу изменчивой и нужной. Раздел, к которому робот приходит ежедневно, и раздел, к которому он заглядывает раз в несколько недель, различаются не содержанием страниц, а тем, что первый регулярно обновляется и получает ссылки. Сопоставление интервалов с датами публикаций показывает, реагирует ли обход на вашу работу вообще.

Как посчитать

Работа начинается с трёх команд. Файл журнала здесь называется access.log, поле пути — седьмое, поле кода ответа — девятое; в других форматах номера сдвинутся.

grep -ci 'googlebot' access.log
awk '{print $7}' access.log | sort | uniq -c | sort -rn | head -n 20
grep -i 'googlebot' access.log | awk '{print $9}' | sort | uniq -c | sort -rn

Что означают результаты:

• Первая команда — общее число обращений робота за период. Само по себе число ничего не значит, смысл появляется при сравнении с соседним периодом: падение вдвое после выкатки — повод искать причину в ответах сервера.
• Вторая команда — двадцать самых запрашиваемых адресов. Здоровая картина: сверху главная, хабы разделов, свежие материалы. Тревожная: сверху адреса с параметрами, страницы внутреннего поиска, календарь архива. Это прямое указание, что закрывать от обхода.
• Третья команда — распределение кодов ответа для робота. Ожидаемо преобладание 200 и 304. Заметная доля 404 означает, что робот ходит по несуществующим адресам; доля 301 — что переадресации стоят там, где должны стоять прямые ссылки; появление 503 — что сервер отдавал недоступность.

Флаг -c в первой команде считает строки, -i игнорирует регистр. Во второй sort | uniq -c даёт частоты, sort -rn выстраивает по убыванию.

Отдельного внимания заслуживает код 304. Он означает, что робот запросил страницу условно и сервер ответил «не изменилась с прошлого раза», не передавая тело. Высокая доля таких ответов — хороший признак: обход идёт экономно, ресурс тратится на новое. Полное отсутствие 304 при том, что содержимое сайта стабильно, обычно означает, что сервер не отдаёт заголовки, позволяющие роботу спрашивать условно, и каждая страница качается заново.

Подлинность обращений проверяется отдельно, по IP-адресу из первого поля:

host 66.249.66.1

Ответ вида ... domain name pointer crawl-66-249-66-1.googlebot.com означает, что адрес принадлежит поисковой системе. Ответ с именем произвольного хостинг-провайдера или отсутствие записи — обращение поддельное, и в статистику обхода его включать нельзя. Полная проверка требует и обратного шага: разрешить полученное имя обратно в IP и убедиться, что адрес совпал.

Чего в логах нет

Ограничения у журналов жёсткие, и это ровно та половина картины, о которой забывают.

Нет причин. Лог фиксирует, что робот запросил адрес и получил ответ. Почему после этого страница не попала в индекс, из журнала не выводится: решение принимается на стороне системы и наружу не сообщается. Статусы страниц смотрят в панели вебмастера, а сопоставление с журналом даёт больше, чем каждый источник по отдельности.

Нет рендеринга. Обычная запись показывает запрос HTML-документа. Загружает ли робот скрипты, исполняет ли их и что видит после исполнения — по журналу не восстанавливается, хотя запросы к файлам скриптов в нём есть.

Нет полноты при кэшировании. Если перед сайтом стоит кэширующий слой или сеть доставки, часть запросов до вашего сервера не доходит и в журнал не попадает. Картина получается заниженной, и об этом нужно знать до того, как делать выводы о падении обхода.

Нет удобства на больших объёмах. Журнал нагруженного сайта за месяц — это гигабайты. Командной строки хватает для разовых проверок; для регулярной работы нужны либо выгрузки в таблицы, либо специализированные инструменты.

Нет связи с содержанием. Из журнала не видно, что было на странице. Полный разбор требует сопоставления с выгрузкой краулера — только вместе они показывают, что робот ходил не туда и что там лежало.

Спорное место

Анализ логов принято подавать как высшую ступень технической работы: настоящие данные, никаких посредников, видно всё как есть. Отчасти это верно — источник действительно первичный.

Проблема в том, что выводы из него чаще всего совпадают с выводами более дешёвых проверок. Робот тратит обход на фильтры — это видно и по числу адресов в индексе. Робот не доходит до глубоких страниц — это видно по тому, что они не в поиске. Журнал добавляет точности, но редко меняет решение.

Практическое следствие неудобное для тех, кто любит сложную работу: логи имеет смысл открывать после того, как сделаны обычные проверки из технического аудита, а не вместо них. Исключение одно — расследование конкретного инцидента с датой. Там журнал незаменим, потому что он единственный помнит, что происходило в тот день.

Частые вопросы

Источники

1. Журнал сервера — Wikipedia
2. Проверка робота Googlebot — Google