Лог-файл

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

Что такое лог-файл

Лог-файл (от английского log file, дословно — «журнальный файл») — это хронологический дневник сервера, в котором каждая строка соответствует одному событию. Когда браузер запрашивает страницу, сервер не просто отдает HTML — он фиксирует: кто запросил (IP-адрес), что запросил (URL), когда (метка времени до секунды), какой ответ дал (HTTP-код), сколько данных передал (размер в байтах), откуда пришел пользователь (referer) и какой браузер или бот использовал (User-Agent). Все это складывается в одну строку стандартного формата Combined Log Format — именно его используют Apache, Nginx и большинство облачных балансировщиков по умолчанию. Строка выглядит как набор полей, разделенных пробелами, и машина записывает факты без интерпретации и без пропусков.

История лог-файлов начинается в 1990-х, когда первые веб-серверы NCSA httpd и CERN httpd ввели стандарт Common Log Format. Тогда логи были единственным способом понять, кто посещает сайт: никаких счетчиков, никакого JavaScript-трекинга не существовало. Позже появился расширенный Combined Log Format с полями referer и User-Agent, и именно он стал де-факто стандартом для всей индустрии. С ростом сложности приложений появились дополнительные типы: логи PHP, баз данных, CDN. Крупный e-commerce генерирует сотни гигабайт логов в сутки, и их обработка требует специализированных инструментов — ELK Stack, Graylog или облачных сервисов Datadog и Splunk.

В digital-маркетинге лог-файлы занимают особое место, которое не могут заменить никакие аналитические счетчики. Яндекс.Метрика и Google Analytics показывают поведение людей — но молчат о роботах. Краулер Googlebot или Яндекс-бот не запускает JavaScript, не активирует счетчик и не попадает в отчеты по трафику. Зато он оставляет след в каждом access.log: строку с User-Agent «Googlebot/2.1» и временем обхода. Это означает, что только через лог-файлы SEO-специалист видит реальный краулинговый бюджет — сколько страниц обходит бот за сутки, какие URL он посещает чаще всего, на каких страницах получает ошибки 404 или 500, и тратит ли он время на страницы, которые вообще не нужно индексировать (дублирующие параметры URL, страницы пагинации, фильтры категорий).

Понимание лог-файлов критично для любого специалиста, который отвечает за видимость сайта в поиске или за его техническое здоровье. Без лог-анализа невозможно проверить, видит ли поисковый робот нужные страницы так же, как их видит пользователь. Нельзя выявить «тихие» ошибки — те, что не крашат браузер пользователя, но дают боту код 500, после чего бот перестает заходить на этот раздел. Нельзя обнаружить паразитный трафик: боты-спамеры, сканеры уязвимостей и конкурентные парсеры нагружают сервер и могут косвенно влиять на скорость ответа для реальных пользователей. Лог-файл — это та точка, где технический SEO встречается с DevOps, и специалист, умеющий читать логи, решает задачи за часы, а не за недели итераций с разработчиками.

Как работает лог-файл

1. Прием запроса и генерация записи. Каждый раз, когда браузер, бот или API-клиент обращается к серверу, сервер обрабатывает запрос и сразу после отправки ответа формирует строку лога. Строка содержит до 10 полей: IP клиента, идентификатор пользователя, дата и время, метод HTTP (GET/POST/HEAD), запрошенный URI, версия протокола, код ответа, размер тела ответа, referer и User-Agent. Запись создается именно после отправки ответа — это значит, что если соединение оборвалось в процессе передачи, в логе всё равно появится строка с кодом 200, но с нулевым или урезанным размером тела.
2. Запись на диск через буфер. Nginx и Apache не пишут каждую строку синхронно на диск — это было бы критически медленно при высокой нагрузке. Записи накапливаются в буфере в памяти и сбрасываются на диск пачками (flush). Директива access_log в Nginx поддерживает параметр buffer=64k flush=5m — «накапливать до 64 килобайт или не дольше 5 минут». При падении сервера последние несколько секунд событий могут не попасть в лог-файл, если буфер не был сброшен — это важно учитывать при диагностике инцидентов.
3. Ротация лог-файлов. Без ротации access.log за год занял бы сотни гигабайт.Systemная утилита logrotate переименовывает текущий файл (access.log становится access.log.1), сжимает в gzip и создает новый пустой файл. Стандартная схема — 14-30 дней в сжатом виде. Для SEO-аудита нужно минимум 30 дней — достаточно для полного цикла обходов Googlebot и выявления паттернов краулинга.
4. Парсинг и агрегация инструментами. Читать сырые лог-файлы вручную невозможно на масштабе тысяч строк. Специализированные инструменты — Screaming Frog Log File Analyser, GoAccess, Logpoint, ELK Stack — парсят файлы, разбивают каждую строку на поля и строят агрегации: топ-URL по числу запросов, распределение HTTP-кодов по дням, активность краулеров по часам. GoAccess обрабатывает файл в 1 ГБ за 10-15 секунд и выдает интерактивный HTML-отчет прямо в терминале. Screaming Frog Log File Analyser ориентирован специально на SEO: сопоставляет URL из логов с данными Google Search Console и показывает, какие страницы бот обходит, но не индексирует.
5. Интерпретация кодов ответа. Ключевой шаг анализа — фильтрация по HTTP-кодам. Код 200 означает успешную отдачу; 301/302 — редиректы, которые тратят краулинговый бюджет; 404 — несуществующие страницы, на которые продолжает ходить бот (обычно из-за внутренних ссылок, которые не обновили); 500/503 — серверные ошибки, которые заставляют бота отступать и снижать частоту обходов. Если в логах Googlebot видит 10-20% строк с кодом 500 в конкретном разделе — Googlebot начинает реже заходить в этот раздел, что напрямую бьет по индексации новых страниц. Анализ распределения кодов ответа для поисковых ботов — стандартный первый шаг технического SEO-аудита.
6. Принятие решений и мониторинг. Результат анализа — конкретные действия: исправить URL с 404 во внутренних ссылках, закрыть параметрические страницы через robots.txt, устранить серверные ошибки в нужных контроллерах. После правок мониторинг логов покажет динамику: вырос ли процент 200 для бота, снизилось ли число обходов бесполезных страниц. Алерты автоматизируют контроль: если доля 5xx превысила 2% за 15 минут — система уведомляет команду.

Виды лог-файлов

• Access log (журнал доступа). Основной тип — фиксирует каждый входящий HTTP-запрос к серверу. В нем видны все посетители: люди, поисковые боты, API-клиенты, мониторинговые сервисы. Для SEO-специалиста access.log — главный источник данных о краулинговом поведении Googlebot и Яндекс-бота: когда заходили, какие URL запрашивали, с какой частотой, на каких страницах получали коды 200 или 301.
• Error log (журнал ошибок). Отдельный файл, куда сервер пишет только нештатные ситуации: синтаксические ошибки конфигурации, проблемы с правами доступа к файлам, ошибки подключения к бэкенду (upstream). Error.log критичен для выявления «тихих» сбоев — тех, что не крашат страницу для пользователя, но возвращают боту 500. Например, ошибка «upstream timed out (110) while reading response header» в error.log Nginx прямо указывает, что PHP-процесс не успевает ответить за отведенное время — бот получает 500, хотя пользователь просто видит медленную загрузку.
• PHP error log (журнал ошибок PHP). Логирует ошибки и предупреждения PHP-интерпретатора, независимо от веб-сервера. Для сайтов на WordPress, Bitrix или кастомных PHP-приложениях этот файл часто содержит предупреждения (E_WARNING, E_NOTICE), которые не ломают страницу, но замедляют генерацию HTML. Регулярный просмотр PHP error log позволяет обнаруживать устаревшие вызовы функций, конфликты плагинов (актуально для WordPress) и утечки памяти ещe до того, как они начнут влиять на пользователей.
• Application log (журнал приложения). CMS и фреймворки ведут собственные логи поверх серверных. WordPress пишет в таблицу БД или отдельный файл при включенном WP Debugging, Magento — в system.log и exception.log. Маркетологу они нужны при отладке интеграций: например, чтобы понять, почему заявка с CF7-формы не прилетела в CRM.
• Security log (журнал безопасности). Генерируется модулями fail2ban, ModSecurity, Nginx rate limiting. Фиксирует заблокированные IP-адреса, попытки SQL-инъекций и перебора паролей. Для SEO критично: если fail2ban блокирует диапазон IP, куда попал Googlebot, бот перестает заходить на сайт — регулярная проверка защищает от ситуации, когда сайт открыт людям, но закрыт для краулера.
• CDN-лог (журнал на уровне сети). Cloudflare, Akamai и AWS CloudFront ведут собственные логи до того, как запрос достигает сервера. CDN-логи показывают распределение трафика по геолокации и процент кеш-хитов. Если Googlebot получает кешированную страницу прямо с CDN, в access.log сервера эта строка не появится — анализ только серверных логов даст искаженную картину краулинга.

Сравнение

Пример использования

Интернет-магазин зоотоваров с трафиком 25 000 визитов в месяц заметил, что органический трафик снижается третий месяц подряд — с 8 200 до 6 100 визитов. Позиции в среднем не изменились, Search Console не показывала критических ошибок, а счетчик Яндекс.Метрики не выявил проблем с загрузкой. Технический специалист выгрузил access.log за 30 дней и отфильтровал строки с User-Agent Яндекс-бота. Выяснилось, что бот обходит 1 200 страниц в сутки — из них 340 страниц (28%) возвращают код 500. Все они принадлежали разделу «Корма для грызунов», который был перенесен на новый шаблон в рамках редизайна.

После нахождения виновного PHP-шаблона (ошибка в функции получения остатков товара, которая не обрабатывала пустой массив) разработчик исправил баг за 2 часа. Лог-файлы за последующие 6 недель показали снижение доли ошибок для бота с 28% до 0,3%. Яндекс-бот за этот период увеличил суточный обход раздела с 340 до 890 страниц, и число проиндексированных страниц выросло с 1 200 до 1 850. Органический трафик восстановился до 8 400 визитов в месяц — прирост 38% к просевшему показателю — без каких-либо изменений в контенте или ссылочном профиле. Вся диагностика заняла 4 часа; без анализа логов команда продолжала бы искать проблему в контенте или ссылках.

Частые вопросы