Аудит серверных логов сайта в 2026 году: что искать

Я обычно начинаю аудит серверных логов не с «поиска ошибок», а с ответа на простой вопрос: что именно сайт делает не так в 2026 году. На деле в access.log и error.log видно больше, чем в отчётах аналитики, если знать, куда смотреть.

Какие логи смотреть первыми

Если у вас обычный сайт на WordPress, Битрикс или Laravel, я бы в первую очередь открыл два файла: access log и error log. Иногда полезны ещё отдельные логи nginx, PHP-FPM и приложения, но старт всегда один и тот же.

• access.log — кто пришёл, на какой URL, с каким кодом ответа, каким user-agent и откуда.
• error.log — PHP-ошибки, проблемы с upstream, таймауты, 502/504, падения модулей.
• лог CMS — если есть свой журнал ошибок, его тоже надо смотреть. Особенно в Bitrix и Laravel.

По опыту, именно access.log чаще всего выдаёт реальную картину. В error.log может быть тишина, а сайт при этом уже теряет трафик из-за 404, плохих редиректов или мусорных запросов ботов.

Что искать в access.log

Я обычно иду по списку, а не хаотично. Так быстрее понимаешь, что ломается и где именно.

1. Массовые 404

Это первое, что я проверяю. Не раз видел ситуацию: сайт живой, но тысячи запросов идут на несуществующие URL. Причина может быть банальной — старые ссылки, неправильные редиректы после редизайна, битые картинки, мусор от ботов.

Особенно настораживают:

• одинаковые 404 с разных страниц;
• запросы к старым каталогам и карточкам товаров;
• сканирование типов файлов вроде .env, .bak, .sql, wp-login.php на чужих движках;
• 404 на ресурсы, которые должны существовать по логике проекта.

Если 404 много, я почти всегда параллельно смотрю материал про 404-мониторинг и уведомления о битых ссылках в 2026. Это экономит время, потому что дальше уже понятно, что именно автоматизировать.

2. Петли редиректов и странные 301/302

Иногда в логах видно не просто редирект, а целую карусель: HTTP → HTTPS → www → без www → снова HTTPS. Или ещё хуже — бесконечная цепочка между двумя URL. Честно говоря, это плохая идея оставлять без контроля.

Я смотрю на последовательность кодов ответа и на одинаковые пары URL. Если один и тот же запрос успевает получить несколько редиректов подряд, это уже повод проверить правила в nginx, .htaccess и настройки CMS.

3. Всплески 403 и 401

403 и 401 я не игнорирую. Да, иногда это нормальная защита админки. Но если запросов слишком много, значит кто-то стучится туда, куда не надо, либо защита настроена слишком агрессивно и режет живых пользователей.

На моей практике проблемы с 403 часто всплывают после обновлений WAF, смены правил на сервере или включения жёсткого Cloudflare-защиты. В логах видно, кто именно получает отказ: бот, админка, API-метод, фронтенд-ресурс.

Что искать в error.log

Error.log полезен не только когда сайт уже упал. Я бы даже сказал, что заранее в нём видно будущие проблемы.

1. PHP warnings и fatal errors

Если у вас PHP 8.1, 8.2 или 8.3, а код писали много лет назад, в логах часто всплывают несовместимости. Это не всегда сразу превращается в белый экран, но уже сигнал.

Ищите:

• Fatal error;
• Uncaught Exception;
• Deprecated;
• Undefined array key;
• Trying to access array offset on value of type null.

Да, deprecated-ошибки многие игнорируют. И зря. Сегодня это просто шум, а завтра после очередного обновления PHP сайт начнёт сыпаться в ошибках. По опыту, лучше сразу чистить такие места, чем потом срочно откатываться.

2. Ошибки upstream и таймауты

Если nginx пишет upstream timed out, connect() failed или bad gateway, я смотрю не только веб-сервер, но и PHP-FPM, базу данных и тяжёлые запросы. На проектах с MySQL 5.7 и MySQL 8.0 причина может быть в одной медленной выборке, которая тянет весь сайт.

Здесь уже полезно сопоставить логи с нагрузкой на сервер. Иногда проблема не в коде как таковом, а в том, что запрос к базе стал слишком тяжёлым после роста каталога или кэша нет там, где он нужен.

Если в логах регулярно всплывают 502 и 504, я обычно отдельно проверяю связку веб-сервера и PHP. Подробный разбор похожих ситуаций есть в статье Как исправить 502 Bad Gateway и ошибки прокси на сайте.

3. Ошибки доступа к файлам и правам

Ещё один частый сценарий — сайт вроде бы работает, но часть функций ломается из-за прав на файлы, отсутствующих директорий, неправильного владельца или ограничений в контейнере. В логах это обычно видно сразу: Permission denied, No such file or directory, Failed to open stream.

Особенно это заметно после переноса сайта, обновления CMS или ручной правки файлов на сервере. И тут уже не надо гадать — лог сам показывает, что именно не найдено и где лежит проблема.

Какие паттерны в логах указывают на SEO-проблемы

Серверные логи — это не только про технику. По ним отлично видно, где сайт теряет индексацию и какой мусор мешает поисковикам.

1. Боты заходят на неиндексируемые или бесполезные URL

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

Я бы отдельно посмотрел, не попадают ли в лог страницы с параметрами, которые потом дублируются в индексе. Для такой задачи полезен соседний материал: Как найти и убрать индексируемые страницы с параметрами в 2026.

2. Поисковые боты получают 404, 301 и 5xx вместо нормального ответа

Если бот часто видит 404 или цепочку редиректов, это уже не просто техническая мелочь. По сути, вы сами мешаете поисковику нормально обойти сайт. А если в ответах есть 5xx, индексирование будет проседать ещё сильнее.

Я обычно проверяю, какие именно URL бот трогает чаще всего. Иногда всё сводится к одной кривой карте сайта, иногда — к старым ссылкам в меню, которые никто не заметил после переезда.

3. Слишком много обращений к sitemap, robots.txt и служебным файлам

Это не всегда ошибка, но иногда видно, что бот зациклился на служебных файлах или получает некорректные ответы. Тогда я уже лезу в robots.txt, sitemap.xml и серверные правила. Тут хорошо помогает отдельный аудит robots, и я бы не откладывал его в долгий ящик.

Как отличить живую проблему от шума ботов

Это, пожалуй, самый частый вопрос. В логах всегда много мусора, и если не уметь его отделять, можно потратить весь день впустую.

Я ориентируюсь на несколько вещей:

• повторяемость — проблема появляется регулярно, а не один раз;
• масштаб — ошибка идёт массово или затрагивает только один URL;
• тип клиента — реальный браузер, поисковый бот, подозрительный сканер;
• корреляция — совпадает ли всплеск в логах с жалобами пользователей, падением конверсии, ростом отказов или ошибками в CRM.

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

Как организовать аудит, чтобы не потеряться в логах

Серверные логи без системы — это просто длинный текстовый файл. Я обычно делаю аудит в три шага.

1. Сначала ограничиваю период — например, последние 24 часа, а если ищу инцидент, то конкретный промежуток по минутам.
2. Потом фильтрую по статусам — 4xx, 5xx, редиректы, подозрительные запросы, поисковые боты.
3. После этого сопоставляю с изменениями — релиз, обновление плагина, правки шаблона, миграция, смена CDN, настройка кеша.

Если проект большой, я не советую хранить логи «как есть» без ротации и архивирования. Иначе однажды вы получите гигантский файл, который неудобно анализировать и который может съесть место на диске. Для этого у меня обычно отдельно настраивается log rotation и архивирование.

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

Когда аудит логов лучше доверить специалисту

Если сайт небольшой, вы ещё можете разово посмотреть логи сами. Но когда есть высокая посещаемость, магазин, интеграции с CRM, фильтры, личный кабинет и API, ручной просмотр быстро превращается в мучение.

Я бы однозначно рекомендовал привлекать специалиста, если:

• в логах много 5xx, а причина непонятна;
• после обновления CMS сайт начал вести себя странно;
• поисковики перестали нормально обходить важные страницы;
• есть подозрение на ботов, сканирование или попытки взлома;
• нужно не просто посмотреть ошибки, а ещё и понять, что править в коде, nginx или конфигурации PHP.

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