У поисковика нет дежурного, который докладывает, куда робот сходил и что там нашёл. Search Console показывает агрегаты: сколько запросов в сутки, какие доли кодов ответа, с каким типом робота. Но ответить на вопрос "когда Googlebot последний раз просил страницу /catalog/product-42 и что сервер ему ответил" консоль не может - по одному адресу историю запросов там не отфильтровать. Ответ живёт в логах сервера, где записан каждый визит. Проблема в том, что на живом сайте это миллионы строк, глазами их не прочитать. Screaming Frog Log File Analyser переводит эту массу в таблицы и графики, за которыми видно реальные привычки робота. Ниже - путь от настройки формата логов до списка проблемных страниц.
Что видят логи сервера и чего не покажет отчёт Search Console
Отчёт статистики обхода в Search Console открывается через настройки ресурса и работает только для свойств корневого уровня. Он показывает общее число запросов, доступность хоста с красной линией, за которой сервер перестаёт успевать, а также разбивку по кодам ответа, типу Googlebot (Smartphone и Desktop), назначению запроса и типу файла. Назначений три: знакомство с новым адресом, обновление уже известного и запрос robots.txt. По этим цифрам видно общее здоровье обхода, но не отдельные страницы.
Показательная ситуация: раздел пропал из выдачи, во всех отчётах спокойно, а в логах видно, что робот приходит на адрес и после неудачного релиза получает 404. Агрегаты усредняют такие истории до безобидных процентов, и без построчной истории диагноз не поставить.
Лог фиксирует каждое событие отдельно: время, IP, метод, адрес, код ответа, размер ответа в байтах, referer, строку User-Agent и, если формат настроен, время отдачи. Из такого материала собирается то, чего нет нигде: частота визитов по конкретному URL, доля дублей в обходе, реальная глубина редирект-цепочек, средняя скорость отдачи шаблонов. Отдельная деталь - редиректы: в статистике Search Console каждый прыжок в цепочке считается отдельным запросом, и в логах это видно по строкам с кодами 301 и 302 подряд.
Именно поэтому инженерная документация Google при разборе пропавших из индекса страниц советует смотреть логи: консоль не хранит историю обхода с фильтром по адресу, а сервер хранит всё.
Полезно понимать и назначение визитов из отчёта консоли. Если свежие страницы получают только запросы обновления, а знакомства почти нет, робот не узнаёт о новом контенте: стоит проверить карту сайта, перелинковку и доступность разделов. В логах назначение визита не пишется, зато виден сам факт и результат каждого запроса, поэтому инструменты не конкурируют, а дополняют друг друга.
Подготовка формата логов nginx и Apache для корректного парсинга
Log File Analyser понимает три формата: Apache (его же отдают nginx), W3C (Microsoft IIS) и Amazon Elastic Load Balancing, включая сжатые файлы. Проблема чаще не в формате, а в составе полей: стандартный combined-лог не пишет время отдачи, а для поиска медленных страниц это ключевая колонка.
В nginx добавляют переменную $request_time:
log_format seo '$remote_addr - $remote_user [$time_local] '
'"$request" $status $body_bytes_sent '
'"$http_referer" "$http_user_agent" $request_time';
access_log /var/log/nginx/access.log seo;В Apache ту же роль играет поле %D, время обслуживания запроса в микросекундах:
LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\" %D" seo
CustomLog logs/seo.log seoТипичная строка после настройки выглядит так:
66.249.66.1 - - [12/May/2026:04:17:03 +0000] "GET /catalog/product-42 HTTP/1.1" 200 8432 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" 412000Здесь 412000 микросекунд - это 0.4 секунды, приличный результат. В IIS включают расширенный формат W3C и отмечают поля cs-uri-stem, cs-uri-query, sc-status, time-taken и cs(User-Agent). Для анализа берут непрерывный срез за две-четыре недели: короче - не поймать цикл обхода, длиннее - файлы разбухнут без новой информации.
Добыть сами файлы проще, чем кажется. На VPS это каталог /var/log/nginx или /var/log/apache2, откуда архивы выгребают по SFTP; на виртуальном хостинге сырые логи обычно отдаются в панели управления разделом статистики. Файлы часто уже сжаты gzip, инструмент их понимает без распаковки. Объём лучше считать заранее: активный интернет-магазин генерирует сотни мегабайтов в неделю, и для двухмесячного среза понадобится место и терпение. Перед выгрузкой стоит убедиться, что ротация не режет файлы посреди суток, иначе события разрежутся по границам.
Загрузка файлов в Screaming Frog Log File Analyser и проверка подлинности бота
Инструмент существует в бесплатной версии с лимитом в тысячу событий и одним проектом и в платной за девяносто девять фунтов в год, снимающей ограничения - объём анализа упирается только в диск. Работает на Windows, macOS и Linux. Бесплатной версии хватает, чтобы разобрать лог маленького сайта или посмотреть интерфейс; на реальном проекте робот генерирует тысячи событий за сутки.
Интерфейс разложен по вкладкам: обзор, адреса, коды ответов, User-Agent-ы, referer-ы, каталоги, IP, страны, объёмы, события и импортированные таблицы. Один проект собирает события всех роботов сразу, и рядом с Googlebot видно поведение ботов Яндекса и Bing, а свежие версии научились показывать и AI-краулеров. Сопоставление полезно: у роботов разные привычки, и страница, которую Яндекс обходит ежедневно, а Google игнорирует месяц, - типичная находка такого сравнения.
После загрузки файлов настраивают часовой пояс, диапазон дат и список User-Agent. Дальше начинается то, ради чего инструмент покупают: автоматическую проверку подлинности ботов. Строку User-Agent подделывается за секунды, и в логах почти любого крупного сайта живёт "Googlebot", которым на самом деле является чужой парсер или конкурентный монитор. Верификация по IP выполняется в четыре шага:
- выполнить обратный DNS-поиск по IP из лога командой host;
- убедиться, что полученное имя оканчивается на googlebot.com или google.com;
- выполнить прямой DNS-поиск по этому имени;
- сверить вернувшийся IP с исходным адресом из лога.
host 66.249.66.1
host crawl-66-249-66-1.googlebot.comУ настоящих краулеров имя имеет вид crawl-IP-адрес.googlebot.com, у геораспределённых - geo-crawl-IP-адрес.geo.googlebot.com, и обратный lookup совпадает с прямым. Google дополнительно публикует актуальные списки IP-адресов в машиночитаемом виде, по ним проверку можно автоматизировать. После фильтра в интерфейсе видно, какую долю трафика составляли притворяющиеся роботы, и результат часто оказывается сюрпризом.
Поиск проблемных страниц по кодам ответа и времени отдачи
Первая остановка - вкладка кодов ответа. Красные зоны стандартны: лавина 404 от битых внутренних ссылок, которая выжигает запросы и подсказывает роботу, что сайт неаккуратен; 5xx в ночные часы, когда база не выдерживает бэкапы; цепочки редиректов, где один переход превращается в три. Инструмент показывает inconsistent response codes - адреса, которые вчера отвечали 200, а сегодня 404: такое поведение бывает у страниц с плавающей логикой генерации.
Вторая остановка - время и объём. Средняя скорость отдачи и средний размер по каждому URL выделяют тяжёлые шаблоны: обычно это страницы с сотней товаров в списке или неоптимизированными картинками. Медленная страница съедает не только время пользователя, но и слоты обхода: пока робот ждёт ответ, он не просит следующий адрес.
Третья остановка - дата последнего визита. Сортировка по колонке времени последнего события показывает разделы, куда Googlebot не заглядывал месяцами. Часто выясняется, что робот по кругу ходит по одному каталогу и ни разу не дошёл до свежего раздела, потому что на него нет внутренних ссылок.
Referer-ы добавляют к картине источник перехода: видно, с каких страниц робот пришёл на адрес. Это помогает отличать страницы, найденные по карте сайта, от встреченных по внутренним ссылкам. Вкладка IP показывает, с какого пула адресов приходит основная масса запросов: у Google это диапазон 66.249.., и аномальная активность с единственного адреса сигнализирует о скрытой нагрузке или краулере под чужим флагом.
Анализ расхода бюджета обхода на разделы и параметрические адреса
Вкладка каталогов раскладывает обход по разделам, и здесь чаще всего вскрыаются главные потери. Доля параметрических адресов - сортировок, фильтров, меток отслеживания, сессионных идентификаторов - у неоптимизированного магазина легко превышает половину всех событий. Календарь с бесконечной пагинацией по годам и месяцам способен сам замотать робота на годы вперёд.
Порядок разбора обычно обратный приоритету: сначала считают сумму событий по каждому каталогу и параметру, затем выбирают топ шумных паттернов и решают судьбу каждого. Параметр utm-меток почти всегда закрывается целиком: контент он не меняет, а в обходе оставляет тысячи фантомных адресов. Сортировки и фильтры требуют честного решения: если отфильтрованная страница полезна и имеет спрос, её оставляют в индексе с собственным canonical, если нет - закрывают от обхода.
Ещё один ракурс - сравнение частот. Список наименее посещаемых адресов внутри живого раздела указывает на страницы, до которых робот не доходит из-за глубины вложенности: третий уровень от главной получает визиты каждую неделю, шестой - раз в месяц. Сверка с картой сайта показывает, сколько заявленных адресов вообще имели события за период: разница между числом URL в карте и числом посещённых - простая метрика качества обхода, которую стоит держать перед глазами.
Против найденного работают адресными средствами: бесконечные пространства закрывают в robots.txt, дубли сортировок собирают через canonical, внутренние ссылки ведут на чистые адреса, а не на текущую параметрическую версию. Для неизменённого контента работает ответ 304 Not Modified: сервер не отдаёт тело страницы, экономя и трафик, и время обхода.
Отдельная ценность - поиск страниц, которых робот не видел вообще. В инструмент импортируют список адресов из краулинга SEO Spider или карту сайта и сверяют с логами: непосещённые URL подсвечиваются как uncrawled, а адреса, отсутствующие и в обходе, и в перелинковке, как орфанные. Важно и обратное сопоставление: любые внешние таблицы с колонкой URL можно объединить с логами и посмотреть, например, есть ли у страниц без посещений внешние ссылки.
Сопоставление логов с краулингом сайта и регулярный контроль
Разовый анализ логов даёт список задач, но привычку они приобретают через регулярность. Рабочий ритм для среднего сайта - месячный срез логов при неизменных настройках: сравнение долей кодов ответа, частоты визитов разделов и количества уникальных адресов показывает динамику. Цифры логов сверяют со статистикой обхода в Search Console: расхождения в суточных объёмах запросов подсказывают, что часть событий уходит мимо анализа, например на поддомен.
Приоритет правок логичен: сначала то, что мешает и людям, и роботам - пятисотые коды и медленные шаблоны; потом потери бюджета - параметры и бесконечные пространства; в конце пробелы - важные страницы без посещений.
Результаты удобно выпускать в формате задач для команды разработки: экспортированные списки адресов с кодами ответов, средним временем и числом событий превращаются в понятный бэклог, где каждая правка измерима. Через месяц новый срез покажет, сработало ли: доля сортировок в обходе должна упасть, среднее время отдачи выровняться, а разделы без визитов получить первые события. Проект сохраняют как есть - файлы, настройки и результаты остаются в базе инструмента, к следующему месяцу достаточно подгрузить новые логи в тот же проект и сдвинуть диапазон дат. Логи не заменяют другие инструменты, они их заземляют: краулинг SEO Spider показывает, как сайт может выглядеть для робота, а логи - как он выглядит на самом деле. Между этими двумя картинами и живёт вся техническая оптимизация обхода.