Каждое обращение к сайту записывается в журнал сервера: время, адрес страницы, код ответа, кто обратился. Для поискового продвижения это самый честный источник данных. Search Console показывает обобщённую статистику с задержкой, а журнал показывает буквально: робот пришёл в такое-то время, запросил такую-то страницу и получил такой-то ответ. Никаких оценок и усреднений.
Какие вопросы решает анализ логов
- Какие разделы робот обходит чаще всего, а какие не посещал месяцами.
- Сколько обращений уходит на служебные адреса, фильтры и картинки вместо товаров.
- Встречает ли робот ошибки 404 и 500, о которых вы не знаете.
- Как быстро сервер отвечает именно роботу, а не обычным посетителям.
- Приходит ли трафик от ботов, которые только создают нагрузку без пользы.
Особенно полезен такой анализ для больших каталогов. Робот тратит на сайт ограниченное количество обращений. Если половина уходит на бесконечные комбинации фильтров, до новых товаров он доберётся нескоро, и это не видно ни по одному отчёту кроме логов.
Где взять логи
На VPS они лежат в каталоге журналов веб-сервера, обычно это access.log у nginx или Apache. На виртуальном хостинге их отдаёт панель управления, иногда за последние несколько дней. Если сайт стоит за CDN, брать логи нужно у CDN: до сервера запросы могут просто не доходить. Для первого анализа достаточно выгрузки за две-четыре недели.
Как отличить настоящего робота
В строке журнала есть поле user agent, и подделать его может кто угодно. Значительная часть обращений от якобы Googlebot на самом деле приходит от парсеров конкурентов и сканеров уязвимостей. Настоящий робот проверяется обратным просмотром по IP: адрес должен принадлежать домену googlebot.com или google.com. Без этой проверки выводы об обходе будут искажены, иногда в разы.
С чего начать разбор
Первым делом сгруппируйте обращения робота по кодам ответа. Заметная доля ответов 404 и 301 означает, что бюджет обхода тратится на несуществующие и переехавшие адреса, а источник таких ссылок обычно находится внутри самого сайта - в старом меню, в карте сайта или в блоке рекомендаций. Затем сгруппируйте по разделам и сравните с тем, что для бизнеса важно. Типичная находка: робот активно обходит архивы по датам в блоге и почти не заходит в раздел услуг.
Третий шаг - посмотреть время ответа по обращениям робота. Если оно заметно больше, чем у обычных посетителей, значит роботу достаются некешированные ответы, и при большом каталоге это напрямую ограничивает скорость обхода.
Для небольшого сайта на тридцать страниц анализ логов избыточен: там всё видно в Search Console. Но начиная с нескольких тысяч адресов это часто единственный способ понять, почему новые страницы неделями не появляются в поиске, и починить причину, а не симптом.
Чем обрабатывать
Для первого раза хватит выгрузки в таблицу: отфильтровать строки по user agent, сгруппировать по разделам и кодам ответа. При объёме в миллионы строк удобнее специализированные инструменты для анализа логов или обычные консольные утилиты вроде grep и awk прямо на сервере. Платные сервисы добавляют графики и автоматическое сопоставление с картой сайта, но принципиально новых выводов не дают.
Полезный приём - сравнить список адресов из логов со списком из карты сайта. Адреса, которые есть в карте, но ни разу не встретились в логах, робот не посещал вообще. Адреса, которые робот обходит, но которых нет в карте сайта, обычно оказываются мусором: старые версии страниц, технические параметры, следы прошлой CMS.
Что делать с результатом
Логи сами по себе ничего не улучшают, они только показывают, куда направить усилия. Типичный план после первого анализа выглядит так: убрать внутренние ссылки на несуществующие страницы, закрыть от обхода бесконечные комбинации фильтров, добавить ссылки на разделы, которые робот не находит, и настроить кеширование для тяжёлых страниц. Повторный разбор через месяц покажет, сдвинулось ли распределение обхода в нужную сторону.