Лог-файл (от англ. log file — «файл журнала») — текстовый или бинарный файл, в котором программное обеспечение последовательно записывает информацию о своей работе: события, запросы пользователей, ошибки, действия системы.
Что такое лог-файл в контексте веб-сайтов и SEO — главный источник объективных данных о том, что происходит на сайте: какие страницы посещают пользователи, как поисковые роботы сканируют сайт, какие ошибки возникают, какие ресурсы запрашиваются.
Лог-файлы существуют практически в любом программном обеспечении. На веб-сервере это access.log и error.log от Apache или Nginx, на стороне CMS — собственные системные журналы, в браузере — DevTools console log, в операционной системе Linux — /var/log/. Каждый из этих логов содержит свой тип информации.
В SEO-аудите анализ лог-файлов сервера (log file analysis) — отдельная техническая процедура, позволяющая увидеть реальное поведение поисковых роботов на сайте. Это даёт информацию, недоступную из Search Console и других внешних инструментов — детальный учёт каждого визита Googlebot, YandexBot, Bingbot и других сканеров.
Что такое лог-файл
Лог-файл — это последовательный журнал событий, записываемый программой по мере её работы. Каждая строка обычно представляет одно событие: запрос к серверу, ошибку, действие пользователя, системное уведомление.
Главные характеристики лог-файлов:
- Хронологический порядок. Записи добавляются в конец файла по времени, без редактирования предыдущих
- Структурированный формат. Большинство логов следуют стандартизированному формату, что упрощает автоматический анализ
- Объективность данных. Лог-файл фиксирует реальные события, без интерпретации или фильтрации
- Накопление информации. На загруженных серверах логи быстро вырастают — могут достигать гигабайтов в день
- Ротация. Большинство систем регулярно архивируют старые логи и создают новые — для управления размером файлов
В классическом веб-сервере есть два основных лог-файла. access.log записывает каждый HTTP-запрос к серверу — кто, когда, какую страницу запросил, какой ответ получил. error.log фиксирует ошибки и предупреждения — некорректные запросы, проблемы с PHP, сбои подключения к базе данных.
Виды лог-файлов
| Тип лога | Расположение | Содержание |
|---|---|---|
| access.log | /var/log/apache2/, /var/log/nginx/ | HTTP-запросы: IP клиента, время, метод, URL, код ответа, размер ответа, User-Agent, Referer |
| error.log | /var/log/apache2/, /var/log/nginx/ | Ошибки веб-сервера, PHP-warnings, проблемы с конфигурацией |
| PHP error.log | Настраивается в php.ini | Ошибки PHP-скриптов, fatal errors, warnings, notices |
| MySQL slow query log | /var/log/mysql/ | Запросы к базе данных, превышающие порог времени выполнения |
| System log (syslog) | /var/log/syslog (Linux) | Системные события: загрузки, ошибки ядра, остановки сервисов |
| WordPress debug.log | wp-content/debug.log | Ошибки и предупреждения WordPress при включённом WP_DEBUG |
| Cloudflare logs | Веб-интерфейс Cloudflare, API | Запросы, прошедшие через CDN, информация о ботах, DDoS-атаках |
| Application logs | Зависит от приложения | Произвольные логи бизнес-логики — заказы, регистрации, ошибки оплаты |
Для SEO-анализа главный интерес представляют access.log сервера и Cloudflare logs (если используется CDN). Они показывают, как поисковые роботы взаимодействуют с сайтом — какие страницы они сканируют, как часто, с какими ответами.
Формат записей в access.log
Стандартный формат access.log (Common Log Format и Combined Log Format) представляет каждый запрос одной строкой.
Пример записи:
66.249.66.1 - - [15/Mar/2026:14:23:45 +0300] "GET /seo-slovar/page/ HTTP/1.1" 200 12453 "https://google.com/" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"Разбор полей записи:
- 66.249.66.1 — IP-адрес клиента (в данном случае — реальный IP Googlebot)
- – – — два пропущенных поля (RFC 1413 identity и HTTP basic auth, обычно не используются)
- [15/Mar/2026:14:23:45 +0300] — дата, время и часовой пояс запроса
- “GET /seo-slovar/page/ HTTP/1.1” — HTTP-метод, URL запроса, версия протокола
- 200 — HTTP-код ответа сервера (200 OK)
- 12453 — размер ответа в байтах
- “https://google.com/” — Referer (откуда пришёл запрос)
- “Mozilla/5.0 … Googlebot/2.1” — User-Agent (идентификатор клиента — в данном случае поисковый робот Google)
Каждая такая строка — это один HTTP-запрос. На активном сайте за день фиксируются десятки и сотни тысяч таких запросов. Для SEO-анализа важно отфильтровать запросы от поисковых роботов и проанализировать паттерны их поведения.
Анализ лог-файлов для SEO
Log file analysis — отдельный вид SEO-аудита, дающий уникальные данные о поведении поисковых роботов на сайте. Главные вопросы, на которые отвечает такой анализ:
Какие страницы сканирует Googlebot? Полный список URL, которые робот фактически посещает. Сравнение с sitemap.xml показывает, какие страницы остаются без внимания.
Как часто робот посещает разные страницы? Главная страница обычно сканируется чаще, чем глубокие страницы. Если важные страницы посещаются раз в месяц или реже — это сигнал технических проблем.
Какие коды ответов получает робот? Если значительная часть запросов возвращает 404 или 5xx — это проблема. Робот тратит свой crawl budget на несуществующие или нерабочие страницы.
Где тратится crawl budget? Поисковый робот имеет ограниченный бюджет на сканирование каждого сайта. Если он тратит его на параметрические URL, технические страницы, дублированный контент — важные страницы не сканируются.
Действительно ли робот — Googlebot? Многие боты прикидываются Googlebot в User-Agent. Проверка через обратный DNS-запрос (reverse DNS) подтверждает, что IP действительно принадлежит Google. У Googlebot IP относится к зоне googlebot.com.
Какие новые URL обнаруживает робот? Анализ новых, ранее не виденных URL в логах помогает находить страницы, до которых дошёл робот после изменений на сайте.
Влияет ли производительность сервера на сканирование? Если время ответа сервера растёт (видно по разнице времени запроса и ответа), Googlebot снижает интенсивность сканирования. Это нужно отслеживать.
На крупном сайте (от 10 000 страниц) log file analysis даёт информацию, недоступную из других источников. Search Console показывает только обобщённые данные; логи дают детализацию по каждому запросу.
Инструменты анализа лог-файлов
Готовые инструменты для анализа логов:
- Screaming Frog Log File Analyser. Специализированный инструмент за 99–199 USD/год. Удобный интерфейс, фильтры по ботам, экспорт данных, интеграция с другими SEO-инструментами Screaming Frog
- JetOctopus. Облачный SEO-краулер с функцией log file analysis. Платно, от 50 USD/мес. для базовых тарифов
- Botify. Энтерпрайз-уровня инструмент для крупных сайтов. Контрактные цены, минимум от нескольких тысяч USD/год
- Splunk. Универсальный инструмент анализа логов, не только для SEO. Сложный в освоении, но мощный. Платно
- ELK Stack (Elasticsearch + Logstash + Kibana). Бесплатный open-source стек для анализа любых логов. Требует серверной инфраструктуры и настройки
- GoAccess. Лёгкий open-source инструмент с веб-интерфейсом. Запускается прямо на сервере. Бесплатно
- AWStats. Классический инструмент анализа access.log. Бесплатный, но интерфейс устарел
- Самописные скрипты на Python/PHP. Для специфических задач можно написать парсер логов с регулярными выражениями. Подходит для одноразовых анализов
Базовый процесс работы с log files:
- Получить доступ к лог-файлам сервера (через хостинг-провайдера, FTP, SSH или Cloudflare)
- Скачать логи за период анализа (обычно 30–90 дней)
- Загрузить в выбранный инструмент
- Применить фильтры — отделить запросы от поисковых ботов
- Проверить подлинность ботов через reverse DNS
- Проанализировать паттерны посещения, ошибки, crawl budget
- Сформулировать выводы и план технических исправлений
Часто задаваемые вопросы
Где хранятся лог-файлы веб-сервера?
Стандартные расположения в Linux-системах: для Apache — /var/log/apache2/ или /var/log/httpd/, файлы access.log и error.log; для Nginx — /var/log/nginx/, файлы access.log и error.log. На shared-хостинге доступ к логам обычно есть в панели управления (cPanel, ISPmanager) в разделе «Raw Access Logs». Точное расположение зависит от настроек сервера — иногда логи кладут в директорию сайта.
Сколько хранятся лог-файлы?
По умолчанию — обычно несколько недель или месяцев. Большинство хостинг-провайдеров автоматически удаляют логи через 30 дней. На собственном сервере администратор настраивает ротацию: ежедневное создание нового файла со сжатием старого, удаление архивов через заданный период (90 дней — типичная практика). Для долгосрочного анализа важно сохранять копии в собственном хранилище.
Как отличить настоящего Googlebot от фейкового?
Проверка через обратный DNS-запрос. Команда `dig -x IP-адрес` должна вернуть домен из зоны googlebot.com или google.com. Если возвращается что-то другое — это фейковый бот, имитирующий Google. Подделка User-Agent — типичный приём ботов, использующих имя Googlebot для обхода фильтров.
Как часто Googlebot должен посещать сайт?
Зависит от размера, авторитета и частоты обновления сайта. Главная страница популярного новостного ресурса — несколько раз в день. Главная страница среднего бизнес-сайта — раз в день или два. Глубокие страницы редко обновляемого сайта — раз в неделю или месяц. Если робот не посещает сайт неделями, это серьёзный сигнал — нужно проверять Search Console, sitemap, ссылочный профиль.
Можно ли анализировать логи на shared-хостинге?
Да, если хостинг даёт доступ к raw access logs. Большинство белорусских хостеров (hoster.by, Hoster.RU, Active.by) предоставляют такой доступ через панель управления. Если хостинг не даёт логи — это серьёзное ограничение для технической SEO-работы. Альтернатива — переход на VPS или Cloudflare для собственного учёта запросов.
Сколько стоит профессиональный анализ лог-файлов?
В Беларуси услуга разового аудита лог-файлов крупного сайта (от 10 000 страниц) — 500–2500 BYN. Включает сбор данных за 30–90 дней, анализ через специализированные инструменты, отчёт с рекомендациями. На западе аналогичная услуга стоит 1000–5000 USD. Для малых сайтов с менее 1000 страниц log file analysis обычно избыточен — достаточно Search Console.
Какие коды ответов в логах должны вызывать беспокойство?
Все 5xx (5xx ошибки сервера — это критично, особенно если робот часто их получает). Значительная доля 404 — потеря crawl budget. Много 302 редиректов — лучше заменить на 301 для постоянных перенаправлений. 410 для удалённых страниц — это нормально и даже желательно, в отличие от 404. Доля 200 OK должна быть подавляющей — 90%+ от всех запросов поискового робота.
