Анализ лог-файлов (Log File Analysis)
Изучение журналов доступа сервера: какие URL запрашивали роботы, когда и с каким ответом.
Проверил Alexander Yarovenko · Обновлено: 2026-10-04
Анализ лог-файлов — изучение журналов доступа веб-сервера, чтобы увидеть, какие URL поисковые роботы действительно запрашивали, когда и с каким ответом. В отличие от обхода сайта SEO-инструментом, журнал показывает, что роботы реально делали на сайте. Он не показывает, проиндексирована ли страница и как она ранжируется: запрос — это только запрос.
Что это и где проходит граница
Каждый запрос к серверу записывается в журнал: время, адрес, URL, код ответа, размер и user agent. Отфильтрованный до проверенных роботов Google, этот файл — единственная первичная запись обхода, которой вы владеете. Отчёт Search Console «Статистика сканирования» — та же идея со стороны Google, но он ограничен выбранным доменом и рассчитан на опытных пользователей. Ни то, ни другое не говорит, что произошло после загрузки страницы.
Чем отличается от похожих терминов
| Понятие | Источник | На что отвечает |
|---|---|---|
| Анализ лог-файлов | ваш сервер | какие URL запрашивались и что ответил сервер |
| Статистика сканирования | Search Console | запросы Google, ответы и проблемы доступности |
| Аудит доступности для обхода | инструмент, обходящий сайт | что мог достичь робот, а не что сделал Google |
| Краулинговый бюджет | понятие из руководства Google | сколько Google может и хочет сканировать |
Зачем это нужно
Для большого или часто меняющегося сайта журналы показывают, куда уходит обход: на ценные страницы, дубли с параметрами, редиректы или ошибки. Google пишет, что медленные ответы и ошибки сервера снижают лимит сканирования, а страницы soft 404 продолжают сканироваться и тратят бюджет. Для небольшого сайта отчёт «Статистика сканирования» назван ненужным примерно до тысячи страниц, поэтому журналы там — диагностика последней очереди.
Что читать в строке журнала
Типичная строка выглядит так:
66.249.66.1 - - [03/Oct/2026:09:14:02 +0000] "GET /catalog/pans?page=2 HTTP/1.1" 200 18342 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"В ней записаны адрес запросившего, время, URL, статус (200), размер и user agent. User agent лишь заявляет личность. Документация Google предлагает проверять обратным DNS-запросом по IP, который должен разрешаться в googlebot.com, google.com или googleusercontent.com, затем прямым запросом, возвращающим тот же IP, либо сверять IP с опубликованными списками Google.
Как применять
- Получите сырые журналы доступа за период в несколько недель, включая CDN или балансировщик, если они стоят перед сервером.
- Оставьте только запросы, чей IP проходит проверку обратным и прямым DNS или входит в опубликованные диапазоны Google.
- Сгруппируйте URL по шаблонам: категория, товар, статья, варианты с параметрами, файлы.
- Посчитайте запросы и коды ответа по группам; ищите ошибки, длинные цепочки редиректов и soft 404.
- Сравните обойдённые URL с картой сайта: важные URL без запросов и запрашиваемые URL, которых вы не указывали.
- Устраните причины (ссылки, редиректы, время ответа, правила robots.txt) и повторите на следующем периоде.
Практический пример
Журналы магазина за четыре недели после проверки группируются так:
| Шаблон | Наблюдение | Действие |
|---|---|---|
| /catalog/…?sort=, ?page= | большинство запросов идёт на варианты сортировки | проверить внутренние ссылки, canonical и правила robots |
| /product/… | новые товары впервые запрашиваются через недели | проверить lastmod в карте сайта и внутренние ссылки |
| /old-section/… | запросы заканчиваются цепочкой редиректов | вести ссылки сразу на конечный URL |
Каждая строка — гипотеза для проверки, а не приговор: журнал показывает запросы, а не их влияние на индексацию.
Частые ошибки
- Верить user agent: проверяйте IP; одна строка не доказательство.
- Считать запрос индексацией: просканированная страница всё равно может не попасть в индекс; проверяйте страницу в Search Console.
- Упустить слой CDN: журналы только исходного сервера могут скрыть запросы, обслуженные кэшем.
- Анализировать один день: обход колеблется; берите несколько недель.
- Применять метод к крошечному сайту: Google пишет, что отчёт не нужен до тысячи страниц; потратьте время на контент.
- Считать переходы редиректа за один: отчёт Google считает каждый запрос в цепочке отдельно, как и журналы.
Как проверить результат
После исправления сравните те же группы шаблонов за следующий период: меньше запросов к лишним вариантам, меньше ответов с ошибками и редиректами, раньше первые запросы к новым страницам. Подтвердите в отчёте «Статистика сканирования», что ошибки сервера и проблемы доступности сокращаются. Не ждите изменения позиций только от изменений обхода.
Ещё вопросы
Можно ли обойтись Search Console?
Частично. Отчёт показывает запросы Google, ответы и доступность, но только для выбранного домена и в сводке. Журналы показывают каждый URL и каждого робота.
Больше обхода — выше позиции?
Документация этого не утверждает. Сканирование — условие индексации, а не фактор ранжирования.
Нужна ли специальная программа?
Для нескольких недель журналов хватит скрипта или таблицы. Специализированные инструменты помогают с очень большими файлами.
Следующий практический шаг
Пройдите урок Аудит сканирования, затем выгрузите журналы за неделю и сгруппируйте их по шаблонам.
Связанные понятия
- Краулинговый бюджет — сколько Google сканирует на сайте.
- Глубина обхода — число кликов до страницы.
- Ошибки сканирования — неудавшиеся запросы.
- Цепочка редиректов — несколько переходов до конечного URL.
- Google Search Console — статистика сканирования и отчёты об индексации.