Лог — файл с записями о событиях, расположенных в хронологическом порядке.
Зачем анализировать лог-файлы? — спросите вы.
Для того, чтобы получить идеи и гипотезы, которые появились бы при анализе этого источника данных или при обогащении его другими данными.
Все программы и сервисы Linux ведут лог-файлы, и самыми важными для нас с точки зрения SEO являются:
- веб-сервера;
- сервера базы данных;
- логи самой системы.
Анализ логов позволяет:
- увидеть сбои в работе сервера, CMS, БД и т.п.;
- определить параметры посещения (откуда был выполнен переход, какой браузер использовался, как часто выполняются переходы и т.п.);
- понимать как сканеры поисковых систем ведут себя на сайте, чему отдают приоритет, какие ошибки встречаются на их пути, найти непросканированные страницы и т.д.
Источники данных и их месторасположение
Файлы журналов с логами доступа к сайту хранятся на сервере в папке /var/log, и имеют, как правило, в своем названии слово «access».
Подавляющее большинство сайтов работают под управлением web-серверов Apache или Nginx. Оба они записывают данные в 2 файла: access.log — для записи посещений, error.log — для записи ошибок.
К логам сервера можно отнести и лог-файлы интерпретатора PHP (php-fpm) и его файлы ошибок.
Содержимое и структура лог-файлов могут различаться в зависимости от используемой конфигурации веб-сервера (Apache, Nginx, IIS и др.).
Логи web-сервера Apache
Обычно эти файлы создаются отдельно для каждого сайта и имеют названия site.ru.access.log и site.ru.error.log.
Классическая структура журнала запросов access.log, создаваемая модулем mod_log_config сервера Apache, выглядит так:
1 2 3 4 | 95.12.23.13 - - [08/Jul/2021:10:33:13 +0300] "GET /catalog/page.html HTTP/2.0" 200 2346 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.124 Safari/537.36" |
где:
- 95.12.23.13 — IP-адрес, с которого был сделан запрос;
- [08/Jul/2021:10:33:13 +0300] — дата, время и тайм зона;
- GET — метод HTTP-запроса;
- /catalog/page.html — запрашиваемый ресурс;
- HTTP/2.0 — протокол, по которому прошел запрос;
- 200 — код ответа (состояния) HTTP;
- 2346 — размер объекта (не включая заголовки ответа) в байтах, который был возвращен клиенту;
- Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.124 Safari/537.36 — заголовок HTTP-запроса User-Agent. Это идентифицирующая информация, которую сообщает о себе клиентский браузер.
В официальной документации содержится более подробная информация о настройках и чтении журнала логов Apache.
Инструменты анализа логов
При выборе инструмента важно, чтобы он был гармонично встроен в рабочий процесс, а не проводился разовый аудит.
Для небольших сайтов можно использовать Excel или Google Docs. Минус этих инструментов — приходится все делать вручную и они не масштабируемы.
Screamingfrog Log File Analyzer — платный продукт (бесплатно можно добавить 1 проект и проанализировать 1000 строк). Инструмент начального уровня и подходит для сайтов малого и среднего размера. Имеет простой интерфейс, полезные заранее заданные отчеты, но не имеет возможности совместного использования. Файлы журналов подгружаются в программу вручную.
Другое решение — Elastic Stack, который включает в себя 4 бесплатных инструмента с открытым исходным кодом: Elasticsearch, Logstash, Kibana, Filebeat. Позволяет полностью автоматизировать процесс загрузки логов, настроить дашборды, минус — необходимо установить, настроить и администрировать стек на свой собственной серверной инфраструктуре собственными силами.
Также существуют SaaS-решения: logrunner.io, logz.io, Loggly. Все они основаны на Elastic Stack (ELK) и предназначены для аудита поисковой оптимизации сайта. Плюсы данного решения: работают в режиме реального времени, автоматически подгружают логи, данные с течением времени накапливаются, можно встроить в рабочий процесс SEO, имеется возможность делиться отчетами.
Анализ логов и отчетов
Анализ логов сервера — это прежде всего поиск аномалий. А для этого предварительно необходимо собрать данные.
Вот некоторые направления исследования при SEO-аудите логов сервера:
- какие боты и на сколько регулярно посещают сайт, какие сходства и различия в их поведении;
- сравните объемы сканирования Яндекс (Google) бота для десктопов и бота для мобильных устройств;
- какие страницы чаще всего сканируются поисковыми ботами;
- коды ответов HTTP по каталогам и страницам и их динамика;
- сегментирование ошибок сканирования (диапазон кодов состояния 4xx) для каждого поискового бота;
- объем и постоянство ошибок из диапазона кодов состояния 5xx — например, генерирует ли постоянно какой-то из поисковых ботов одну и ту же ошибку;
- определение наиболее и наименее часто сканируемые страниц — наиболее часто сканируемые страницы могут использоваться как страницы-доноры (для проставления ссылок на наименее часто посещаемые поисковыми ботами или на новый материал для ускорения индексации);
- сканируются ли новые адреса вообще;
- генерирует ли CMS лишние страницы и посещают ли их поисковые боты — обычно это вызвано дополнительными параметрами в URL. Это вызывает дублирование контента и расходует краулинговый бюджет.
Объединение данных с другими источниками
Следующий уровень анализа — обогащение данных из файлов журнала данными из других источников.
Например, можно объединить XML-карту сайта с данные сканирования крауйлерами. Иногда случается, что не все страницы сайта сканируются из-за ошибок в структуре веб-сайта или установленной директивы noindex. Также можно проверить индексируются ли неканонические страницы, и если да, то в каком объеме.
Можно объединить данные с данными из Яндекс Метрики, Google Analytics, Яндекс Вебмастер, Google Search Console и т.д.
