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

Яндекс.Вебмастер показывает вам не то, что происходит с сайтом, а то, что Яндекс счёл нужным вам показать: агрегированные цифры, усреднённые за сутки, с задержкой в несколько дней и без объяснения причин. Логи сервера показывают факты: конкретный робот, конкретный URL, конкретная секунда, конкретный код ответа, конкретное время генерации страницы. Это единственный источник данных о поведении поискового робота, который вы контролируете полностью и который никто не «интерпретирует» за вас. За 20 лет практики я не видел ни одного крупного сайта, где анализ логов не вскрыл бы минимум три проблемы, невидимые в интерфейсах Вебмастера. В этой статье — как читать логи, как отличить настоящего робота от подделки, что искать и как превращать находки в конкретные технические задачи.

Почему Вебмастер — это выводы, а логи — это факты

Раздел «Индексирование → Статистика обхода» в Яндекс.Вебмастере — полезный инструмент, но у него есть четыре принципиальных ограничения, о которых редко говорят.

Первое: агрегация. Вебмастер показывает количество загруженных страниц за день и распределение по кодам ответа. Он не показывает, в каком порядке робот ходил по сайту, сколько времени провёл на каждом типе страниц, какие URL обошёл 40 раз, а какие — ни разу за полгода. Сумма скрывает распределение, а всё интересное живёт именно в распределении.

Второе: выборка. Список URL в статистике обхода ограничен. На сайте с 200 тысячами страниц вы увидите несколько тысяч примеров — и не факт, что репрезентативных. В логах у вас все запросы до единого.

Третье: задержка. Данные приезжают с лагом в 2–5 дней. Если вы выкатили релиз в понедельник и сломали ответ сервера на карточках товара, вы узнаете об этом в четверг — робот к этому моменту уже успеет выбросить часть страниц из индекса. В логах вы видите проблему через 30 секунд после её появления.

Четвёртое: только Яндекс. Вебмастер знает про YandexBot. Логи знают про всех: Googlebot, YandexBot, Bingbot, Ahrefs, Semrush, MJ12bot, GPTBot, PetalBot и полсотни парсеров, которые вместе с ними едят ваш процессор и канал.

Ни один сервис SEO-аудита не заменяет логи, потому что краулер сервиса ходит по сайту так, как ему сказали вы, а не так, как ходит робот Яндекса. Краулер — это модель. Лог — это реальность.

Что такое access.log и где он лежит

Веб-сервер записывает каждый входящий HTTP-запрос отдельной строкой в текстовый файл. Это и есть access-лог (журнал доступа). Есть ещё error.log — журнал ошибок сервера, он тоже пригодится, но основная работа идёт с access-логом.

Типовые места, где его искать:

• Nginx: /var/log/nginx/access.log, часто с ротацией — access.log.1, access.log.2.gz и далее.
• Apache: /var/log/apache2/access.log (Debian/Ubuntu) или /var/log/httpd/access_log (CentOS/RHEL).
• Хостинг с ISPmanager/cPanel: папка logs в домашнем каталоге пользователя, обычно ~/logs/domain.ru.access.log. Скачивается по FTP.
• Битрикс на «облаке»: раздел статистики в панели хостера или тот же /var/log/nginx/, если у вас VPS.

Три вещи, которые надо проверить в первую очередь.

Глубина хранения. По умолчанию logrotate часто держит 7–14 дней. Для SEO-анализа этого мало: сезонность обхода, редкие разделы и медленные страницы видны на горизонте от месяца. Просите админа поднять хранение минимум до 90 дней и включить сжатие — гигабайт текста жмётся в 50–80 мегабайт, это копейки.

Наличие CDN или обратного прокси. Если перед сайтом стоит Cloudflare, Qrator, Selectel CDN или обычный балансировщик, в логах бэкенда во всех строках будет один и тот же IP — адрес прокси. Тогда реальный адрес клиента передаётся в заголовке X-Forwarded-For или CF-Connecting-IP, и его нужно явно добавить в формат лога. Без этого верификация робота невозможна в принципе.

Пишутся ли логи вообще. Смешно, но на каждом пятом проекте, куда мы приходим, access-лог отключён «чтобы не забивать диск» или пишется в /dev/null. Это первое, что надо чинить.

Из чего состоит строка лога

Стандартный формат Nginx (combined) выглядит так:

66.249.66.1 - - [12/Jul/2026:14:22:07 +0300] "GET /catalog/nasosy/page/7/?sort=price HTTP/1.1" 200 48213 "-" "Mozilla/5.0 (compatible; YandexBot/3.0; +http://yandex.com/bots)" 0.842

Разберём по полям — каждое из них имеет прямой SEO-смысл.

1. IP-адрес клиента. Основа для верификации робота. Без него всё остальное — гадание.
2. Дата и время с точностью до секунды. Позволяет строить графики частоты обхода, ловить всплески и провалы, сопоставлять падения с релизами.
3. Метод и URL с query-строкой. Самое ценное поле. Именно здесь вы увидите, что робот 3000 раз в сутки заходит на ?sort=price&filter=color-red.
4. Код ответа. 200, 301, 404, 500 — то, что робот получил на самом деле, а не то, что вы видите в браузере из-под своего IP.
5. Размер ответа в байтах. Резко упавший размер при коде 200 — верный признак «мягкой» ошибки: страница отдаёт 200, но контента внутри нет.
6. Referer. Для роботов обычно пустой, для людей — источник перехода.
7. User-Agent. Строка, которой клиент представляется. Подделывается за две секунды — верить ей нельзя.
8. Время генерации ответа ($request_time). В стандартном combined-формате его нет — и это главная причина, почему формат лога надо расширять.

Минимальная доработка формата в Nginx, которую я прошу сделать на каждом проекте: добавить $request_time, $upstream_response_time, $http_x_forwarded_for и $host. Последнее критично для мультидоменных проектов — иначе поддомены сольются в кашу.

Главная ловушка: 60% «роботов Яндекса» — не роботы Яндекса

User-Agent — это просто заголовок HTTP-запроса. Любой парсер, скрапер или конкурент может представиться YandexBot/3.0, чтобы обойти защиту от ботов и спокойно выкачать вашу базу товаров. Если вы фильтруете логи по подстроке «YandexBot» и делаете выводы — вы анализируете поведение чужих парсеров, а не поискового робота.

По нашим замерам на интернет-магазинах доля поддельных запросов среди «яндексовских» User-Agent колеблется от 15% до 70%. На одном проекте по продаже сантехники 68% трафика «робота Яндекса» шло с двух хостингов в Нидерландах — это был конкурент, снимавший цены каждые 20 минут.

Проверка через обратный DNS: единственный надёжный способ

Яндекс официально поддерживает верификацию по методу обратного, а затем прямого DNS-запроса. Алгоритм состоит из двух шагов, и оба обязательны.

1. Обратный запрос (PTR). Берём IP из лога и спрашиваем у DNS, какое доменное имя ему соответствует. Настоящий робот Яндекса вернёт имя в зоне yandex.ru, yandex.net или yandex.com — например, spider-5-255-253-11.yandex.com.
2. Прямой запрос (A). Берём полученное имя и спрашиваем, какой IP ему соответствует. Он должен совпасть с исходным IP из лога.

Второй шаг нужен потому, что PTR-запись настраивает владелец IP-адреса, и теоретически её можно подделать. Совпадение в обе стороны подделать нельзя.

Руками это делается так:

host 5.255.253.11 → 11.253.255.5.in-addr.arpa domain name pointer spider-5-255-253-11.yandex.com

host spider-5-255-253-11.yandex.com → spider-5-255-253-11.yandex.com has address 5.255.253.11

Совпало — настоящий. Не совпало или PTR ведёт куда-то в hosted-by-ovh.net — самозванец.

Для Google логика идентичная, только зоны googlebot.com и google.com. Проверять по спискам IP-подсетей я не рекомендую: Яндекс их официально не публикует и не гарантирует, списки из блогов устаревают за месяцы.

На больших логах проверять каждый IP по отдельности бессмысленно — уникальных адресов у робота обычно несколько сотен. Соберите список уникальных IP, прогоните через DNS один раз, закешируйте результат и дальше размечайте лог по этому справочнику. Обновлять справочник достаточно раз в месяц.

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

1. Какие страницы робот обходит часто, редко и никогда

Это фундамент. Выгружаете все запросы верифицированного YandexBot за 30 дней, группируете по URL, считаете количество обращений. Дальше — самое важное: сопоставляете этот список с картой сайта или выгрузкой всех реальных URL из CMS.

Три группы находок:

• «Чёрные дыры» — страницы, которые есть в sitemap.xml, но которых нет в логах вообще. Робот про них не знает или до них не доходит. Причина почти всегда одна: на них не ведёт ни одна внутренняя ссылка с достаточно «близкой» к главной страницы. Sitemap не заменяет ссылки — он лишь подсказка.
• «Пылесосы» — URL с аномально высокой частотой обхода, обычно служебные или параметрические. Они съедают бюджет, который должен идти на коммерческие страницы.
• «Забытые» — важные разделы с обходом раз в 2–3 месяца. Верный признак, что страница считается роботом малоценной или лежит слишком глубоко.

Практический приём: постройте распределение частоты обхода по типам страниц (главная / категории / карточки / фильтры / блог / служебное) и посчитайте долю бюджета на каждый тип. На здоровом интернет-магазине на карточки и категории должно уходить 70–85% обхода. Если у вас 40% — вы нашли главную техническую проблему проекта.

2. Какие коды ответа получает робот

Вы заходите на сайт из браузера и видите 200. Робот в это же время может получать 503 — потому что защита от ботов на хостинге режет частые запросы, или потому что кеш работает только для авторизованных, или потому что для мобильного User-Agent отдаётся другая ветка кода.

Что критично:

• 5xx для робота. Любая доля выше 1% — авария. Яндекс при систематических 5xx снижает частоту обхода, а затем начинает выбрасывать страницы из индекса. Особенно опасны 502 и 504 — они означают, что бэкенд не успел ответить.
• 404 в больших объёмах. Смотрите, откуда робот берёт эти URL. Обычно это битые внутренние ссылки, старые адреса из индекса или мусор из sitemap. Каждый 404 — это потраченный впустую запрос.
• 403 для робота. Классика: WAF или модуль защиты хостинга блокирует «подозрительную активность», не отличая робота от парсера. Сайт при этом для людей работает идеально.
• 304 Not Modified. А вот это хорошо. Корректно настроенные заголовки Last-Modified и ETag позволяют роботу не скачивать неизменившиеся страницы заново — это прямая экономия бюджета. Если у вас 304-х ноль, вы теряете ресурс.
• «Мягкие» 404. Страница отдаёт 200, но контента нет. Ловятся по размеру ответа: если типовая карточка весит 60 КБ, а часть URL отдаёт 200 с размером 4 КБ — это пустышки.

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

3. Куда утекает краулинговый бюджет

Краулинговый бюджет — это количество запросов, которое робот готов потратить на ваш сайт за единицу времени. Он не бесконечен и зависит от авторитетности домена и скорости ответа. Каждый запрос к мусорному URL — это запрос, который не достался вашей новой категории.

Главные пожиратели бюджета, которые вылезают в логах:

• Фильтры и сортировки. ?sort=price&order=asc, ?view=grid, ?brand=1&brand=2&color=5. Комбинаторика фильтров генерирует миллионы URL. На одном проекте по автозапчастям робот тратил 71% обхода на фильтрационные комбинации, из которых в индекс попадали единицы.
• Пагинация без границ. Особенно когда пагинация комбинируется с фильтрами: /catalog/?filter=x&page=248. Проверьте, что происходит при ?page=99999 — если отдаётся 200 с пустым листингом вместо 404, робот будет ходить туда вечно.
• UTM-метки и метки рекламных систем. ?utm_source=yandex&utm_campaign=... в индексе — это дубли. Робот находит их по ссылкам из соцсетей и внешних площадок.
• Идентификаторы сессий. PHPSESSID в URL — привет из 2008-го, но на Битриксе до сих пор встречается.
• Служебные и технические URL. /ajax/, /bitrix/, /wp-json/, /local/, эндпоинты корзины и сравнения.
• Дубли со слешем и без, с index.php и без. Каждая пара — двойной расход.
• Календари и архивы. Бесконечные /events/2031/07/ — робот честно уходит в 2040 год.

Считается это просто: берёте все URL робота, помечаете «полезные» (те, что должны быть в индексе) и «мусорные», считаете доли. Цифра доли мусора — самый убедительный аргумент в разговоре с разработчиками и руководством. «У нас проблема с фильтрами» звучит слабо. «Робот тратит 71% ресурса на страницы, которые никогда не будут в индексе, — вот почему новые товары индексируются три недели» звучит совсем иначе.

Если у вас интернет-магазин с развитой фильтрацией, работа с параметрическими URL — отдельная большая задача; она же обычно даёт самый быстрый эффект в продвижении интернет-магазинов.

4. Насколько быстро сервер отвечает именно роботу

Здесь $request_time в логе становится золотом. Скорость ответа для робота и скорость для пользователя — это разные метрики, и они регулярно расходятся в разы.

Почему так:

• Робот ходит по «холодным» страницам — тем, которых нет в кеше, потому что живые люди их не открывали неделями. Пользователь попадает на популярные, кешированные.
• Робот не выполняет JavaScript при первом проходе и не грузит статику — он получает голый HTML. Значит, его время ответа = время работы бэкенда. Это чистый показатель здоровья сервера.
• Робот ходит ночью, когда крутятся выгрузки, бэкапы и импорт прайсов. Именно поэтому на многих сайтах медиана времени ответа для робота в 4–6 раз хуже, чем дневная для людей.

Что считать: медиану и 95-й перцентиль $request_time по запросам верифицированного робота, в разрезе по часам суток и по типам страниц. Ориентир: медиана до 300 мс — норма, 300–800 мс — есть над чем работать, выше 1 секунды — Яндекс начнёт снижать частоту обхода. При времени ответа в 2–3 секунды сайт с 50 тысячами страниц физически не может быть обойдён целиком.

Отдельно ловите 95-й перцентиль: если медиана 200 мс, а 95-й — 8 секунд, значит есть узкая группа тяжёлых страниц (обычно глубокая пагинация или фильтры с большой выборкой), которые роняют весь обход. Как скорость связана с ранжированием напрямую, разбираем в материале о влиянии скорости загрузки на SEO.

5. Зацикленные и цепочечные редиректы

Редирект-цепочка в логах видна как последовательность запросов с одного IP за доли секунды: /tovar → 301 → /tovar/ → 301 → /catalog/tovar/ → 301 → https://site.ru/catalog/tovar/ → 200. Четыре запроса вместо одного — четырёхкратный расход бюджета на одну страницу.

Настоящие циклы (A → B → A) выглядят как повторяющийся паттерн из 301-х, который не заканчивается 200-м. Робот пройдёт 3–5 шагов и бросит — страница не будет проиндексирована никогда.

Типовые источники цепочек:

• Слой «http → https» + слой «www → без www» + слой «слеш» настроены как три независимых правила, а не как одно.
• Старые правила после переезда, наложенные на новые правила после следующего переезда.
• Редирект на мобильную версию, потом обратно на десктопную по User-Agent.
• Пагинация: ?page=1 → редирект на канонический URL категории, а в листинге ссылка снова ведёт на ?page=1.

Чинится просто: все внутренние ссылки должны вести на конечный URL, а правила редиректов сводятся в один слой, отдающий финальный адрес за один шаг. После правки логи покажут результат за сутки.

6. Что робот видит вместо контента

Сопоставьте размер ответа для робота с размером той же страницы для обычного браузера. Если карточка товара для человека — 90 КБ, а для YandexBot — 12 КБ, значит контент подгружается JavaScript'ом и робот его не видит. В Вебмастере это будет выглядеть как «страница в индексе, но не ранжируется» — и вы будете месяцами переписывать тексты, которых робот вообще не получает.

7. Как робот реагирует на изменения

Логи — это ещё и обратная связь. Закрыли фильтры в robots.txt — через 2–4 дня в логах должно упасть количество запросов к ним. Не упало — значит директива написана неправильно. Ускорили бэкенд — через неделю должна вырасти суммарная частота обхода. Не выросла — либо ускорение мнимое, либо ограничение не в скорости, а в авторитетности домена.

Инструменты анализа

Командная строка. Для быстрой диагностики на 90% задач хватает grep, awk, sort и uniq. Топ-50 URL робота за месяц — одна строка. Распределение кодов ответа — одна строка. Это бесплатно, работает на любых объёмах и не требует ничего скачивать с сервера.

Screaming Frog Log File Analyser. Отдельный продукт, не путать с краулером. Умеет верифицировать роботов, строит отчёты по частоте обхода, кодам, скорости, и главное — склеивает данные лога с выгрузкой краулера. Именно эта склейка даёт лучшие инсайты: «страницы, которые есть в структуре, но которых нет в логах» и «страницы в логах, которых нет в структуре» (то есть орфаны и мусор).

GoAccess. Бесплатный, работает в реальном времени прямо в терминале, рисует HTML-дашборд. Хорош для мониторинга, слабее для глубокого SEO-разбора.

Excel или Google Таблицы. Работают до сотни тысяч строк. Для небольшого сайта за неделю — вполне рабочий вариант.

ELK / OpenSearch, ClickHouse, Grafana Loki. Для проектов от миллиона строк в сутки. Дороже в настройке, но дают постоянный мониторинг и алерты: «доля 5xx для YandexBot превысила 2%» приходит в Telegram через минуту, а не обнаруживается через месяц.

Python + pandas. Мой рабочий выбор для регулярных разборов: парсинг, верификация IP с кешем, классификация URL по типам, сводные таблицы. Один раз пишется скрипт под проект — дальше отчёт собирается за минуту.

Практический совет по объёму: не тащите гигабайты с сервера целиком. Отфильтруйте на сервере строки только с ботами в User-Agent — файл сожмётся в 10–30 раз, и дальше работайте с ним локально.

Как превратить находки в задачи

Анализ, который не заканчивается тикетами в трекере, — это развлечение. Вот прямое соответствие «находка → действие».

robots.txt

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

• Disallow: /*?sort=, Disallow: /*?utm_, Disallow: /*PHPSESSID=
• Служебные разделы, корзина, сравнение, личный кабинет, AJAX-эндпоинты.
• Для Яндекса — директива Clean-param: она аккуратнее Disallow, потому что склеивает параметрический URL с основным, не теряя его сигналы. Clean-param: utm_source&utm_medium&sort&view.

Важно понимать границу: robots.txt управляет обходом, а не индексом. Закрытая в robots страница, на которую ведут ссылки, может остаться в выдаче — просто без описания. Если задача — убрать из индекса, нужен noindex в meta или X-Robots-Tag в заголовке, и страница при этом должна оставаться открытой для обхода, иначе робот не увидит директиву. Это самая частая ошибка: закрыть в robots и удивляться, почему страница висит в индексе годами.

Редиректы

Все цепочки схлопываем в один шаг. Внутренние ссылки правим на конечные URL — это разовая работа по шаблонам, но она снимает десятки процентов лишних запросов. Массовые 404, на которые робот ходит из старого индекса, закрываем 301-ми на релевантные страницы, а не на главную скопом: редирект всего на главную Яндекс расценивает как soft-404 и просто игнорирует.

Канонические

rel="canonical" — для случаев, когда страница должна быть доступна и обходима, но не должна ранжироваться отдельно: сортировки, представления списка, версии для печати. Проверяйте в логах, что после установки canonical частота обхода неканонических версий падает — если не падает, значит canonical проставлен неправильно (например, указывает сам на себя или на URL, отдающий 301).

Структура и перелинковка

Если целый класс страниц не появляется в логах — это не проблема индексации, это проблема архитектуры. Робот не находит их, потому что до них нет пути. Лечится сокращением вложенности (правило трёх кликов от главной), хабовыми страницами, блоками «похожие товары» и корректными хлебными крошками. Мы подробно разбирали это в материалах про структуру сайта для SEO и внутреннюю перелинковку — обе задачи напрямую управляют тем, куда пойдёт краулинговый бюджет.

Инфраструктура

Медленный ответ для робота — это задача не сеошнику, а админу и бэкендеру: кеширование HTML, индексы в БД, вынос тяжёлых выгрузок из ночного окна, ограничение глубины пагинации, отключение генерации бесполезных комбинаций фильтров на уровне кода. Такие работы обычно попадают в блок техподдержки и доработки сайта, и без них остальное SEO упирается в потолок.

Приоритизация

Порядок действий, отработанный на десятках проектов:

1. Сначала 5xx и 403 для робота — это прямая потеря индекса.
2. Затем мусорный бюджет — быстрый выигрыш, часто даёт кратный рост частоты обхода полезных страниц за 2–3 недели.
3. Затем скорость ответа для бота.
4. Затем редирект-цепочки.
5. В последнюю очередь — «чёрные дыры» и структура: это самая долгая работа, но и самая доходная.

Как часто это делать

Полный разбор — раз в квартал и обязательно после любого крупного релиза, переезда на новый домен, смены CMS или хостинга. Точечная проверка — раз в месяц: доля кодов ответа, медиана времени ответа для бота, топ-20 URL по частоте обхода. Постоянный автоматический мониторинг с алертом на рост 5xx для верифицированного YandexBot — обязателен для любого проекта, где SEO приносит деньги. Это 20 строк кода и один вебхук, а спасает от катастроф, которые в Вебмастере проявятся на четвёртый день.

Связывайте данные логов с Яндекс.Метрикой и Вебмастером: логи говорят, что робот получил, Вебмастер — что Яндекс решил, Метрика — что из этого принесло трафик и деньги. Три источника вместе дают полную картину, по отдельности — только фрагменты.

Три ошибки, которые обесценивают весь анализ

Первая — анализ без верификации робота. Вы делаете выводы о поведении Яндекса на данных чужих парсеров. Всё, что построено дальше, — мусор.

Вторая — слишком короткое окно. Неделя логов покажет только частые страницы. Разделы с обходом раз в 40 дней в такое окно не попадут, и вы решите, что их «не обходят вообще», хотя всё в порядке. Минимум — 30 дней, лучше 90.

Третья — цифры без сопоставления со структурой. «Робот сделал 400 тысяч запросов» — бессмысленно. «Робот сделал 400 тысяч запросов, из них 280 тысяч — к фильтрам, закрытым от индексации, а 6 тысяч карточек товара не получили ни одного запроса за месяц» — это уже диагноз с готовым планом лечения.

Вывод

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

Честно скажу: это не та задача, которую решают между делом. Она требует доступа к серверу, понимания инфраструктуры, навыка работы с большими данными и — главное — умения превратить таблицу на 400 тысяч строк в короткий список приоритетных задач для разработчиков. Именно связка «технический аудит логов → задачи в разработку → контроль результата по тем же логам» отличает системную внутреннюю оптимизацию от косметических правок.

В SEO ПРОГРЕСС анализ логов входит в базовый технический аудит на старте работ и повторяется ежеквартально — с автоматическим мониторингом ответов сервера для верифицированных роботов между итерациями. Результаты этого подхода видны в наших кейсах: на нескольких проектах наведение порядка в краулинговом бюджете дало рост поискового трафика на 40–90% без единой новой статьи — просто потому, что робот наконец добрался до того, что уже было на сайте. Если хотите узнать, что на самом деле видит на вашем сайте робот Яндекса, — напишите нам, посмотрим ваши логи и покажем, куда уходит бюджет обхода.