Анализ логов сервера: что на самом деле видит робот
Все привычные SEO-инструменты показывают вам сайт таким, каким его видит краулер этого инструмента. И только логи веб-сервера показывают сайт таким, каким его реально обходили Яндекс и Google: какие URL робот дёргал сегодня ночью, сколько раз, с каким кодом ответа и за сколько миллисекунд. Это единственный источник данных, который не моделирует поведение робота, а фиксирует его. Именно в логах обнаруживаются вещи, которых нет ни в одном отчёте: сотни тысяч обходов страниц фильтров, робот, который девятый месяц упорно долбится в удалённый раздел, и товарные карточки, до которых он не доходил ни разу. В этой статье разбираем лог-анализ так, как мы делаем его на проектах: от выгрузки сырых файлов до готового списка правок, которые дают прирост в рамках SEO-продвижения.
Коротко
- Лог сервера — единственный источник фактических данных о поведении робота: краулер-эмулятор показывает, что робот мог бы обойти, лог показывает, что он обошёл.
- Минимальный полезный период выгрузки — 30 дней, для крупных каталогов — 60–90; за неделю картина обхода не складывается.
- User-agent подделывается тривиально: настоящего робота подтверждают только обратным DNS-запросом с проверкой в прямую сторону.
- Главная находка почти любого лог-анализа — доля обходов, потраченная на URL, которых вообще не должно быть в индексе: параметры фильтров, сортировки, UTM-метки, пагинация, цепочки редиректов.
- Ключевая метрика — не «сколько обходов всего», а «какая доля коммерчески важных URL получила хотя бы один обход за период».
- Логи стыкуются со сканом краулера и выгрузкой трафика — из пересечения этих трёх таблиц рождаются самые ценные выводы.
Почему логи — единственный честный источник данных об обходе
Между тем, как SEO-специалист представляет себе обход сайта, и тем, что происходит на сервере, обычно лежит пропасть. Сканер вроде Screaming Frog обходит сайт по вашим правилам: с вашим лимитом глубины, вашим списком стартовых URL, вашим набором ограничений. Он моделирует идеального робота. Настоящий робот ведёт себя иначе: у него свои приоритеты, своя история сайта, свой накопленный список URL — включая те, которые вы удалили два года назад, но которые он до сих пор помнит и периодически проверяет.
Панели вебмастеров дают агрегаты. Яндекс.Вебмастер покажет статистику обхода в разрезе кодов ответа и суммарное число загруженных страниц, Google Search Console — отчёт «Статистика сканирования» с разбивкой по типу файла, назначению и типу робота. Это полезно, но это витрина: там нет пути к конкретному URL, нет времени ответа по конкретному разделу, нет возможности сказать «вот эти 12 400 адресов с параметром ?sort= съели 38% обходов за месяц». Всё это есть только в логах.
Лог-анализ отвечает на вопросы, на которые больше не отвечает ничто:
- Какие разделы робот обходит регулярно, а какие не трогал ни разу за 60 дней?
- Сколько процентов обходов приходится на страницы, приносящие деньги, а сколько — на технический мусор?
- Какие URL робот получает с кодом 5xx — и не совпадают ли эти всплески с моментами просадки позиций?
- Через сколько дней после публикации новая карточка получает первый обход?
- Не бьётся ли робот в цепочки редиректов, оставшиеся после переезда?
- Есть ли страницы-сироты, которые робот знает, а внутренняя перелинковка — нет?
Сканер показывает, что робот может обойти. Лог показывает, что он обошёл. Разница между этими двумя списками — и есть ваша работа на ближайший квартал.
Как устроен лог и что в нём лежит
Веб-сервер записывает по строке на каждый входящий запрос. Формат по умолчанию у Nginx и Apache — combined. Типичная строка выглядит так: IP-адрес клиента, метка времени с таймзоной, метод и путь запроса с протоколом, код ответа, размер тела ответа в байтах, реферер, строка User-Agent. Для лог-анализа этого хватает, но два поля стоит добавить в конфигурацию заранее — они окупаются моментально.
| Поле лога | Что даёт SEO-специалисту | Комментарий |
|---|---|---|
| IP-адрес | Верификация робота, отсев подделок | Единственное поле, которое нельзя подделать в рамках TCP-сессии |
| Дата и время | Частота обхода, всплески, реакция на публикации | Проверьте таймзону: часть серверов пишет UTC, часть — локальное время |
| Метод + URL | Ядро анализа: что именно обходится | Строка запроса с параметрами обязательна, без неё утечки бюджета не видно |
| Код ответа | Битые обходы, редиректы, серверные ошибки | Смотрите распределение в динамике по дням, а не одной суммой |
| Размер ответа | Выявление пустых и обрезанных ответов | Ответ 200 весом 1,2 КБ на карточке товара — почти всегда сломанный шаблон |
| User-Agent | Первичное разделение роботов и людей | Подделывается одной строкой в curl — верить нельзя |
| Время ответа ($request_time) | Медленные разделы, которые робот обходит реже | Не входит в combined по умолчанию — добавьте в log_format |
| Host ($host) | Разделение поддоменов и зеркал в одном логе | Критично, если на сервере несколько доменов |
Отдельно про объёмы. Один запрос в combined-формате — это примерно 200–400 байт. Магазин с 50 тысячами страниц и активным обходом легко генерирует 1,5–4 ГБ сырых логов в месяц с учётом людей и статики. Это нормальный размер, который переваривается обычным ноутбуком, если сначала отфильтровать статику и людей. Проблемы начинаются на проектах с миллионами URL — там уже нужен BigQuery, ClickHouse или ELK-стек.
ГЛАВНАЯ ОШИБКА ПОДГОТОВКИ
Ротация логов по умолчанию хранит 7–14 дней и удаляет остальное. Это значит, что если вы попросите логи «за последний квартал» — их просто нет, и ждать придётся заново. Первое, что нужно сделать на любом проекте, где планируется техническое SEO, — попросить администратора включить хранение логов минимум на 90 дней и складывать архивы в отдельное хранилище. Это одна строка в конфигурации logrotate и ноль рублей бюджета.
Как собрать логи: практическая сторона
Где они лежат
На Nginx стандартный путь — /var/log/nginx/access.log плюс ротированные архивы вида access.log.1, access.log.2.gz и дальше. На Apache — /var/log/apache2/access.log или /var/log/httpd/access_log в зависимости от дистрибутива. На виртуальном хостинге логи обычно доступны через панель управления (ISPmanager, cPanel) в разделе статистики или лежат в домашней директории аккаунта в папке logs. У некоторых хостеров логи отдаются только по запросу в поддержку — это тоже нормально, просто заложите пару дней на переписку.
Что мешает и как это обходить
Реальность сложнее учебника. Если перед сайтом стоит CDN или облачный прокси (Cloudflare, Selectel, собственный балансировщик), в логах бэкенда вы увидите IP прокси вместо IP робота — верификация станет невозможной. Решение: попросить админов пробросить реальный IP в заголовок X-Forwarded-For или CF-Connecting-IP и добавить это поле в формат лога. Если стоит кэширующий слой, часть запросов робота может отдаваться из кэша и не доходить до бэкенда — тогда логи нужно снимать с фронтенд-слоя или с CDN напрямую (у большинства провайдеров есть выгрузка логов, иногда за деньги).
Второй частый сюрприз — балансировка на несколько серверов. Если у вас три бэкенда, логи нужно собрать со всех трёх и склеить, иначе вы увидите треть обхода и построите картину на неполных данных. Всё, что связано с конфигурацией сервера, косвенно бьёт и по скорости — эту связку мы разбирали в материале о том, как хостинг влияет на SEO и позиции.
Какой период брать
Минимум — 30 дней. За 7 дней вы увидите шум: робот обходит сайт волнами, недельного окна не хватает даже для средних проектов. Для каталогов от 10 тысяч URL берите 60 дней, для крупного e-commerce — 90. Чем больше сайт, тем длиннее цикл полного обхода и тем длиннее должно быть окно наблюдения. Если анализируете последствия конкретного события — переезда, релиза, смены структуры — берите период, симметрично захватывающий 3–4 недели до и после.
Как отличить настоящего робота от самозванца
Это тот шаг, который пропускают чаще всего — и потом строят выводы на мусорных данных. Строка User-Agent — это просто текст, который клиент присылает о себе сам. Написать в ней «Mozilla/5.0 (compatible; YandexBot/3.0)» может кто угодно: парсер конкурента, сервис мониторинга цен, чей-то самописный скрипт, сканер уязвимостей. На типичном коммерческом сайте доля фальшивых «роботов» в логах составляет заметную часть трафика, и если её не отсечь, вы получите завышенные цифры обхода и ложную уверенность, что с краулингом всё хорошо.
Единственный корректный способ верификации — двусторонняя проверка DNS (reverse DNS lookup с последующей forward-проверкой):
Обратный запрос по IP
Берём IP из строки лога и делаем обратный DNS-запрос: host 5.255.253.1 или nslookup. Получаем доменное имя, например spider-5-255-253-1.yandex.com.
Проверяем домен
Имя должно оканчиваться на официальный домен поисковика: для Яндекса это yandex.ru, yandex.net или yandex.com; для Google — googlebot.com или google.com. Всё остальное — самозванец, независимо от того, что написано в User-Agent.
Прямой запрос обратно
Резолвим полученное имя обратно в IP: host spider-5-255-253-1.yandex.com. Итоговый IP обязан совпасть с исходным из лога. Совпал — робот настоящий, не совпал — подделка с настроенным PTR.
Кэшируем результат
Уникальных IP роботов на сайте обычно от нескольких сотен до нескольких тысяч. Проверять их построчно для миллиона записей бессмысленно — соберите уникальные IP, проверьте один раз, сохраните словарь «IP → верифицированный робот» и присоединяйте его к логу.
Разделяем роботов по типам
Не сваливайте всё в кучу: основной индексирующий робот, робот изображений, робот мобильной версии, робот быстрой индексации и робот рекламной системы ведут себя по-разному. Смешивать их — значит потерять смысл цифр. Отдельно выделите AdsBot и робота Метрики: они не индексируют, а проверяют.
У Google есть официальные опубликованные диапазоны IP для его краулеров в формате JSON — их можно скачать и использовать вместо DNS-проверки, это быстрее. У Яндекса такого списка нет, официальная рекомендация — именно двусторонняя DNS-проверка. Заодно на этапе верификации вы почти всегда обнаруживаете, кто ещё скребёт ваш сайт: если некий «Googlebot» с IP из чужой автономной системы делает 40 запросов в секунду по карточкам товаров — это парсер цен, и его стоит обсудить с администратором отдельно от SEO-задач.
Подготовка данных перед анализом
Сырой лог непригоден для выводов, пока его не почистить. Порядок операций, который экономит часы:
- Отсечь статику. Запросы к .css, .js, шрифтам и изображениям обычно составляют львиную долю строк. Их не выбрасывают совсем — по ним отдельно смотрят, не тратит ли робот бюджет на ресурсы, — но из основного анализа URL убирают, иначе картина утонет.
- Отсечь людей. После верификации у вас есть флаг «подтверждённый робот». Всё остальное складывайте в отдельную таблицу — она пригодится, но в анализ обхода не идёт.
- Нормализовать URL. Привести к нижнему регистру хост, решить, что делаете со слешем на конце, вынести параметры строки запроса в отдельные колонки — по каждому параметру потом считается своя статистика.
- Разметить URL по типам. Регулярными выражениями расставить категории: главная, категория каталога, карточка товара, страница фильтра, пагинация, статья блога, служебная страница, поиск по сайту. Без этой разметки лог остаётся списком строк; с ней он превращается в аналитику по разделам.
- Присоединить внешние данные. К каждому URL подтянуть: код ответа из свежего скана краулером, наличие в sitemap.xml, число входящих внутренних ссылок, визиты и конверсии из систем аналитики за тот же период.
Последний пункт превращает лог-анализ из технической забавы в бизнес-инструмент. Именно на стыке трёх таблиц — лог, скан, трафик — видно самое интересное: страницы с трафиком, которые робот перестал обходить; страницы в sitemap, которых робот не знает; страницы, которые робот долбит ежедневно, а посетителей там ноль за квартал.
Куда утекает краулинговый бюджет
Понятие краулингового бюджета становится осязаемым именно в логах: вы буквально видите, на что потрачен каждый запрос робота. И почти всегда картина оказывается хуже, чем ожидал клиент. Вот типичные утечки в порядке убывания вреда.
Фильтры, сортировки и UTM
Комбинаторика фильтров порождает бесконечное множество URL. Робот радостно уходит в него и не возвращается. Смотрите топ-параметров по числу обходов — обычно ?sort=, ?page=, ?filter[] и UTM-метки, попавшие в индекс через внешние ссылки.
Цепочки после переезда
Каждый 301 — это лишний запрос. Цепочки из 3–5 звеньев, оставшиеся после смены структуры, умножают расход. В логе они видны как серия обходов, где ответ 301 идёт валом на старые адреса.
Глубокие страницы списков
Робот честно доходит до /page/87/ с четырьмя товарами и повторяет это на каждой категории. Дублирующий контент, нулевая ценность, реальный расход бюджета.
Открытые результаты внутреннего поиска
URL вида /search/?q=... технически бесконечны. Если они не закрыты и попадают в перелинковку — робот будет генерировать себе работу сам.
Бесконечные пространства URL
Виджет календаря с ссылками «следующий месяц» уводит робота в 2087 год. Идентификаторы сессий в URL создают уникальный адрес на каждый заход.
Тяжёлый JS и лишние картинки
Если робот тратит существенную долю обходов на бандлы и превью, это отъедает от HTML. Особенно заметно на сайтах с клиентским рендерингом.
Практическая методика: постройте сводную таблицу «тип URL → число обходов роботом → число визитов из поиска» и отсортируйте по числу обходов. Верхние строки, где обходы исчисляются десятками тысяч, а визиты стремятся к нулю, — это и есть ваши утечки, отранжированные по приоритету. Дальше решается, как чинить: запрет в robots.txt, атрибут canonical, noindex, правки в фасетной навигации или пересмотр пагинации. Важно понимать разницу инструментов: robots.txt экономит бюджет (робот вообще не пойдёт), canonical и noindex бюджет не экономят — робот всё равно загрузит страницу, чтобы прочитать директиву. Если задача именно в экономии обхода, canonical её не решает. Механику дублей подробно разбирали в статье про canonical и дубли страниц.
ПОРЯДОК ВЕЛИЧИН
Ориентир, от которого мы отталкиваемся на аудитах: если доля обходов, приходящихся на коммерчески значимые URL (карточки, категории, посадочные), ниже примерно половины — сайт работает вхолостую, и оптимизация обхода даст больше, чем любые правки текстов. Если эта доля выше 70–80% — с краулингом порядок, и ресурсы стоит вкладывать в другие направления. Точные пороги зависят от типа проекта, но сама пропорция «полезное/мусор» — первая цифра, которую нужно посчитать.
Битые обходы: читаем коды ответа
Распределение кодов ответа в разрезе робота — вторая по важности таблица после утечек. Ключевое слово здесь — в динамике. Один и тот же процент 404 может означать и норму, и катастрофу, в зависимости от того, растёт он или падает.
| Код | Что означает в логе робота | Когда это проблема | Что делать |
|---|---|---|---|
| 200 | Страница отдана нормально | Если размер ответа аномально мал — шаблон сломан или отдаётся пустышка | Проверить группы 200-ответов с нетипично малым весом |
| 301 / 302 | Робот получил редирект | Устойчивая доля выше 10–15% и цепочки длиннее одного звена | Схлопнуть цепочки, заменить 302 на 301 там, где переезд постоянный |
| 304 | Не изменилось с прошлого обхода | Проблема, если приходит на страницы, которые реально менялись | Проверить корректность Last-Modified и ETag |
| 404 / 410 | Страницы нет | Растущая доля; 404 на URL из sitemap; 404 на страницах с трафиком | Найти источник ссылок, вернуть страницу или поставить 301 на релевантную |
| 403 | Доступ запрещён | Почти всегда проблема: робот забанен защитой или WAF | Добавить верифицированных роботов в исключения фильтров |
| 429 | Слишком много запросов | Всегда проблема: сервер сам режет обход | Снять лимиты для верифицированных роботов, усилить хостинг |
| 500 / 502 / 503 | Ошибка сервера | Всегда; даже кратковременные всплески снижают темп обхода | Сопоставить время всплеска с логом ошибок и деплоями |
Отдельно про 5xx — это самый недооценённый сигнал в логах. Когда робот систематически получает серверные ошибки, он снижает интенсивность обхода: с точки зрения поисковика сайт нестабилен, и лучше его лишний раз не нагружать. Проблема в том, что в панели вебмастера вы увидите усреднённую цифру, а в логе — что каждую ночь с 3:00 до 3:40, во время бэкапа, сайт отдаёт роботу 502. Такие вещи находятся только почасовой разбивкой и чинятся за один разговор с администратором.
С 404 работайте не по общему числу, а по источнику. Присоедините к списку 404-х поле реферера и данные скана: 404 по внешним ссылкам — это потерянный ссылочный вес, его закрывают 301-редиректом; 404 по внутренним ссылкам — это ваша собственная ошибка вёрстки или выгрузки; 404 по URL из sitemap.xml — грубая ошибка, которая портит доверие робота к вашей карте сайта целиком. Практическая последовательность разбора описана в материале про битые ссылки и ошибки 404, а логика склейки старых адресов — в статье про 301 редиректы.
Приоритеты обхода: что робот считает важным
Робот распределяет обходы неравномерно, и это распределение — прямая оценка вашего сайта поисковиком. Частота обхода URL коррелирует с тем, насколько важной поисковик считает страницу. Соответственно, лог даёт вам карту приоритетов, которую вы не увидите нигде больше.
Три ключевых показателя
Покрытие. Возьмите список коммерчески важных URL и посчитайте, какая доля из них получила хотя бы один обход за период. Если из 8 000 карточек товара за 60 дней робот не заходил на 2 500 — эти карточки не участвуют в поиске, и никакие правки метатегов там не помогут, пока робот до них не дойдёт. Это самая отрезвляющая метрика лог-анализа.
Частота. Постройте распределение обходов по типам страниц: сколько раз в среднем за месяц обходится главная, категория, карточка, статья блога. Нормальная картина — убывающая пирамида: главная десятки раз, категории — единицы раз в неделю, карточки — раз в 1–3 недели. Аномалия — когда служебная страница обходится в 50 раз чаще, чем целевая посадочная. Это сигнал, что структура перелинковки говорит роботу не то, что вы думаете.
Свежесть. Время от публикации до первого обхода. Если новая карточка ждёт первого визита робота 14 дней, у вас проблема с сигналами обновления: не работают sitemap с lastmod, нет ссылок с часто обходимых страниц, не используется индексирующий API. Ускорение этого показателя — прямой рост скорости попадания ассортимента в поиск, о чём подробно в материале про индексацию сайта в Яндексе.
Страницы-сироты и слепые зоны
Сопоставление лога со сканом краулера даёт две взаимно дополняющие находки. Сироты — URL, которые есть в логе (робот их обходит), но которых нет в скане (на них не ведёт ни одна внутренняя ссылка). Часто это старые посадочные, забытые лендинги, страницы из прошлой структуры. Иногда среди них обнаруживаются адреса с реальным трафиком, о которых никто в компании не помнит. Слепые зоны — наоборот: URL есть в скане и в sitemap, но в логе их нет ни разу. Робот о них либо не знает, либо считает недостойными обхода.
Лечится и то, и другое перестройкой внутренних связей: сироты либо возвращаются в структуру, либо закрываются 301-м; слепые зоны получают ссылки с часто обходимых узлов. Механики разобраны в статьях про внутреннюю перелинковку и структуру сайта. Глубина вложенности здесь работает буквально: страницы на пятом-шестом клике от главной в логах обходятся кратно реже, чем на втором-третьем, — и это видно на любом достаточно крупном проекте.
Инструменты лог-анализа
Выбор инструмента определяется объёмом данных и тем, разовая это задача или регулярный процесс.
| Инструмент | Объём | Для чего подходит | Ограничения |
|---|---|---|---|
| grep / awk / sort в консоли | До сотен МБ | Быстрые срезы: топ URL, топ IP, распределение кодов | Нет джойнов с другими данными, всё вручную |
| GoAccess | Гигабайты | Мгновенный обзорный отчёт по логу, в том числе в реальном времени | Общая веб-аналитика, не заточен под SEO-разрезы |
| Screaming Frog Log File Analyser | Миллионы строк | SEO-разрезы из коробки, верификация роботов, стык со сканом Frog | Настольное приложение, упирается в память на очень больших логах |
| Python + pandas | Десятки миллионов строк | Любая логика: своя разметка URL, джойны с аналитикой, регулярные отчёты | Нужен навык программирования |
| ClickHouse / BigQuery | Сотни миллионов и больше | Крупный e-commerce, история за годы, дашборды поверх данных | Требует инфраструктуры и участия разработчиков |
| ELK / OpenSearch | Потоковые данные | Постоянный мониторинг с алертами на всплески 5xx у роботов | Избыточен для разового аудита, дорог в поддержке |
Практический совет: не начинайте с тяжёлой инфраструктуры. На первом аудите почти всегда хватает связки «консоль для грубой чистки + pandas для анализа». Стройте ELK-дашборд только тогда, когда лог-анализ уже стал частью регулярного процесса и вы точно знаете, за какими метриками следите.
Пошаговый разбор: первый лог-анализ проекта
Запросить логи и убедиться в полноте
Период от 30 дней, все бэкенды, реальные IP клиентов (не IP прокси), формат с временем ответа и хостом. Сверьте суммарное число запросов робота с цифрами из панели вебмастера: расхождение в разы означает, что часть логов вы не получили.
Распарсить и верифицировать роботов
Разобрать строки в таблицу, собрать уникальные IP, прогнать двустороннюю DNS-проверку, промаркировать записи: настоящий Яндекс, настоящий Google, подделка, человек, прочие боты. Дальше работаем только с верифицированными.
Разметить URL по типам
Регулярками расставить категории: главная, категория, карточка, фильтр, пагинация, поиск, блог, служебное, статика. Без этой колонки дальнейшие сводные таблицы бессмысленны.
Построить карту распределения бюджета
Сводная: тип URL → доля обходов. Сразу видно, сколько процентов уходит в мусор. Это слайд, который показывают клиенту первым, — он убеждает лучше любых аргументов.
Разобрать коды ответа в динамике
По дням и по часам: доля 4xx и 5xx, всплески, длина цепочек редиректов. Совместить пики с календарём релизов и бэкапов.
Сопоставить со сканом и трафиком
Полный джойн трёх источников: лог, скан краулера, выгрузка визитов. Получить списки сирот, слепых зон, страниц с падающей частотой обхода и страниц с обходом без трафика.
Собрать список правок с приоритетами
Каждая находка превращается в задачу с оценкой: сколько обходов освободит или вернёт. Сначала то, что перераспределяет наибольшую долю бюджета при наименьших трудозатратах.
Внедрить и снять контрольный срез
Через 4–6 недель после правок повторить анализ на новом окне и сравнить: выросла ли доля полезных обходов, сократилось ли время до первого обхода новых страниц, ушли ли всплески ошибок.
Восьмой шаг пропускают чаще остальных — и зря. Лог-анализ ценен именно тем, что даёт измеримый результат: вы не рассуждаете о том, «стало ли лучше», а показываете два распределения до и после. Это редкий случай в SEO, когда эффект правки виден до того, как изменились позиции. Примеры таких перестроек обхода на крупных каталогах есть в нашем портфолио.
Что логи говорят такого, чего не скажет ничто другое
Соберём находки, ради которых этот анализ и делается.
Реакция робота на скорость. Присоедините время ответа к обходам и постройте зависимость: разделы, где сервер отвечает медленно, обходятся реже. Причинно-следственная связь прямая — поисковик ограничивает нагрузку. Ускорение медленных разделов часто даёт рост обхода без единой правки в контенте; это дополняет обычную работу над скоростью загрузки сайта тем, что показывает эффект не для пользователя, а для робота.
Мобильный робот против десктопного. Разделите обходы по типу робота. Если мобильный краулер получает другие коды ответа или другой размер ответа на тех же URL, у вас проблема с мобильной версией, которую сканер в десктопном режиме не поймает.
Реальная стоимость JavaScript. На сайтах с клиентским рендерингом в логе видно, какую долю обходов робот тратит на загрузку бандлов и обращения к API вместо HTML. Это самый убедительный аргумент в разговоре с разработкой о переходе на серверный рендеринг — тема подробно разобрана в статье про JavaScript-SEO.
Следы старой жизни сайта. Робот помнит URL годами. Если в логе стабильно идут обходы структуры, которую вы снесли при последнем редизайне, значит внешние ссылки или ваш собственный старый sitemap продолжают её питать. Это одновременно и утечка бюджета, и потерянный ссылочный вес.
Паразитный трафик. Побочный, но регулярный результат: на этапе верификации вскрываются парсеры и сканеры, создающие реальную нагрузку. Их отсечение разгружает сервер и косвенно ускоряет сайт для всех — включая робота.
Регулярность: из аудита в процесс
Разовый лог-анализ — это снимок. Ценность возникает, когда он становится регулярным. Минимальная разумная схема для среднего коммерческого проекта: полный разбор раз в квартал плюс автоматический мониторинг двух-трёх метрик еженедельно.
Что имеет смысл держать на автомониторинге:
- Доля 5xx у верифицированных роботов — алерт при превышении порога в 1% за сутки.
- Общее число обходов по дням — резкое падение означает либо проблемы с сервером, либо санкции, либо ошибку в robots.txt.
- Доля обходов на приоритетных типах URL — медленное сползание вниз сигнализирует о новой утечке.
- Появление обходов на URL-паттернах, которых быть не должно, — первый признак, что релиз породил новое пространство мусорных адресов.
Обязательные точки для внепланового анализа — любые крупные изменения: редизайн, смена CMS, переезд на новый домен, перестройка каталога, изменение системы фильтров. Логи в такие моменты — самый быстрый способ увидеть, что пошло не так, ещё до того, как это отразится на позициях и трафике. При миграции сайта мы снимаем срез до переезда и затем ежедневно первые две недели после — этот график обхода показывает проблему на 3–5 день, тогда как в аналитике она проявится через месяц. И если сайт уже упал в выдаче, логи — первое место, куда стоит смотреть: часто причина находится там, а не в текстах и ссылках.
Сам по себе лог-анализ не выводит сайт в ТОП. Он убирает препятствия: делает так, чтобы робот тратил свой ограниченный ресурс на страницы, которые приносят деньги, а не на бесконечные комбинации фильтров. Это фундамент, поверх которого работают семантика, контент и ссылки. Но без этого фундамента остальное работает вполсилы, и по опыту техническая часть SEO-аудита без логов остаётся неполной — вы описываете сайт, а не то, как с ним обращается поисковик.
Частые вопросы
Минимум 30 дней, оптимально 60. За неделю вы увидите случайный срез: робот обходит сайт волнами, и недельное окно не отражает реальный цикл. Для каталогов от 10 тысяч URL берите 60–90 дней — полный цикл обхода крупного сайта занимает недели. Если хранение настроено на 7 дней (частая ситуация по умолчанию), первым делом попросите администратора включить хранение на 90 дней и вернитесь к анализу через месяц: это одна строка в конфигурации logrotate.
Нет. User-Agent — произвольная строка, которую клиент присылает о себе сам; подделать её можно одной командой в curl. На коммерческих сайтах заметная часть «роботов» в логах оказывается парсерами конкурентов и мониторингами цен. Единственный корректный метод — двусторонняя DNS-проверка: обратный запрос по IP должен дать имя на официальном домене поисковика, а прямой резолв этого имени должен вернуть исходный IP. У Google дополнительно есть опубликованный список диапазонов IP.
Панели дают агрегаты: суммарное число загруженных страниц, распределение по кодам, общая динамика. Лог даёт факты по каждому URL: кто, когда, что запросил, с каким кодом и за сколько миллисекунд. Только в логе можно сказать «страницы фильтров съели 38% обходов за месяц» или «эти 2 500 карточек робот не посещал ни разу за 60 дней». Панели показывают симптомы, логи — причины. Это дополняющие, а не заменяющие друг друга источники.
Попросить администратора пробросить реальный IP клиента в заголовок (X-Forwarded-For, CF-Connecting-IP или аналог вашего провайдера) и добавить это поле в формат лога. Без реального IP верификация робота невозможна. Второй вариант — снимать логи с самого CDN: у большинства провайдеров есть выгрузка логов уровня фронтенда. Учитывайте, что при агрессивном кэшировании часть запросов робота вообще не доходит до бэкенда, и логи бэкенда покажут неполную картину.
Если задача именно сэкономить бюджет обхода — только robots.txt: робот не пойдёт по запрещённому URL и не потратит запрос. Canonical и noindex бюджет не экономят: чтобы прочитать директиву, робот обязан сначала загрузить страницу. Их роль — управлять индексом, а не обходом. Практическая схема: бесполезные комбинации фильтров и сортировки закрываем в robots.txt, ценные посадочные комбинации оставляем открытыми и оптимизируем как самостоятельные страницы, а технические варианты одного и того же контента склеиваем через canonical.
Критичнее, чем кажется. Получая серверные ошибки, поисковик снижает интенсивность обхода — с его точки зрения сайт нестабилен и его лучше не нагружать. Восстановление темпа занимает время и после того, как ошибки ушли. Особенно опасны регулярные всплески: например, ежедневные 502 в окно бэкапа. В панели вебмастера это размажется в незаметную усреднённую долю, а в логе с почасовой разбивкой видно сразу — и чинится это одним разговором с администратором.
Полноценный регулярный процесс — избыточен: на таком объёме робот, как правило, успевает обойти всё, и краулинговый бюджет не является узким местом. Но разовый разбор полезен и здесь: он вскрывает 404 по внешним ссылкам, серверные ошибки, следы старой структуры и парсеров. И есть исключение: небольшой сайт с открытыми фильтрами или календарём может генерировать десятки тысяч мусорных URL — тогда проблема бюджета возникает и на 300 страницах, и увидеть это можно только в логах.
По трём метрикам на сопоставимых окнах до и после (4–6 недель каждое). Первая — доля обходов, приходящаяся на коммерчески значимые типы URL: должна вырасти. Вторая — покрытие: доля важных URL, получивших хотя бы один обход за период. Третья — время от публикации до первого обхода новой страницы: должно сократиться. Позиции и трафик подтянутся позже, но эти три цифры показывают эффект раньше и отвечают на вопрос, сработала правка или нет, не дожидаясь переиндексации.
Разберём логи вашего сайта и вернём роботу правильные приоритеты
Выгрузим и проанализируем логи, верифицируем роботов, найдём утечки краулингового бюджета, битые обходы и слепые зоны. Соберём список правок с приоритетами и доведём его до внедрения. Прозрачный договор, отчёты каждую неделю.
- Пакет «Старт» от 55 000 ₽/мес
- Пакет «Стандарт» 75 000 ₽/мес
- Пакет «Премиум» 95 000 ₽/мес
- Бесплатный аудит и прогноз
- Договор с гарантией результата
- Отчёты каждую неделю
Комментарии (14)
Кирилл
Фраза про то, что сканер показывает, что робот может обойти, а лог — что он обошёл, стоит того, чтобы повесить её над столом. До этого я честно верил отчётам Frog как истине.
Марина_К
Запросили логи у хостера, а там ротация на 7 дней, как вы и написали. Админ включил хранение на 90 дней одной строкой в logrotate, ждём месяц. Обидно, что потеряли квартал, но хоть теперь будет с чем работать.
AdminSEO Мастер
Марина, это самая частая история на первом аудите, вы не одиноки. Пока копится окно, попросите админа сразу добавить в log_format $request_time и $host — потом не придётся ждать ещё месяц ради этих двух полей.
Дмитрий
Про двустороннюю DNS-проверку всё верно, но на практике на миллионе строк это ад, пока не сообразишь собрать уникальные IP в словарь. Хорошо, что вы про кэширование написали отдельным шагом.
Ольга П.
У нас сайт за Cloudflare и в логах бэкенда одни IP прокси. Если попросить пробросить CF-Connecting-IP, но при этом стоит агрессивное кэширование — я всё равно увижу неполную картину? Или проброса достаточно?
AdminSEO Мастер
Ольга, проброс решает только вопрос верификации, но не полноты: всё, что отдалось из кэша, до бэкенда не дойдёт и в логе не появится. При агрессивном кэшировании берите выгрузку логов с самого CDN — она покажет фронтенд-слой целиком. Если хотите, посмотрим ваш случай на бесплатном аудите.
vladimir77
Спорно про порог в половину обходов на коммерческие URL. У нас огромный блог, он тянет на себя обход и продаёт не хуже карточек. Так что «мусор» — понятие относительное.
AdminSEO Мастер
Владимир, справедливо — в статье речь про коммерчески значимые URL, а не про карточки как таковые. Если блог приводит заявки, он в вашем случае как раз попадает в «полезное», и порог считается с его учётом. Мусор — это то, что не приносит ни трафика, ни денег: сортировки, UTM в индексе, глубокая пагинация.
Ирина
Метрика «покрытие» действительно отрезвляет. Посчитала за 60 дней — треть карточек робот не видел ни разу. А я до этого месяц переписывала на них тайтлы.
Сергей_бизнес
Не спец, владелец магазина. Подрядчик третий месяц шлёт отчёты про метатеги. Показал им ваш пункт про сводную «тип URL → обходы → визиты» — сказали, что логи им хостер не даёт. Это отмазка?
AdminSEO Мастер
Сергей, чаще всего это вопрос настойчивости, а не технической невозможности: на виртуальном хостинге логи обычно лежат в папке logs в вашем аккаунте либо отдаются по тикету в поддержку. Напишите в поддержку сами от имени владельца — вопрос решается за пару дней.
Анна Т.
Спасибо за таблицу с инструментами. Начала с grep и awk, как вы советуете, и не полезла сразу в ELK — сэкономила себе неделю.
Максим
История про 502 в окно бэкапа — это прямо про нас. Полгода не могли понять, почему обход проседает волнами. Разбивка по часам всё показала за вечер, чинили полчаса вместе с админом.
Тимур
А что если у нас три бэкенда и логи с них склеиваются с разными таймзонами? Часть пишет UTC, часть локальное. Приводить всё к одной зоне на этапе парсинга или можно забить, если смотрю только суммы?
AdminSEO Мастер
Тимур, приводите обязательно и сразу при парсинге. На суммах за месяц вы разницы не заметите, но вся почасовая аналитика поедет: всплески 5xx размажутся, и вы не увидите ни бэкапов, ни деплоев. Приведите к одной зоне и зафиксируйте её в конфигах всех трёх серверов.
Женя_фриланс
Нашёл в логах кучу обходов раздела, который снесли при редизайне ещё в позапрошлом году. Робот реально ничего не забывает.
Наталья_В
Пункт про то, что canonical и noindex не экономят бюджет, надо выделять жирным в начале статьи. Я года два жила с уверенностью, что каноникал спасает от лишних обходов. Оказалось, робот всё равно грузит страницу, чтобы прочитать директиву.
Роман Ш.
Восьмой шаг с контрольным срезом — самое ценное. Наконец-то есть что показывать клиенту до того, как позиции поедут.
Полина
Сайт небольшой, страниц двести с чем-то, но с открытыми фильтрами. Про календарь, уводящий робота в 2087 год, посмеялась, а потом проверила свой виджет бронирования и перестала смеяться.