SEOProvision
В отчёте видно 20 000 обращений с User-agent YandexBot. Половина пришлась на параметры сортировки, важные карточки за день не запрашивались, а часть «роботов» использовала чужие IP. Общая цифра выглядит внушительно, но не отвечает на главный вопрос: какие URL реально запросил подтверждённый поисковый робот и что получил от сервера.
Лог-анализ для SEO начинается с одной строки access log, а не с красивого графика. В ней есть время, адрес, метод, код ответа, объём, User-agent и IP. После проверки принадлежности поисковых роботов строки группируют по шаблонам URL. Только тогда видно, куда ушли запросы: на ценные документы, редиректы, ошибки или бесконечные параметры.
Строка лога фиксирует реальный запрос к серверу
Серверный лог записывает обращение до того, как аналитический счётчик выполнится в браузере. Поэтому в нём видны роботы, ошибки загрузки и запросы к техническим URL. Это фактический след запроса, но не готовый SEO-вывод: одна строка не доказывает индексацию, позицию или полезность страницы.
| Поле | Пример | Как используется |
|---|---|---|
| Время | 27/Jul/2026:10:15:04 +0300 | Строит последовательность визитов |
| Метод и URL | GET /catalog?page=8 | Показывает запрошенный документ |
| Код ответа | 200, 301, 404, 500 | Описывает результат обращения |
| Объём | 18452 | Помогает заметить пустой или аномальный ответ |
| User-agent | YandexBot/3.0 | Даёт кандидата на фильтрацию |
| IP | адрес клиента | Нужен для подтверждения робота |
Сначала проверьте формат и часовой пояс. Логи CDN и origin-сервера могут хранить разное время и разные адреса клиента. Если настоящий IP скрыт за прокси, нужно корректно читать доверенный заголовок, а не принимать адрес балансировщика за источник всех обращений.
Не удаляйте параметры до первого анализа. Они могут быть самой причиной лишнего обхода. Сохраните исходный URL, а нормализованную группу добавьте отдельным полем: /catalog?sort=price и /catalog?sort=name попадут в один шаблон сортировки, но их конкретные значения останутся доступными.
Робота определяют по нескольким признакам
Любой клиент может написать YandexBot в User-agent. Фильтр только по этой строке включает маскирующиеся программы и искажает частоту обхода. Яндекс рекомендует проверять принадлежность по IP через инструмент Вебмастера или связку reverse DNS с обратной проверкой адреса.
Практический порядок такой: выберите IP из лога, выполните обратное разрешение имени, убедитесь, что домен относится к Яндексу, затем разрешите полученное имя обратно и проверьте присутствие исходного IP. Для разовой проверки подойдёт официальный инструмент. Не храните статический список адресов: диапазоны могут меняться.
Разделяйте назначение роботов. Основной индексирующий робот, сервис проверки Вебмастера и другие агенты могут обращаться к сайту с разными задачами. Сам факт визита сервиса Яндекса не означает, что документ загружен в поисковый индекс.
- отфильтруйте кандидатов по User-agent без привязки к версии браузера;
- подтвердите IP официальным способом;
- сохраните тип робота отдельным полем;
- исключите внутренние проверки, мониторинг и CDN health-check;
- зафиксируйте долю неподтверждённых обращений, а не смешивайте их с поисковым обходом.
URL и коды ответа показывают цену обхода
После очистки сгруппируйте запросы по шаблонам страниц: категории, товары, статьи, фильтры, поиск, файлы и служебные адреса. Внутри каждой группы посчитайте обращения и распределение кодов. Так общий объём превращается в карту работы сервера.
| Группа | Запросы | Коды | Первый вывод |
|---|---|---|---|
| Карточки товаров | 1 420 | 94% 200, 6% 404 | Разобрать удалённые ID и ссылки |
| Сортировки | 8 900 | 200 | Проверить генерацию параметров и Clean-param |
| Категории | 310 | 200 | Сопоставить с обновлениями и глубиной |
| Старые URL | 640 | 301 → 301 → 200 | Сократить цепочки |
| API | 270 | 5xx | Найти сбой динамического контента |
Код 200 не всегда означает полезный обход. Страница может быть пустой, дублирующей или персональной. Поэтому к группе добавляют размер ответа, canonical из выборочной проверки и тип содержимого. Но не пытайтесь извлечь весь HTML из access log: он показывает запрос, а тело проверяется отдельно.
Коды 3xx требуют разворачивания цепочки. Если робот постоянно проходит старый адрес через два промежуточных редиректа, обновите внутренние ссылки и сократите маршрут. Группы 4xx сопоставьте с источниками ссылок, а 5xx — со временем релизов и нагрузкой.
Приоритет задаёт сочетание масштаба и ценности. Сто запросов к аварийным карточкам могут быть важнее десяти тысяч обращений к безвредному статическому файлу. Таблица нужна не для соревнования цифр, а для выбора конкретной проверки.
Частота визитов без контекста вводит в заблуждение
Рост обращений не является автоматическим улучшением. Робот может чаще запрашивать новые полезные статьи, а может зациклиться на календаре, сортировках и бесконечных фильтрах. Сравнивайте частоту вместе с типом URL, кодом ответа и изменениями содержимого.
Падение запросов тоже не всегда означает проблему. Стабильные документы могут обходиться реже, а кэш и Last-Modified влияют на работу сервера. Ищите не идеальное число визитов, а несоответствие: обновляемый раздел не посещается, важные страницы отсутствуют, ошибки повторяются, технические варианты забирают основную долю.
Лог не показывает, вошла ли страница в индекс и по каким запросам она видна. Для этого нужны данные Яндекс Вебмастера и фактическая выдача. Он также не объясняет пользовательский спрос. Факт запроса, индексация и ранжирование — три разных этапа.
| Наблюдение | Что можно сказать | Чего утверждать нельзя |
|---|---|---|
| Робот запросил URL и получил 200 | Документ был доступен в этот момент | Он вошёл в индекс |
| URL запрашивается ежедневно | Робот часто к нему возвращается | Страница важна или хорошо ранжируется |
| 404 больше не встречается | В выбранном периоде запросов не было | Все ссылки исправлены |
| Параметры занимают 60% | Большая доля обхода приходится на варианты | Они обязательно вредят позициям |
Вопросы и ответы
Какой формат серверного лога нужен для SEO-анализа?
Достаточен access log с датой и временем, методом, полным URL, кодом, размером ответа, User-agent и реальным IP клиента. Referer полезен для поиска источника ошибочной ссылки, а время обработки — для диагностики нагрузки.
За какой период брать данные?
Для первого разбора начните с одного полного дня без аварии, затем возьмите неделю или месяц для устойчивых закономерностей. Сезонный крупный сайт требует периода, который включает обычные и пиковые дни.
Можно ли передавать логи подрядчику без очистки?
Сначала удалите токены, cookie, персональные параметры, внутренние адреса и всё, что не нужно для задачи. Передавайте минимальный набор полей по защищённому каналу и заранее согласуйте срок хранения.
Однодневная трассировка превращает записи в решение
Для первого полезного анализа не нужна большая платформа. Выберите один раздел и один спокойный день. Выгрузите строки, подтвердите роботов, приведите время к одному часовому поясу и добавьте шаблон URL. Исходный файл сохраните неизменным, а преобразования выполняйте в отдельной таблице или скрипте.
Однодневная трассировка: от строки лога к решению
- Сколько подтверждённых запросов получил раздел и какие роботы обращались.
- Какие десять URL запрашивались чаще всего и почему.
- Как распределились 200, 3xx, 4xx и 5xx.
- Какие параметры образовали самые большие группы.
- Какие важные URL не встретились, хотя были обновлены.
- Какое одно исправление можно проверить по следующему периоду.
Допустим, 62% обращений пришлись на sort и view, а ссылки на эти варианты стоят в HTML фильтра. Решение — вести внутренние ссылки на основной порядок, проверить canonical и обработку незначащих параметров. Через неделю повторите тот же срез: доля технических вариантов должна снизиться, а ценные категории не исчезнуть.
Другой исход: карточки регулярно получают 500 в коротком ночном окне. Здесь не нужно сокращать обход. Сопоставьте время с резервным копированием, релизом и нагрузкой на API, затем исправьте доступность. Следующий лог должен показать 200 для тех же URL.
Когда проводится комплексное SEO-продвижение сайта, лог-анализ связывают с краулингом, Вебмастером и планом технических работ. Серверные записи дают фактический слой, а остальные источники объясняют внутренние ссылки, статус в поиске и ценность страниц.
Трассировка готова, если коллега может взять исходный файл, повторить фильтр и получить те же группы. Итогом служит не диаграмма визитов, а короткое решение: какой шаблон создаёт лишние URL, где робот получает ошибки и что сравнить после исправления.
