Анализ лог-файлов для SEO: читаем серверные логи и устраняем потери краулингового бюджета

Короткий тест

Подходит ли вам SEO и с чего начать?

Вопрос 1 из 425%

Ищут ли люди в Google то, что вы продаёте?

Да, думаю, ищутНет, это новое или очень нишевоеНе знаю

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

Каждый раз, когда что-то запрашивает файл с вашего сервера, сервер записывает одну строку в свой лог доступа. Большинство серверов используют формат, близкий к "combined" формату Apache. Запрос Googlebot выглядит так:

66.249.66.1 - - [13/Nov/2026:08:14:22 +0100] "GET /products/red-running-shoes HTTP/1.1" 200 18342 "-" "Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; Googlebot/2.1; +http://www.google.com/bot.html)"

Читайте её слева направо: IP-адрес, временная метка, HTTP-метод и URL, код состояния (здесь 200), число переданных байтов, реферер и user agent. Здесь есть каждый запрос, включая те, которые никогда не появляются как просмотр страницы в вашем аналитическом инструменте: изображения, CSS-файлы, редиректы и ошибки 404.

Остальные источники данных видят только часть этого. Отчёт «Статистика сканирования» в Search Console агрегирован и охватывает только сканеры Google. Аналитические инструменты фиксируют только посетителей, чей браузер выполняет ваш JavaScript. Краулер сайта, например Screaming Frog, показывает то, что он может достичь, переходя по вашим ссылкам, а это не то же самое, что Google решил запросить. Только лог сервера фиксирует то, что действительно произошло.

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

Краулинговый бюджет представляет собой набор URL, которые Google может и хочет сканировать на вашем сайте. Google описывает его через два фактора. Первый фактор: лимит пропускной способности сканирования: сколько соединений сканеры Google могут держать открытыми к вашему серверу, не перегружая его. Этот лимит растёт, когда сайт работает стабильно, и падает, когда ответы замедляются или возвращают ошибки 5xx или 429. Второй фактор: спрос на сканирование, который зависит от размера сайта, частоты изменения контента, его качества и популярности страниц.

Google подаёт эту тему как продвинутое руководство для крупных сайтов. Ориентировочные пороги: сайты с 1 миллионом и более уникальных страниц, контент которых меняется примерно раз в неделю, и сайты с 10000 и более уникальных страниц, контент которых меняется каждый день. В зону внимания попадают и сайты, где много URL в статусе «Discovered - currently not indexed». Небольшие сайты обычно справляются с актуальной картой сайта и регулярной проверкой отчёта «Индексирование страниц». Это не значит, что логи для них бесполезны. Когда с сканированием что-то не так, лог: самый быстрый способ увидеть, где именно.

Если ваш сайт попадает в этот диапазон, вопрос уже не в том, читать ли логи, а в том, как часто. Разовый аудит показывает потери сегодня. Ежемесячная выгрузка показывает, изменили ли ваши исправления то, на что Googlebot тратит время. Для базовых понятий полезна статья глоссария о краулинговом бюджете, а руководство по статусу Discovered, currently not indexed объясняет статус, который обычно и запускает такую проверку.

Метод шаг за шагом

Описанный ниже порядок работы подходит для любого сервера и любого инструмента. Следующие разделы подробно объясняют каждый шаг и дают команды, которые можно запустить на сыром лог-файле уже сегодня.

Берите логи с правильного уровня

Попросите разработчика или хостинг-провайдера предоставить исходные логи доступа веб-сервера (Apache, Nginx или IIS). Перед началом проверьте три вещи: формат логов, часовой пояс и срок хранения. В зависимости от настроек старые логи могут ротироваться через несколько дней или недель, поэтому запросите выгрузку сейчас, а не позже.

Уровень важнее, чем многие думают. Если CDN отвечает на запрос из своего кэша, origin-сервер этот запрос никогда не видит. Googlebot может сканировать URL, которого нет в логе origin, поэтому выгрузка только с origin занижает активность сканирования кэшированного контента. Выгрузите и логи CDN, сравните два источника для нескольких URL, прежде чем доверять какому-либо итогу.

Фильтруйте и считайте Googlebot несколькими командами

В логе формата combined код состояния стоит в 9-м поле, а путь URL в 7-м. Эти два столбца отвечают на большинство первых вопросов. Эта команда считает запросы Googlebot по кодам состояния:

grep "Googlebot" access.log | awk '{print $9}' | sort | uniq -c | sort -rn

Эта команда выводит 20 путей, которые Googlebot запрашивает чаще всего, с удалённой строкой запроса, чтобы варианты фильтров группировались вместе:

grep "Googlebot" access.log | awk '{print $7}' | cut -d '?' -f1 | sort | uniq -c | sort -rn | head -20

Первая команда читает текст user agent, который может подделать любой. Считайте её результат списком кандидатов, пока не завершён следующий раздел. Если ваш лог использует собственный формат, номера полей меняются, поэтому проверьте одну строку глазами, прежде чем доверять столбцам.

Проверяйте Googlebot так, как его описывает Google

Собственный метод Google, позволяющий подтвердить, что посетитель является Googlebot, использует DNS. Выполните обратный DNS-поиск по IP-адресу из лога, убедитесь, что имя хоста оканчивается на googlebot.com, google.com или googleusercontent.com, затем выполните прямой поиск по этому имени и проверьте, что он возвращает исходный IP. В документации Google используется такой пример: 66.249.66.1 обратно разрешается в crawl-66-249-66-1.googlebot.com:

host 66.249.66.1

Прямую проверку выполняет вторая команда, и она должна вернуть тот же IP:

host crawl-66-249-66-1.googlebot.com

Если вы обрабатываете миллионы строк, DNS-запросы станут медленными. Google также публикует JSON-файлы с диапазонами IP своих сканеров, включая common-crawlers.json для Googlebot. Сопоставление с этими диапазонами быстрее, а официальное руководство по проверке описывает оба метода в руководстве Google по проверке Googlebot.

Группируйте, измеряйте и читайте результаты

Сырые счётчики по каждому URL трудно использовать. Сначала группируйте URL по шаблону, потому что исправление обычно касается шаблона, а не одной страницы. Затем измерьте четыре вещи для каждой группы. Измерьте, сколько обращений Googlebot она получает по сравнению с её значением для бизнеса. Измерьте распределение кодов состояния. Измерьте, как быстро новые страницы получают первое обращение после публикации. Измерьте, концентрируются ли обращения на страницах, которые вы хотите видеть в выдаче.

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

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

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

Сигнал	Что показывают логи	Что делать
Потери на сканировании	Обращения Googlebot к фильтрам, порядкам сортировки, внутреннему поиску и URL сессий	Консолидируйте через canonical, уберите внутренние ссылки на эти URL и блокируйте бессмысленные варианты в robots.txt там, где их нельзя консолидировать
Редиректы	Обращения к ответам 301 или 302 и цепочки из двух и более переходов	Ссылайтесь напрямую на конечный URL. Руководство по 301 и 302 поможет выбрать правильный тип редиректа
Ошибки	Повторные обращения к 404 или 410 и всплески ответов 5xx	Восстановите или перенаправьте страницы, которые по-прежнему важны, и устраните ошибки сервера, так как ответы 5xx снижают объём сканирования Google
Пропущенные сканирования	Важные URL, которые за период ни разу не получили обращения Googlebot	Проверьте внутренние ссылки, записи в карте сайта и правила robots.txt, которые могут не пускать к ним сканеры
Дубликаты	Один и тот же контент открывается по разным URL: с завершающим слэшем, заглавными буквами или параметрами	Выберите один канонический URL и ссылайтесь на него везде
Время до первого сканирования	Время между публикацией и первым обращением Googlebot к новой странице	Ссылайтесь на новые страницы с тех, которые уже часто сканируются, и держите карту сайта в порядке
Время ответа	Медленные ответы на шаблоны, которые Googlebot посещает чаще всего	Ускорьте эти шаблоны в первую очередь, так как Google говорит, что медленные ответы заставляют его сканировать меньше

Строку о пропущенных сканированиях часто пропускают, а она нередко самая дорогая. Страница, которую вы никогда не видите в логе, не может ранжироваться ни по одному запросу, даже если её контент отличный. Если URL есть в карте сайта, но никогда не появляется в логах, страница, вероятно, доступна только по пути, который сканеры не проходят. Руководство по статусу Crawled, currently not indexed охватывает другую сторону этой ситуации, когда Googlebot заходит на страницу, но всё равно не индексирует её.

Три способа провести анализ, сравнение

Анализ логов можно проводить скриптами, настольным приложением или платформой. Каждый вариант подходит для разного объёма и разной команды. Выбор зависит не столько от размера сайта, сколько от того, как часто нужен ответ и кто будет его читать.

Командная строка: grep, awk и Python

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

Пример: команды из раздела о методе, запущенные раз в месяц на одной и той же выгрузке, дают распределение кодов состояния и самые частые пути Googlebot. Короткий Python-скрипт может сделать то же и добавить DNS-проверку, которая медленнее, но точнее.

Настольный инструмент: Screaming Frog Log File Analyser

Принцип: вы импортируете сырые логи в настольный проект, а инструмент группирует ботов, проверяет их идентичность и строит графики. Когда использовать: консультант или внутренний аналитик, работающий с сайтом из десятков тысяч URL. Преимущества: он читает логи Apache, IIS и Nginx в формате W3C Extended, проверяет поисковых ботов и отмечает большие или медленные страницы. Ограничения: бесплатная версия ограничена, а объём данных зависит от жёсткого диска.

Прочитайте страницу Screaming Frog о Log File Analyser перед покупкой. Полный разбор парного краулера смотрите в нашем руководстве по Screaming Frog SEO Spider. Анализатор логов делает то, чего не может краулер: показывает, что боты реально запрашивали, а не то, что подсказывают ваши ссылки.

Платформа: непрерывный мониторинг логов

Принцип: платформа получает ваши логи по расписанию, часто от CDN или сервера, и объединяет их с сканированием вашего сайта и данными индексации. Когда использовать: крупные интернет-магазины или корпоративные команды, которые каждую неделю отслеживают сканирование на нескольких рынках. Преимущества: масштабируется на очень большие логи, хранит историю, и несколько команд могут делить дашборды. Ограничения: стоит дороже, требует времени на внедрение, а привязка к поставщику реальна, поэтому прежде чем подписываться, проверьте, как экспортировать данные. В этой категории работают Oncrawl и Botify, и стоит спросить каждого поставщика, как он проверяет ботов.

Критерий	Командная строка	Настольный инструмент	Платформа
Стоимость	Бесплатно	Бесплатно до 1000 событий лога, £99 в год за полную лицензию	Подписка, цена зависит от объёма
Настройка	Скрипты пишете и поддерживаете вы	Установка, импорт, запуск	Коннекторы и онбординг
Объём	Ограничен вашей машиной	Ограничен жёстким диском и лицензией	Создан для очень больших логов
Проверка ботов	Вручную, через DNS или проверку диапазонов IP	Встроена	Уточняйте у поставщика
Лучше всего для	Разовых проверок и небольших сайтов	Консультантов и средних сайтов	Корпоративных и интернет-магазинных команд с еженедельным мониторингом

Отчёт «Статистика сканирования» Google: полезен, но недостаточен

Прежде чем выгружать хотя бы один лог, откройте отчёт «Статистика сканирования» в Search Console. Он показывает общее число запросов сканирования, общий объём загрузки, среднее время ответа, ответы, сгруппированные по типу, типы файлов, назначение сканирования и тип Googlebot, который сделал каждый запрос. Для проверки тренда это самый быстрый вид, который у вас есть, а руководство по Google Search Console объясняет, где его найти.

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

Справка Google по статистике сканирования описывает каждую группировку. Если график и ваша выгрузка логов расходятся, не доверяйте ни одному из них, пока не проверите временное окно и шаг с верификацией. Большинство таких расхождений вызвано другим окном, CDN, который отвечает из кэша, или подсчётом ботов, который включает непроверенные запросы.

Устранение потерь на сканировании, когда вы их увидели

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

Фасетная навигация. Фильтры и порядки сортировки создают много URL с почти одинаковым контентом. Консолидируйте их через canonical, где это возможно, и уберите внутренние ссылки на варианты без поискового значения. Там, где вариант нельзя консолидировать и он должен оставаться вне сканирования, заблокируйте его в robots.txt. Рекомендация Google здесь конкретна: не используйте для этого noindex, потому что Google всё равно должен запросить страницу, прежде чем сможет увидеть тег. Вот пример правила, которое стоит проверить:

User-agent: Googlebot
Disallow: /*?sort=
Disallow: /*?color=

Сохраняйте меру в изменениях robots.txt. Google говорит, что блокировка URL не освобождает краулинговый бюджет для других страниц, пока сайт уже не упёрся в лимит пропускной способности. Блокировка нужна для URL без ценности, а не для перераспределения бюджета на лучшие страницы. Наша статья глоссария о robots.txt объясняет, как читается файл.

Цепочки редиректов. Если страница переехала дважды, краулер каждый раз проходит оба редиректа. Обновите внутренние ссылки так, чтобы они вели на конечный URL, а старые редиректы оставьте для внешних ссылок. Выбор между постоянным и временным редиректом важен по той же причине, и руководство по 301 и 302 подробно это разбирает.

Удалённые страницы. Возвращайте 404 или 410 для страниц, которые удалены навсегда. Google говорит, что мягкие 404 продолжают сканироваться и тратят краулинговый бюджет, поэтому сообщение «страница не найдена», отданное со статусом 200, хуже настоящей 404.

Время ответа и кэширование. Google говорит, что медленные или сбойные ответы заставляют его сканировать меньше. Поддерживайте ответы 304 (Not Modified), чтобы неизменённые страницы отдавались из кэша. Затем посмотрите на шаблоны, которые получают больше всего обращений Googlebot, и ускоряйте их ответы в первую очередь.

Ошибки, которые стоят дороже всего, и как их избежать

Большинство неудачных анализов логов совершают одну из небольшого набора ошибок. У каждой из них ниже есть симптом, который видно в данных, и исправление, которое можно внедрить в ту же неделю.

Доверие строке user agent

Что это: подсчёт каждого запроса, который называет себя «Googlebot», как сканирования Google. Как распознать: обращения Googlebot с IP-адресов, которые не разрешаются обратно в имена хостов Google, или резкий скачок с одного адреса. Как исправить: выполните проверку из раздела о методе, прежде чем что-либо считать, и держите непроверенные обращения в отдельной группе, чтобы по-прежнему видеть активность скрейперов.

Чтение только ответов 200

Что это: фокус на страницах, которые отдают 200, и игнорирование остальных. Как распознать: в вашем отчёте нет раздела 3xx, 4xx или 5xx, или распределение кодов состояния никогда не обсуждается. Как исправить: всегда начинайте с распределения кодов состояния. Рост обращений к 404 может указывать на битую внутреннюю ссылку, а рост обращений к 5xx указывает на проблему сервера, которая замедляет всё сканирование.

Блокировка страницы, которую вы хотите удалить из индекса

Что это: добавление правила robots.txt к странице, на которой также стоит тег noindex. Как распознать: страница остаётся в индексе, а в логе нет обращений Googlebot, потому что сканер не может её запросить. Как исправить: снимите блокировку, чтобы Google мог прочитать тег noindex, дождитесь, пока страница выпадет из индекса, а затем, если блокировка всё ещё нужна, верните её. Руководство по Blocked by robots.txt объясняет статус Search Console, который появляется в этом случае.

Сравнение окон разной длины

Что это: сравнение 3-дневной выгрузки до исправления с 30-дневной выгрузкой после него. Как распознать: итоги сильно меняются, а доля по шаблонам остаётся прежней. Как исправить: сравнивайте одинаковое число дней, по возможности в одно и то же время года, а при изменении объёма сравнивайте доли, а не сырые итоги.

Измерение обращений вместо ценности

Что это: радость от роста обращений Googlebot без проверки, доходят ли они до индексируемых страниц. Как распознать: обращения концентрируются на URL, которые не индексируются или никогда не приносят трафик. Как исправить: сопоставьте группы логов со статусом индексации из инструмента проверки URL в Search Console и считайте исправление успехом, только если сканирование смещается к важным страницам.

Где AI-боты находятся в тех же логах

Те же логи показывают, что делают AI-краулеры на вашем сайте, и метод тот же: группируйте, проверяйте там, где поставщик даёт такую возможность, и читайте коды состояния. Наше руководство по логам AI-краулеров объясняет, каких ботов искать и чем они отличаются от Googlebot. Эта статья подробно разбирает метод для Googlebot, а раздел об AI ниже показывает, как объединить оба в одном отчёте.

Тип бота	Примеры	Что проверять в логах	Подробнее
Поисковый краулер	Googlebot	Обращения по шаблонам, распределение кодов состояния, время до первого сканирования новых страниц	Разделы выше в этой статье
Краулер обучения	GPTBot, ClaudeBot, CCBot	Запрашивают ли они ваш контент вообще и соблюдают ли ваш robots.txt	Robots.txt для AI-краулеров
Краулер извлечения	ChatGPT-User, PerplexityBot	Короткие всплески визитов, связанные с вопросами пользователей, и страницы, до которых они доходят	Логи AI-краулеров

Разделение на обучение и извлечение следует из того, как документируются AI-краулеры. Краулеры обучения собирают контент для моделей, а краулеры извлечения загружают страницы, когда пользователь задаёт вопрос. В отчёте их нужно держать раздельно, потому что решение по одному не распространяется автоматически на другой.

Если вы хотите видеть трафик Google и трафик AI рядом, пока внедряете эти исправления, дашборд GEO / SEO Sorank показывает оба в одном виде. Используйте его, чтобы проверить, двигают ли изменения, сделанные по логам, трафик, а не только меняют ли они число сканирований.