Верить одному User-Agent
Любой бот может притвориться поисковым.
Практическое SEO · логи
Анализ серверных логов для SEO: что реально запрашивает поисковый робот
Краулер показывает, как сайт можно обойти из текущей структуры, а серверные логи — что поисковый робот действительно запрашивал. По логам видно частоту обхода, HTTP-коды, старые URL, параметры, 5xx и разделы, на которые уходит большая часть роботных запросов.
Основа
Лог — фактическая запись запроса к серверу
В access log обычно есть время, URL, метод, HTTP-код, user-agent, объём ответа и иногда время обработки. Это позволяет анализировать не модель поведения робота, а реальные обращения к сайту.
Логи особенно полезны после миграции, при проблемах индексации и на больших каталогах: видно, продолжает ли робот запрашивать старые URL, как часто встречает 404/5xx и доходит ли до новых разделов.
Краулер отвечает «что доступно по ссылкам сейчас», а лог — «что сервер реально отдавал роботам в выбранный период».
Шаг 1
User-Agent недостаточно: подозрительные запросы нужно верифицировать
Любой скрипт может написать в User-Agent слово YandexBot. Для серьёзного анализа проверяют IP через обратное и прямое DNS-разрешение по правилам поисковой системы или используют уже верифицированные данные инфраструктуры.
Это особенно важно при оценке нагрузки: бот-имитатор может создавать тысячи запросов и искажать выводы о реальном поисковом обходе.
Не блокируем IP только по строке User-Agent: сначала подтверждаем, кто делает запросы.
Шаг 2
Сырые миллионы строк превращаем в группы шаблонов
Отдельная строка лога редко полезна. Группируем URL по разделам и паттернам: /catalog/, /product/, параметры, поиск, API, изображения, старые пути. Затем считаем запросы и коды по каждой группе.
Так становится видно, что 40% роботных запросов уходят на ?sort=, или что новый раздел почти не посещается, хотя находится в Sitemap.
| Группа | Что считать | Что может означать |
|---|---|---|
| Канонические 200 | Частота и свежесть | Нормальный полезный обход |
| 301/302 | Доля и источники | Старые внутренние или внешние маршруты |
| 404/410 | Частые URL | Битые ссылки или исторический хвост |
| 5xx | Время и шаблон | Проблема приложения/инфраструктуры |
| GET-параметры | Комбинации и объём | Фасеты или технический мусор |
Шаг 3
Коды в логах показывают стабильность во времени
Ручная проверка сейчас может дать 200, хотя ночью сервер регулярно отвечал 502. Логи показывают такие периодические проблемы и помогают связать их с нагрузкой, deploy или конкретным шаблоном.
Смотрим не только количество ошибок, но и URL: 100 ошибок одного health-check и 100 ошибок карточек товаров имеют разный приоритет.
Шаг 4
После миграции логи показывают, какие старые адреса всё ещё востребованы
Робот может месяцами и дольше возвращаться к историческим URL из своей базы и внешних ссылок. Если они имеют новую релевантную версию, проверяем постоянный редирект и конечный код.
Частые запросы к старому адресу также помогают обнаружить забытые внутренние ссылки или Sitemap, который не был очищен.
Шаг 5
Логи быстро показывают бесконечные пространства параметров
Сортировки, фильтры и tracking-параметры удобно группировать по именам query-string. Если робот активно перебирает комбинации, ищем источник href и правила генерации.
Один только canonical не всегда уменьшает сам обход: технические URL могут продолжать обнаруживаться и загружаться. Поэтому анализируем архитектуру целиком.
Шаг 6
Если лог содержит request time, можно найти медленные шаблоны для робота
Сравниваем медиану и хвост времени ответа по группам URL. Категории могут отвечать быстро, а тяжёлые фильтры — в десять раз медленнее, создавая нагрузку и таймауты.
Важно смотреть распределение, а не только среднее: редкие 20-секундные запросы способны указывать на блокировки базы или внешнего API.
Шаг 7
Логи содержат технические и иногда пользовательские данные
В query-string могут случайно попадать email, токены или идентификаторы. Перед передачей логов подрядчику удаляем или маскируем чувствительные данные и ограничиваем срок хранения.
Для SEO обычно достаточно URL, времени, кода, user-agent, IP для верификации робота и времени ответа; содержимое POST и персональные данные анализу не нужны.
Логи — мощный диагностический источник, но обращаться с ними нужно как с данными инфраструктуры, а не как с безобидным текстовым файлом.
Шаг 8
Сравниваем два периода до и после исправлений
Берём сопоставимые интервалы, очищаем роботов, группируем URL и считаем метрики. После исправления фильтров или редиректов повторяем тот же отчёт.
Так можно доказать, что доля обхода служебных URL снизилась, ошибки 5xx исчезли, а новые страницы стали получать больше роботных запросов.
Частые ошибки
Что обычно ломает эту часть SEO
Смотреть строки по одной
Без группировки шаблонов невозможно увидеть масштаб.
Игнорировать время ответа
Периодические таймауты теряются за успешными запросами.
Передавать сырые логи без очистки
В параметрах могут находиться чувствительные данные.
Практический сценарий
После переноса робот продолжает запрашивать старую CMS
Сайт переехал полгода назад, но в логах ежедневно видны тысячи запросов к /index.php?route=... и старым категориям. Часть отвечает 301, часть 404, а несколько старых внутренних ссылок всё ещё присутствуют в футере.
Группируем старые паттерны: полезные адреса перенаправляем напрямую на новые, внутренние источники исправляем, бессмысленные параметры не пытаемся спасать редиректами. Повторный отчёт показывает, какой исторический хвост действительно уменьшается.
| Паттерн | Запросов/день | Действие |
|---|---|---|
| Старые категории | 1200 | Точный 301 + убрать внутренние ссылки |
| Старые карточки с аналогом | 600 | 301 на соответствие |
| Случайные параметры | 3000 | Не генерировать/ограничить источник |
| 5xx новой CMS | 80 | Отдельная серверная диагностика |
Чек-лист
SEO-проверка серверных логов
- Определить период: Взять достаточно данных для типичного поведения сайта.
- Отфильтровать поисковых роботов: Верифицировать источники, а не верить только User-Agent.
- Нормализовать URL: Сгруппировать пути и параметры.
- Посчитать HTTP-коды: 200, 3xx, 4xx и 5xx по группам.
- Найти старые URL: Проверить редиректы и источники обнаружения.
- Посмотреть параметры: Выявить технический хвост и фасеты.
- Оценить время ответа: Найти медленные типы страниц.
- Сверить с Sitemap и crawl: Понять расхождения между проектной и реальной структурой.
- Защитить данные: Не передавать чувствительные query и токены.
- Повторить отчёт: Сравнить период после исправлений.
Вопросы
Короткие ответы
Чем логи лучше обычного краулера?
Они показывают реальные запросы робота во времени, включая старые URL и периодические серверные ошибки.
Можно ли определить YandexBot только по User-Agent?
Для надёжного анализа лучше дополнительно верифицировать источник по DNS/IP.
Сколько дней логов нужно?
Зависит от размера и частоты обхода. Нужен период, в котором представлены типичные страницы и нагрузка.
Нужно ли хранить логи годами?
Для SEO обычно достаточно разумных диагностических периодов; срок хранения определяют задачи, безопасность и политика инфраструктуры.
Практика NIC-SEO
Логи показывают поведение робота без предположений
Мы используем их, чтобы подтвердить технические гипотезы: куда уходит обход, где возникают ошибки и какие старые URL всё ещё живут.