Иногда на сайтах возникают проблемы с поисковой оптимизацией, которые сложно или даже невозможно обнаружить с помощью популярных сервисов веб-аналитики вроде Google Analytics, Яндекс.Метрики, Рамблер/Топ-100 или Спутник/Аналитики. Когда это происходит, опытные оптимизаторы часто полагаются на методы старой школы. Например, начинают изучать лог-файлы веб-серверов.
Что такое лог-файл веб-сервера
Многие вебмастера и оптимизаторы полагают, что Google Analytics и подобные аналитические платформы фиксируют каждое посещение их сайтов. Однако платформы веб-аналитики не регистрируют большинство посещений роботов, в том числе и ботов поисковых систем. Другое дело лог-файлы веб-серверов. Там фиксируется каждое посещение сайта – людьми или роботами. Обычно в них содержится информация об IP-адресе посетителя, агенте пользователя, запрошенные страницы и страницы, откуда приходят посетители.
Основная проблема в данном случае заключается в том, что информация находится в необработанном виде, и вебмастеру / оптимизатору необходимо предпринять дополнительные шаги для анализа данных. Например, так выглядит информация из лога Apache.
66.249.64.34 - frank [05/Apr/2017:13:55:36 -0700] "GET /product-123 HTTP/1.1" 200 2326 " http://www.webstore.com/home.html" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"
Можно выделить ключевые элементы записи : IP-адрес посетителя, время посещения, посещенная страница, ссылающаяся страница, а также информация о посетителе (человек или бот).
Зачем делать анализ лог-файлов
Если страниц на сайте много, тяжело отследить, что происходит со страницами ресурса: бот может просматривать ненужные, «мусорные» ссылки, не закрытые для индексации, а важные пропускать. Поэтому важно понимать фактическое количество страниц сайта и представлять процент, который на самом деле индексируется поисковиками.
Анализ лог-файлов решает несколько задач:
- Наблюдать за реальным поведением бота: он может сканировать те страницы, о которых вы не знаете, и не посещать нужные. Если бот долго не посещал страницу, то скорее всего ее не будет в индексе.
- Понять, куда уходит краулинговый бюджет, то есть какое количество URL собирается просканировать бот Google.
- Увидеть, по каким страницам бот ходит чаще всего: это значит, что они важны, и им нужно уделить особое внимание.
- Подстраховаться от «писем счастья» Google поможет частый мониторинг лог-файлов. Вы сразу увидите скачки в поведении бота, если со ссылками возникнут проблемы.
- Оценить изменения позиции сайта после внедрения каких-то новшеств.
То есть анализ лог-файлов поможет контролировать индексацию больших сайтов с множеством страниц и влиять на нее.
Кому нужно анализировать лог-файлы
Для некоторых сайтов нет смысла делать регулярный анализ лог-файлов, а кому-то анализ показан обязательно.
Нужно:
Если у сайта больше 100 тысяч страниц, анализировать логи нужно регулярно. За таким количеством страниц тяжело следить, поэтому нужен особенный контроль.
Обязательно проводить анализ нужно при переезде сайта, особенно если ресурс крупный. Это поможет минимизировать ошибки и потери ссылок.
Не нужно:
Если у сайта меньше 50 тысяч страниц. Обычно у таких сайтов четкая структура, за страницами проще следить, и бот индексирует то, что нужно.
Как боты видят сайт
Размер анализируемого сайта считается не по количеству индексируемых страниц в поисковой системе, а по сумме всех страниц, которые генерирует движок. То есть неиндексируемые тоже считаются. Если ресурс большой, то фактическое количество страниц без анализа лог-файлов установить сложно.
Бот распознает сайт как набор индексируемых и закрытых для индексации страниц, которые он будет игнорировать.
Многие не анализируют лог-файлы, поскольку приходится работать с большими объемами неструктурированных данных. Но для больших сайтов это хороший способ разобраться с некоторыми SEO-проблемами.
3 примера использования лог-файлов веб-серверов в SEO
Ниже представлены три реальных кейса использования логов веб-серверов, чтобы добраться до корня SEO-проблем.
Боремся с дублями страниц на сайте интернет-магазина
Первый пример касается сайта крупного онлайн-ритейлера. В разделе Google Search Console > Сканирование> Файлы Sitemap отображалось сообщение о том, что в файле Sitemap XML данного ресурса прописано более 100 тыс. страниц. Но в индексе Google было менее 20 тыс. из них. Как это возможно?
Робот Google может сканировать множество страниц с повторяющимся контентом и пропускать часть таких страниц при индексировании. Определить, какие дублирующиеся страницы индексируются, а какие реальные – нет, бывает непросто. К сожалению, сервис Google Search Console не предоставляет список проиндексированных URL-адресов и не указывает, какие страницы из файлов Sitemap XML не индексируются.
Чтобы их получить соответствующие данные, были проанализированы лог-файлы веб-серверов за 3 месяца. Выяснилось, что за этот период Google просканировал менее 9 процентов страниц в XML-файле Sitemap (91,6% URL-адресов сайта из Sitemap не сканировались). После внимательного изучения страниц, которые не сканировались, обнаружилось, что большинство из них имеют точно такой же контент и шаблон. Единственным отличием было название продукта. Роботу Googlebot такое не нравится. В этом случае решением было создание уникального контента для каждой страницы, начиная со страниц самых продаваемых продуктов.
Находим отсутствующие параметры URL
Второй пример - большой сайт автомобильной тематики. После перехода на HTTPS его владельцы столкнулись с многочисленными задержками при повторном индексировании, которые ухудшали позиции сайта в поисковой выдаче. Этот случай был особенно сложным, поскольку было подозрение, что на сайте имеются серьезные "ловушки для ботов", которые заставляют поисковых роботов продолжать сканировать страницы в бесконечном цикле. Причиной зачастую является непродуманная навигация или структура сайта. Подобные проблемы следует оперативно решать, ведь бюджет сканирования (crawl budget) робота Googlebot не резиновый.
Для решения проблемы снова пришлось обработать данные из лог-файлов с нескольких веб-серверов. Это позволило найти страницы, которые сканируются необычно часто, что свидетельствует о наличии "ловушки для ботов". Затем проблемные страницы были классифицированы по типу. Разбивка страниц по типу позволила "сузить круг подозреваемых" до группы URL-адресов "Год-Марка-Модель-Категория". После анализа этих страниц обнаружился ряд новых параметров, информации по которым не было в разделе Google Search Console> Сканирование>
параметры URL.
Избавляемся от лишних статей информационного сайта, которые не видят программы для сканирования
Третий пример касается сайта популярного веб-издателя. Оптимизаторы знали, что на сайте есть дублирующиеся страницы. Но когда они запускали инструмент для скирдования ScreamingFrog, то не смогли найти такие страницы, потому что они не были перелинкованы между собой. Однако при поиске в Google в SERP можно было увидеть несколько таких страниц. Это подтверждало, что они были проиндексированы. Угадывать проблемные URL-адреса – не вариант. Пришлось использовать лог-файлы.
Были проанализированы данные из логов за один месяц. При анализе необходимо было получить ответ на вопрос: какие из просканированных Googlebot адресов URL не включены в XML-Sitemap? Были найдены несколько бесполезных страниц с дублирующимися заголовками и без уникального контента, от которых пришлось избавиться.
В данном случае важно отметить, что робот Google может находить и сканировать страницы, которые сторонние инструменты для сканирования вроде ScreamingFrog не замечают, по следующим причинам:
- Google использует ссылки с любого веб-сайта, а не только внутренние ссылки сканируемого ресурса.
- Популярные платформы для блогов вроде WordPress имеют встроенные системы оповещения поисковых систем о создании нового контента.
- У Google длинная память: если страница была просканирована в прошлом, Google может повторно ее просканировать в будущем.
