Логи сервера для SEO: как увидеть реальный обход, а не предполагать

Что журналы сервера показывают лучше других инструментов

В журнал обычно попадают время обращения, путь, код ответа, User-Agent, IP-адрес, иногда размер и скорость ответа, referer и идентификатор хоста. Набор зависит от прокси, CDN, веб-сервера и настроек хранения, но общий смысл один: это след фактического обращения к серверу.

Он отличается от панели поисковой системы. В отчете «Статистика сканирования» Google доступны агрегированные запросы, ответы сервера, среднее время ответа, типы файлов и примеры URL. При этом Google отдельно предупреждает: часть попыток может не попасть в журналы сервера, если запрос не достиг сайта, а примеры URL в отчете не являются полным списком. Поэтому журналы и панель не соревнуются друг с другом, а отвечают на разные вопросы. Это описано в справке Search Console о статистике сканирования.

Если важная страница не видна в логе, это не повод немедленно менять robots.txt или отправлять ее на переобход. Сначала нужно сверить период, хост, путь, источник логов и саму гипотезу. Нередко запрос записывается на CDN, а команда смотрит только журнал приложения; или URL изменился после редиректа, а фильтр ищет старую версию адреса.

Сначала задайте один вопрос к данным

Самая частая ошибка - выгрузить огромный файл, отфильтровать User-Agent и остановиться на цифре запросов. У такой цифры нет решения. Полезнее выбрать один сценарий и заранее определить, какое наблюдение будет считаться сигналом к действию.

Хорошая задача по логам заканчивается не графиком, а приоритетом. Если мы видим, что робот регулярно получает 500 на страницах услуг, следующий шаг очевиден: устранить причину ответа и проверить контрольную выборку. Если же запросы приходятся на неважные варианты фильтра, сначала нужна договоренность о судьбе этого класса URL, а не еще одна выгрузка.

Практическое правило: перед выгрузкой сформулируйте один вопрос, период наблюдения и пять-десять контрольных URL. Это сохраняет время команды и не дает превратить диагностику в бесконечное чтение строк.

Подготовьте выгрузку, которой можно доверять

Логи полезны только если понятно, из какой точки они получены. У сайта могут быть CDN, балансировщик, reverse proxy, несколько хостов и отдельное приложение. Когда один слой не передает исходный IP или User-Agent дальше, вывод о роботе станет неточным. До анализа стоит зафиксировать, где запрос входит, какие поля сохраняются и за какой период доступны данные.

Не воспринимайте строку Googlebot в User-Agent как доказательство, что запрос пришел от Google. Google рекомендует проверять робота по обратному DNS, затем подтверждать, что домен указывает обратно на исходный IP, либо сопоставлять IP с опубликованными диапазонами. Подробный порядок описан в инструкции Google по проверке запросов. Для первичного анализа удобно пометить такие строки как кандидаты, а проверку подлинности выполнить до решений, которые касаются доступа или нагрузки.

Лог становится надежным источником, когда известны его границы: какой слой пишет события, какие поля сохранены и кого именно вы считаете роботом. Без этого можно принять трафик сканера или поддельный User-Agent за поисковую активность.

Смотрите на классы URL и ответы, а не на отдельные адреса

Один URL редко объясняет проблему сайта. Для работы нужны группы: страницы услуг, карточки, статьи, параметры фильтров, теги, результаты внутреннего поиска, файлы, старые маршруты. Затем - распределение ответов внутри каждой группы. Именно так обнаруживается правило, которое можно исправить на уровне шаблона.

В статье о раздутом индексе уже разобрана карта ценности URL. Логи помогают дополнить ее фактом: какие классы поисковый робот действительно открывает. Это не означает, что каждый часто посещаемый URL нужно оставлять. Наоборот, комбинация «много запросов + нет самостоятельной роли» дает хороший повод разобрать шаблон первым.

Не путайте ошибки с поводом спрятать проблему

Иногда в логе находят 404 и автоматически настраивают редирект на главную. Это ухудшает понимание структуры: посетитель получает нерелевантный путь, а команда теряет сигнал о том, что ссылка сломана. Корректный 404 может быть правильным ответом для удаленной страницы без замены. В справке Google прямо сказано, что не все 404 требуют устранения; часть из них соответствует намеренно удаленному содержанию.

Google указывает, что его инфраструктура стремится не перегружать сайт и может снижать обращения при медленных ответах или серверных ошибках. Если есть проблема нагрузки, сначала нужно установить, какой робот и какой класс URL ее создают; для этого Google прямо предлагает изучить журналы сайта или отчет статистики сканирования. Общее правило здесь простое: устранять причину ответа, а не прятать симптом.

Свяжите наблюдение с выпуском и проверкой

Логи имеют максимальную ценность вокруг изменения: запуска нового раздела, миграции, смены CDN, обновления роутинга, правил фильтрации или массовой правки URL. Тогда можно сравнить короткий период до и после, не приписывая каждое колебание случайной новости или сезону.

Когда задача связана с релизом, я прошу заранее назвать не только дату выпуска, но и ожидаемое поведение пяти контрольных страниц. Это превращает логи в приемку: мы проверяем не абстрактный «обход стал лучше», а конкретные статусы, маршруты и отсутствие новых побочных URL.

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

Начните с одной ситуации, которую можно объяснить без технического жаргона: важные страницы не получают обращения, робот видит лишние параметры, после релиза выросли ошибки или старые URL не получили понятную судьбу. Для точечной проверки конкретной страницы используйте диагностику индексирования; если речь идет о масштабной частоте обхода, сопоставьте результат с материалом о краулинговом бюджете. Логи не заменят решение о ценности страницы, зато не дадут команде строить его на догадке.