Анализ логов самостоятельного сайта: как читать логи Nginx/Apache — краулеры, ошибки, трафик
Почему нельзя смотреть только на «общее число визитов»
Многие владельцы сайтов, открывая лог, первым делом смотрят, сколько запросов пришло за сегодня, и по этой цифре судят, как идут дела. Это первая ловушка: в стандартном access.log от Nginx одна запись — это один HTTP-запрос, а один реальный человек, открывая главную, может создать 8–15 запросов (HTML, CSS, JS и картинки считаются отдельно), тогда как вредоносный краулер за минуту делает тысячи. Общее число для решений почти бесполезно.
Вот контринтуитивный вывод:Ваши визиты «взлетели» — скорее всего, какой-то краулер начал яростно обходить ваш сайт, а не пришли клиенты. Критерий простой — сгруппируйте лог по User-Agent и посмотрите, кто входит в топ-20 источников запросов. Если больше половины — это UA из категории bot, всплеск не имеет никакого отношения к вашему бизнесу. Это совпадает с логикой анализе логов AI-краулеров: сначала разберитесь, «кто вас читает», и только потом — «сколько прочитал».
| Поле лога (Nginx combined) | Значение | Для чего анализировать |
|---|---|---|
| $remote_addr | IP источника | Выявить IP дата-центров, вредоносное сканирование, принадлежность краулера |
| $request | Метод запроса + путь + протокол | Понять, какие URL реально посещали, какие файлы дёргали |
| $status | HTTP-статус | 200 — норма, 301 — редирект, 404 — битая ссылка, 5xx — сбой |
| $body_bytes_sent | Число отданных байт | Выявить пустые ответы и заблокированные подозрительные скачивания |
| $http_referer | Страница-источник | По какой ссылке пришёл реальный человек |
| $http_user_agent | Идентификатор клиента | Отличить браузер, поискового краулера и AI-краулера |
Как читать: три типа сигналов — краулеры, ошибки, реальный трафик
Рекомендуемый порядок анализа всегда такой: «ошибки → краулеры → реальные люди», не наоборот. Причина в том, что ошибки напрямую бьют по опыту реальных людей и потому в приоритете; объём краулеров определяет ваш бюджет на обход и расходы на трафик; а реальный трафик — то, что стоит разбирать подробно в последнюю очередь. Именно поэтому в Мониторинг сайта и оповещения доступность и доля ошибок стоят на первом месте.
Не полагайтесь только на UA при распознавании краулеров: вредоносные боты подделывают UA и выдают себя за Googlebot. Стандартный подход — двусторонняя проверка: для IP, который называет себя Googlebot, делаем обратный DNS и убеждаемся, что он действительно из диапазона googlebot.com, затем делаем прямой DNS и сверяем. Поддельный краулер этот шаг не пройдёт.
| Категория сигнала | Здоровый диапазон | Порог для вмешательства | Действие |
|---|---|---|---|
| Доля ошибок 5xx | Меньше 0,5% | Больше 1% в течение 10 минут подряд | Проверить PHP-FPM и логи бэкенда, немедленно |
| Доля 404 | Меньше 3% | Один URL даёт больше 100 ошибок 404 в день | Поставить 301 или исправить внутренние ссылки |
| Доля подозрительных запросов краулеров | 20–40% | Больше 60% и не хватает пропускной способности | Ограничить через robots или WAF |
| Количество сессий реальных пользователей | Стабильно неделя к неделе | Падение больше 20% две недели подряд | Проверить индексацию и рекламу, а не сервер |
| Доля чтения AI-краулерами | 5–15% — это норма | Рост больше чем в 3 раза | Проверить, не идёт ли массовый сбор данных для обучения |
3. Как это делать: от одной команды до недельного отчёта
Команде из одного человека не нужна дорогая платформа для анализа логов. Минимальный набор инструментов — три вещи: GoAccess для наглядного недельного отчёта, awk для почасовой статистики и ручной полный аудит раз в месяц. Ниже два сценария, которые можно применять сразу.
Сценарий 1: найти URL с наибольшим числом ошибок за сегодня. В каталоге логов Nginx выполните: awk ‘$9 ~ /^5/ {print $7}’ access.log | sort | uniq -c | sort -rn | head -20. Команда извлекает пути всех запросов с 5xx, сортирует их по числу появлений, и первые 20 — это страницы, которые сегодня нужно чинить в первую очередь.
Сценарий 2: посмотреть, сколько раз за сегодня приходили Google и AI-краулеры. awk ‘BEGIN{IGNORECASE=1} /Googlebot|GPTBot|ClaudeBot|bingbot/ {print $http_user_agent}’ access.log | sort | uniq -c | sort -rn. Сгруппировав результат по UA, вы увидите соотношение обычного краулера Google для индексации и краулеров разных AI для чтения. Для сайтов на CDN нужно брать логи источника, а не логи edge — об этом в Глобальное ускорение CDN о разнице между источником и кэшем.
Сценарий 3: сделать для себя недельный отчёт. Запустите GoAccess и генерируйте HTML-отчёт раз в неделю. Смотрите на четыре группы цифр: сколько занимают 4xx и 5xx в распределении кодов статуса, десять самых запрашиваемых URL, кривую трафика по часам и долю краулеров в разбивке по UA. Смотрите этот отчёт каждое утро понедельника — это гораздо эффективнее, чем листать логи время от времени. Полезная привычка — записывать каждую найденную аномалию в небольшую таблицу: через три месяца, оглянувшись назад, вы увидите закономерности.
| Частота | Действие | Результат | Время |
|---|---|---|---|
| Ежедневно | Беглый взгляд на панель ошибок 5xx | Есть сбой или нет | 2 минуты |
| Еженедельно | GoAccess формирует отчёт за прошлую неделю | Топ путей, топ краулеров, распределение кодов статуса | 10 минут |
| Ежемесячно | Полный аудит 404 и подозрительных UA | Список битых ссылок, список IP для блокировки | 1 час |
| Ежеквартально | Пересмотреть политику хранения и ротации логов | Убедиться, что диск не переполнится и история доступна | 30 минут |
4. Подводные камни: три самых частых заблуждения
Первая ловушка — считать, что код 200 всегда означает норму. Некоторые плагины атакуют вредоносные сканеры, и в ответ приходит 200 плюс поддельная страница: статус в порядке, а содержимое подменено. Такое надо выявлять по «аномально малому числу байт в ответе» или по «появлению в URL параметров, которых там быть не должно», а в серьёзных случаях действовать по После взлома сайта сценарию.
第二个坑是只看实时、不留历史。日志不按切割和保留策略管理,磁盘被打爆或者三个月后想查一次”三月那次故障到底什么时候开始的”,根本翻不到。建议按天切割、保留 90 天热数据、超期压缩归档。
Третья ловушка — принимать заходы краулеров за успехи в SEO. То, что Googlebot пришёл десять тысяч раз, не значит, что вы хорошо ранжируетесь, — это значит лишь, что он снова и снова обходит сайт. С SEO реально связано другое: «нормально ли обходятся важные страницы», и смотреть на это надо в связке с данными индексации, а не хвастаться объёмом краулинга в отрыве от всего. О связи производительности и обхода читайте в Core Web Vitals о влиянии на полноту обхода пауками.
| Заблуждение | Внешнее проявление | Настоящая причина | Как правильно проверять |
|---|---|---|---|
| Резкий рост трафика — это хорошо | Число запросов выросло втрое | Какой-то краулер начал активно обходить | Смотреть долю реальных людей с дедупликацией по UA |
| Если везде 200, значит всё в порядке | Все коды состояния в норме | Взломщики вернули поддельную страницу | Проверить выборку аномально малых ответов и подозрительных параметров |
| Много обходов Google = хорошие позиции | Высокое число запросов от Googlebot | Он снова и снова обходит низкокачественные страницы | Сопоставить объём индексации с реальными позициями |
| 404 можно игнорировать | Доля выглядит невысокой | Старые внешние ссылки теряют вес | Для TOP 404 поставить 301 на соответствующую новую страницу |
FAQ: частые вопросы
Чем отличаются форматы логов Nginx и Apache, универсальны ли методы анализа?
Как отличить настоящий Googlebot от поддельного краулера?
Сколько хранить логи, чтобы этого хватало?
Нужно ли обрабатывать все ошибки 404?
Точны ли логи сервера после подключения CDN?
Вижу в логах GPTBot и ClaudeBot — это хорошо или плохо?
В заключение
Ценность анализа логов не в том, чтобы «смотреть трафик», а в том, чтобы «разбирать ошибки и различать, кто пришёл». Для независимого сайта, которым занимается один человек, достаточно раз в неделю потратить десять минут на отчёт и раз в месяц — час на полный аудит, чтобы закрыть 90% типичных проблем: где ошибки, где битые ссылки, какие краулеры съедают ваш канал, откуда на самом деле приходят живые люди.
Три шага на практике: первый — привести формат логов к combined и хранить их по дням 90 дней; второй — сначала следить за долей ошибок 5xx и подавать сигнал при превышении 1%, затем заняться TOP 404; третий — считать краулеров и живых людей отдельно и не обманывать себя общим числом посещений. С ритмом обслуживания сайта можно сверяться по графиком обслуживания сайта— там список из шести дел на каждый месяц.
Фраза, которую стоит запомнить: логи сервера — это не панель трафика, а запись с места аварии: сначала найдите, куда врезалась машина, а потом считайте, сколько их проехало по дороге.
