Как использовать логи сервера для оптимизации сайта

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

Полученные данные можно использовать для улучшения качества сканирования сайта и общего уровня поисковой оптимизации проекта. Регулярный просмотр логов даст понимание, как увеличить рост позиций проекта в поисковой выдаче, общий объем трафика, количество конверсий и продаж.

Вот как оценивает значимость файлов логов сервера ведущий аналитик компании Google Джон Мюллер:

Используя данные логов сервера, вы можете проанализировать поведение поисковых роботов и ответить на важные для вас вопросы. Например:

• Какие коды состояния страниц возвращаются?
• Какие проблемы с доступностью контента сайта были обнаружены во время сканирования?
• Какие типы страниц редко посещают поисковые роботы?
• Какие URL просматриваются чаще всего?
• Какие типы контента просматриваются чаще всего?
• О каких страницах сайта поисковые системы не догадываются?
• Эффективно ли расходуется краулинговый бюджет сайта?

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

О том, что такое логи сервера и как их использовать с пользой для SEO, пойдет речь в этой статье.

Что такое логи сервера и для чего они используются?

Логи сервера – файлы с веб-сервера, содержащие записи запросов (или «обращений»), которые получает сервер. Полученные данные хранятся анонимно и содержат следующую информацию:

• время и дата, в которую был сделан запрос;
• IP-адрес запроса;
• запрошенный URL/контент;
• пользовательский агент.

Для унификации данных, полученных с разных версий серверов, записи логов специально запрограммированы для вывода в формате журнала консорциума W3C. 

Структура строки журнала чаще всего содержит стандартный набор элементов, которые дают информацию о сеансе. Рассмотрим для примера следующую запись:

127.0.0.1 – frank [10/Oct/2000:13:55:36 -0700] "GET /apache_pb.gif HTTP/1.0" 200 2326 "http://www.example.com/start.html" "Mozilla/4.08 [en] (Win98; I ;Nav)"

127.0.0.1 – имя удаленного хоста, IP-адрес.

frank – идентификатор пользователя, запрашивающего страницу.

[10/Oct/2000:13:55:36 -0700] – дата, время и часовой пояс для конкретного запроса в формате strftime.

"GET /apache_pb.gif HTTP/1.0" – это одна из двух команд (другая – «POST»), которую можно выполнить. «GET» извлекает URL, а «POST» отправляет что-либо, например, комментарий на форуме. Вторая часть – это URL, к которому осуществляется доступ. Последняя часть – версия HTTP, к которой осуществляется доступ.

200 – код состояния документа, который был возвращен сервером.

2326 – размер в байтах документа, который был возвращен сервером.

"http://www.example.com/start.html" — заголовок HTTP-запроса «Referer». Это страница, которая ссылается или включает в себя документ /apache_pb.gif.

"Mozilla/4.08 [en] (Win98; I ;Nav)" — заголовок HTTP-запроса «User-Agent». Это информация, которую клиентский браузер сообщает о себе.

Абсолютно каждый запрос к содержимому вашего веб-сервера размещается в файле журнала. Это важно, потому что вы можете точно видеть, какие ресурсы поисковые системы сканируют на сайте и какие проблемы со сканированием возникли или могут возникать.

Пример:.

В ходе анализа логов сервера одного из проектов на платформе WP была обнаружена проблема – CMS генерировала большое количество «мусорных» страниц путем добавления параметров в URL-адреса основных версий. При этом данные страницы не отображались в отчетах Google Search Console и не были выявлены в ходе сканирования сайта десктопными парсерами. А вот Google обнаружил данные страницы и добавил в индекс. Это привело к множественному дублированию контента и пустой трате краулингового бюджета сайта. Записи логов сервера помогли выявить подобные страницы и устранить механизм их генерации.

Доступность к просмотру логов сервиса дает возможность идентифицировать потенциальные «проблемные» страницы. Анализировать нужно следующие показатели:

• Общее количество посещений страниц поисковыми роботами.
• Частота сканирования конкретной страницы.
• Коды ответа сервера.
• Сканирование приоритетных и активных страниц.
• Использование ресурса бота и трата краулингового бюджета.
• Дата последнего сканирования страниц.

Доступ к файлам журнала сервера

Различные типы серверов хранят и управляют своими файлами журналов по-разному. Не будем подробно вдаваться в процесс извлечения файлов журналов сервера, так как он детально описан в документации к разным типам серверов.

Официальные руководства по поиску и управлению файлами логов сервера:

1. Доступ к файлам журнала Apache (Linux)
2. Доступ к файлам журнала NGINX (Linux)
3. Доступ к файлам журнала IIS (Windows)

Извлечение и обработка данных журнала сервера

Извлечение данных

Существует множество инструментов для работы с файлами журналов сервера. Они имеют как схожие типы инструментов обработки и анализа, так и уникальные функции –все зависит от цели работы с данными журналов. Ниже рассмотрим наиболее популярные среди них.

При выборе сервиса для анализа логов важно знать разницу между статическими инструментами и инструментами анализа в режиме реального времени.

1. Статические инструменты

Данный тип инструментов дает возможность анализировать только статический файл. Основной недостаток – нет возможности выбрать временной период предоставления данных. Чтобы проанализировать другой период, необходимо выгрузить новый файл журнала.

Мой любимый инструмент для анализа статических файлов журналов – WebLog Expert. Это быстрый и мощный анализатор логов сервера:

Он предоставляет обширную информацию о посетителях вашего сайта: статистику активности, доступ к файлам, пути перехода на сайт, информацию о ссылающихся страницах, поисковых системах, браузерах, операционных системах и многое другое. WebLog Expert может анализировать логи веб-серверов Apache, IIS и Nginx. Он может читать форматы сжатых файлов журналов GZ и ZIP, поэтому вам не нужно распаковывать их вручную.

Не менее популярный и мощный инструмент для анализа логов сервера – Screaming Frog Log File Analyzer. Включает в себя все функции предыдущего сервиса. Но имеет более гибкий функционал по части удобства анализа данных логов сервера и формирования отчетов. Дает возможность импортирования списка URL-адресов, например, из файла sitemap.xml веб-сайта, и сопоставления их с данными файла логов сервера. Это помогает найти потерянные или неизвестные страницы, которые Googlebot не просканировал.

Среди других статических инструментов анализа данных журнала сервера можно выделить:

• Log Analyzer: Trends – позволяет анализировать изменения основных параметров веб-сайта как графически, так и численно. Программное обеспечение предлагает более 20 стандартных отчетов, которые включают отчеты «Хиты», «Уникальные посетители», «Посещенные страницы», «Ссылающиеся сайты», «Поисковые фразы», «Переходы» и отчеты с использованием других параметров веб-сайта.

• Web Log Explorer – поддерживает более 43 форматов файлов журналов. Может автоматически распознавать форматы логов сервера, извлекать сжатые файлы журналов, обрабатывать несколько файлов журналов и загружать журналы из различных источников: локальных или сетевых источников, FTP или базы данных через ODBC. Web Log Explorer может читать самые популярные форматы сжатых файлов журнала: BZIP2, GZIP, ZIP, 7z, rar и другие – их не нужно распаковывать вручную.

2. Инструменты анализа в режиме реального времени

Данный тип инструментов дает прямой доступ к журналам сервера. Сервисы данной группы устанавливаются в программную среду сервера и мониторят в режиме онлайн все доступные изменения. Преимущество – возможность выбрать любой промежуток времени для анализа данных.

Анализ и визуализация данных нисколько не уступают, а в некоторых случаях и превосходят статические инструменты.

Среди инструментов анализа журналов сервера в режиме реального времени можно выделить:

• GoAccess – сервис был спроектирован как быстрый анализатор логов на основе терминалов. Его основная идея заключается в том, чтобы быстро анализировать и просматривать статистику веб-сервера в режиме реального времени без необходимости использовать браузер. GoAccess может генерировать полный автономный отчет в реальном времени в формате HTML, а также JSON и CSV отчеты.

• Logstash – инструмент обработки данных на стороне сервера с открытым исходным кодом, который одновременно получает данные из множества источников. Подходит для сбора данных журналов сервера, их хранения и анализа.

• Splunk – программное обеспечение создано для поддержки процесса индексации и дешифрования журналов любого типа, будь то структурированные, неструктурированные или сложные журналы приложений.
• Octopussy – менеджер журналов, основанный на Perl. Его основная функциональность заключается в анализе журналов, создании отчетов на основе данных журналов и предупреждении администрации о любой соответствующей информации.

• Seolyzer – гибкая система, которая позволяет контролировать множество параметров сайта в режиме реального времени. Благодаря анализу логов Seolyzer.io вы можете немедленно реагировать на проблему, которая влияет на поисковую оптимизацию проекта.

3. Обработка и анализ данных в среде Microsoft Excel (Google Spreadsheet)

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

Это одновременно самый простой и самый времязатратный способ анализа логов сервера. У данного способа есть один существенный недостаток – количество анализируемых строк ограничено ресурсами вашего компьютера. Решить данную проблему можно путем разбиения исходного файла на несколько частей. К преимуществам относится мощнейший функционал по части статистической обработки данных, который недоступен для вышеперечисленных сервисов.

Алгоритм действий при использовании данного метода следующий:

• Конвертировать .log в .csv.

Когда вы извлечете журнал веб-сервера, получите файлы с расширением .log. Преобразовать их в формат, понятный для Excel, очень просто: выберите файл и введите расширение файла как .csv. Excel откроет файл, не повредив содержимое.

• Преобразовать строки в столбцы.

Открытие в Excel обычно приводит к тому, что данные журнала сервера записываются в один столбец. Чтобы упорядочить набор данных в управляемый формат, нужно распределить данные по нескольким столбцам. Для удобства воспользуйтесь функцией «Текст в столбцы»:

• Определиться с размером выборки.

Открыв файл в Excel, проверьте, сколько строк данных в нем содержится. Хороший размер выборки/диапазон для работы – 60–120 тыс. строк. При бо́льшем объеме выборки данных Excel может перестать отвечать на запросы, как только вы начнете фильтровать, сортировать и комбинировать наборы данных.

В результате вы получите набор данных о посещениях страниц вашего веб-сайта:

Анализ данных

После извлечения и расшифровки всех данных файла логов сервера можно приступать к основной цели всего этого процесса – анализу посещений страниц сайта.

! Главное правило – перед началом необходимо определиться с основной целью анализа. В противном случае высока вероятность загрузнуть в огромных массивах данных и не получить никакой пользы.

! Второй момент – не забудьте отсортировать свои данные с помощью пользовательского агента. Анализируя Googlebot для компьютеров, Googlebot для смартфонов и Yandexbot вместе, вы не найдете никакой полезной информации.

! Последнее – проверьте, действительно ли вебсканер является Гуглботом. Или это подмена личности от спам-ботов и скреперов? Чтобы проверить, действительно ли веб-сканер, обращающийся к вашему серверу, является роботом Google, запустите обратный поиск DNS, а затем прямой поиск DNS. Подробный алгоритм действий описан в Справочном центре Google для веб-мастеров.

Последовательность анализа

Вариантов может быть множество. Все зависит от выбранной цели анализа. Различные сценарии анализа – это контрольный чек-лист при работе со списком просканированных страниц. Рассмотрим наиболее популярные из них.

Частота сканирования определенным агентом пользователя>

Создание сводной таблицы и диаграммы на основе свойства timestamp (date) и фильтрации с помощью определенных пользовательских агентов. Для компьютеров используйте Googlebot, для смартфонов Googlebot, Googlebot Video, Googlebot Images и т.д. (полный список юзер-агентов поисковых роботов Google доступен по ссылке). Это может быть чрезвычайно полезно для быстрого выявления аномалий с конкретными пользовательскими агентами поисковой системы.

Дата последнего сканирования страницы

Анализ файла журнала сообщает, когда Google сканировал определенную страницу в последний раз. Таким образом, можно оценить, насколько быстро обновленный контент определенной страницы переиндексируется.

URL-адреса, которые чаще и реже всего сканируются поисковым роботом

Анализ количества посещений конкретных страниц позволяет увидеть, где поисковые системы проводят большую часть своего времени при сканировании, а также сегментировать области, которые стали реже всего обходиться роботом. Просмотрев данные, можно определить типы URL, которые поисковым сканерам просто не нужны (так называемые, отходы сканирования). Анализ журналов также поможет определить наиболее популярные страницы. Таким образом можно узнать, являются ли наиболее посещаемые ботом страницы важными с точки зрения поисковой оптимизации сайта. Это позволит избежать игнорирования некоторых страниц или отдельных разделов сайта.

Пример: В ходе анализа поисковой оптимизации проекта была обнаружена проблема со сканированием и индексацией страниц фильтров. Логи сервера показали, что Гуглбот посещает их реже аналогичных типов страниц. После оптимизации внутренней перелинковки фильтровых страниц с наиболее часто посещаемыми разделами сайта их ценность возросла – Гуглбот стал чаще сканировать фильтровые страницы.

HTTP-ответ сервера

Сегментация по ответу заголовка сервера позволяет быстро оценить ошибки сканирования, с которыми сталкиваются поисковые системы. Выборка из URL-адресов и кодов ответа сервера покажет, с какими ошибками сталкивается поисковая система. Одинаковы ли они при сканировании определенного URL-адреса или целого диапазона однотипных страниц. Понимание проблемы даст возможность скорректировать стратегию устранения подобных ошибок.

Наиболее часто встречаемые ответы сервера при анализе журналов:

• 500 – Ошибка сервера.
• 404 – Страница не найдена.
• 302 – Временное перенаправление.
• 301 – Постоянный редирект.

Время, затраченное на сканирование

Анализ времени, затраченного на сканирование страницы (измеряется в миллисекундах), показывает, какие запрошенные URL-адреса в среднем были загружены быстрее/медленнее. Объединение этих URL-адресов по каталогам позволит измерить производительность по разделам сайта с целью выявления наименее производительных.

Типы файлов

Анализ типов файлов позволит определить, доступны ли для сканирования Гуглботом, к примеру, необходимые CSS/JS файлы или существуют проблемы с их доступностью. В то же время данный параметр покажет, не сканируются ли ненужные форматы файлов, тратя при этом краулинговый бюджет сайта.

Оценка краулингового бюджета

Анализ журналов сервера также помогает определить, как расходуется бюджет сканирования. Например, тратит ли Google слишком много времени на сканирование изображений.

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

Пример: В ходе анализа логов сервера крупного ecommerce-проекта было обнаружено, что треть краулингового бюджета сайта тратится на обход ненужных страниц, содержащих каноническую ссылку на основные версии страниц сайта. Данная ссылка была размещена в коде, определялась в ходе парсинга сайта десктопными сканерами, но не распознавалась Гуглботом. При этом страницы добавлялись в индекс поисковой системы, генерируя дубли. Выявление и устранение причины нераспознавания поисковым ботом канонической ссылки решило проблему, позволив использовать ценный краулинговый бюджет для сканирования более приоритетных страниц сайта и устранив дублирование контента.

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

Это далеко не полный перечень сценариев анализа данных логов сервера. Объедините журналы сервера с другими источниками данных. Это откроет новый уровень понимания контекста логов сервера, который может не дать анализ только данных журналов. Совместите журналы сервера с другими источниками: данными Google Analytics, отчетами Search Console по индексации/ключевым словам/кликам/показам, xml-картами сайта, данными сканирования сайта Netpeak Spider или Screaming Frog и начинайте задавать вопросы:

• Какие страницы не включены в sitemap.xml, но сканируются поисковыми роботами?
• Какие страницы включены в файл Sitemap.xml, но не сканируются?
• Часто ли сканируются страницы, приносящие конверсии?
• Большинство просканированных страниц находятся в индексе?
• Сканируются ли страницы, заблокированные в Robots.txt?

Плацдарм для анализа данных неограничен. Все зависит только от ваших целей и наличия данных. Вы можете быть удивлены находками, которые вы обнаружите в результате.