Буду рассказывать о файлах логов, как их анализировать, в каких задачах их можно применить.
Если вам удобней видео формат, то смотрите тот же материал на YouTube:
Прошу меня извинить. Данная статья является расшифровкой видео с небольшими изменениями. Качество скриншотов будет низким. Также отдельные извинения за водяные знаки с адресом телеграм-канала.
Что можно узнать в логах?
Самая базовая информация: в логах мы можем узнать по каким юзер-агентам на сайт заходят посетители, какие поисковые роботы там гуляют. Также в логах хранятся сами запросы, даты посещения, URL-адреса страниц, а также коды ответов.
В зависимости от сервисов и инструментов, которые будут использоваться в работе, можно будет узнавать более детальную информацию с визуализацией данных.
В зависимости от сервисов и инструментов, которые будут использоваться в работе, можно будет узнавать более детальную информацию с визуализацией данных.
Сервисы и инструменты
Начнем с инструментов, которые встроены в панели хостингов:
Самый распространенный из них — AWStats. В данном случае пример приведен на хостинге Beget. В главном меню есть раздел «Журналы доступа», в котором нужно включить рычажок и установить встроенный софт. Сами отчеты выглядят таким образом:
Веб-сервис goaccess.io – хорошая альтернатива, выглядят данные так:
Тут побольше визуализации. Пример отчета тут.
Log File Analyser
Наверное, самый популярный инструмент среди SEO-специалистов — это Log File Analyser от компании Screaming Frog. В простонародье эту программу называют лягушкой. С этим инструментом и будем работать дальше.
Подготовка
Мы сами (по своему опыту) в первичных рекомендациях всегда выдаем клиенту такой пункт, в котором рекомендуем включать логирование (журнал). При включении логирования данные выгружаются в корневую папку сайта.
Далее, программисту нужно настроить выгрузку этих файлов в облако. В случае, например, если нам не нужны доступы по этому проекту. Соответственно, у SEO-специалистов будет доступ к облаку. Допустим, это Яндекс.Диск. Туда выгружаются в папку все журналы по каждому дню. Специалист может за любой день достать эти данные и закинуть в программу для анализа и проанализировать то, что ему нужно.
Далее, программисту нужно настроить выгрузку этих файлов в облако. В случае, например, если нам не нужны доступы по этому проекту. Соответственно, у SEO-специалистов будет доступ к облаку. Допустим, это Яндекс.Диск. Туда выгружаются в папку все журналы по каждому дню. Специалист может за любой день достать эти данные и закинуть в программу для анализа и проанализировать то, что ему нужно.
Практика
Теперь переходим к практической части. Что можно проанализировать в Log File Analyser?
Статистика обхода сайта роботами
Во-первых, можно узнать, как часто обходится сайт роботами:
На этом скриншоте у нас сглаживание, так скажем, по неделям. Мы можем увидеть, что сайт в целом начал проседать по сканированию по коду ответа 200.
Сканирование по поисковым системам:
И мы таким образом можем понять, что всего лишь за месяц роботы Яндекс стал реже сканировать этот сайт по какой-то причине.
Как можно поступить, чтобы переломить эту ситуацию? Скорее всего над сайтом перестали работать: обновлять контент и, соответственно, нужно все сделать наоборот — то есть нужно начать работать активнее над сайтом, обновлять контент, актуализировать данные, добавлять новые. Также, можно подливать какое-то внешнее ссылочное — это тоже будет позитивно влиять на результаты сканирования.
Как можно поступить, чтобы переломить эту ситуацию? Скорее всего над сайтом перестали работать: обновлять контент и, соответственно, нужно все сделать наоборот — то есть нужно начать работать активнее над сайтом, обновлять контент, актуализировать данные, добавлять новые. Также, можно подливать какое-то внешнее ссылочное — это тоже будет позитивно влиять на результаты сканирования.
Поиск низкокачественных страниц
Следующая задача, которую можно провести — это поиск низкокачественных страниц.
В данном случае на скриншоте выше мы видим, что перед нами какие-то технические страницы Word Press. Если по ним перейти и посмотреть что это такое, то мы столкнемся с таким содержимым:
То есть это просто какая-то сгенерированная информация. Это всё содержимое файла. Таких файлов на самом деле было много по этому проекту. И каким-то образом роботы добирались до этих ссылок.
Вот сам файлик:
Каким-то образом дополнительно генерировалось эти страницы. Без анализа логов мы бы сами вряд ли так быстро смогли бы обнаружить эти страницы.
Потом с этими данными можно дальше работать. Например, закрывать данные страницы от индексации. Если они ещё по какой-то причине попадают в индекс, их соответственно, нужно ещё и выкидывать из индекса.
Потом с этими данными можно дальше работать. Например, закрывать данные страницы от индексации. Если они ещё по какой-то причине попадают в индекс, их соответственно, нужно ещё и выкидывать из индекса.
Анализ страниц по кодам ответов
Также можно анализировать страницы по кодам ответов:
В связке с информацией о коде ответа и датой последнего сканирования страницы роботом, можно смотреть и делать выводы: по какой причине роботы уже давно не обращаются к целевым полезным страницам сайта и как-то влиять на эти причины.
Поиск сомнительных URL, которые посещают роботы
Также можно находить такие сомнительные URL-адреса, по которым бегают роботы и тратят свои ресурсы (краулинговый бюджет). В данном случае это страницы внутреннего поиска на сайте. Каким образом робот добрался до этих страниц — скорее всего был включен обход по счетчикам на сайте. Таким образом страница может попасть в индекс.
С такими сомнительными URL-адресами нужно бороться, например, ставим самореферентные теги canonical, т.е. ссылка со страницы на саму себя — это бы сработало для Google. Альтернативное решение для Google — поставить запрет на индексацию в мета-тег robots только для Googlebot. Для Яндекса нужно ставить директиву Clean-param в robots.txt, указываем в ней все ненужные GET-параметры.
Выявляем полезное, редко сканируемое
Например, если есть полезные страницы, которые нужно чаще сканировать, то соответственно нужно просто чаще вносить изменения в контент, обновлять, актуализировать контент, либо подливать ссылочное. Про приятное ссылочное рассказывал на этом вебинаре у Михаила Шакина.
Нюансы
Нужно смотреть на IP-адреса роботов поисковых систем, потому что довольно часто юзер-агенты могут подделывать. Это могут делать либо сами боты, либо люди, когда, например, через расширение меняют свой User-Agent и таким образом заходят.
Сведение данных
Можно дополнительно проанализировать сайт через лягушку и закинуть эти данные в Log File Analyser:
Таким образом, получается, что у нас будут и данные по парсингу и по логам. В данном случае, я бы обращал внимание на эти три параметра (указаны на скриншоте):
- Matched with URL Data — совпадение URL при парсинге и в логах;
- Not in URL Data — URL есть в логах, но нет в парсинге;
- Not in Log File — нет в логах, есть в парсинге.
Подробнее про сведение данных рассказывал Иван Зимин в этом видео.
Заключение
На этом все, всю основную информацию я рассказал при работе с файлами логов. Надеюсь этот материал был вам полезен. Не забудьте подписаться на мои социальные сети:
- Телеграм @seosekretiki;
- Канал на YouTube;
Спасибо за внимание!