Маленький секрет Яндекс.Метрики: склейка данных по страницам. На заметку SEO-специалисту

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

Вот скриншот части отчета для одного из сайтов, аудит которого я проверял вручную (ох и скучное это дело!):

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

Не буду читать долгую проповедь, почему это плохо, ограничусь цитатой из справки Яндекса:

Страницы, содержащие знак «/» в конце url и без него, являются для нашего робота разными. Если эти страницы содержат одинаковый контент, то лучше установить перенаправление 301 с одной страницы на другую (вы можете сделать это с помощью настроек в файле htaccess) или указать канонический URL.

Кстати, такие дубли далеко не всегда можно отловить обычным парсером сайта вроде Screaming Frog. Неканоническая страница могла быть проиндексирована и без ссылки на нее (или же ссылка могла исчезнуть впоследствии). По крайней мере для исследуемого сайта десктопный софт не нашел url без слеша. (Видишь суслика? А он есть!)

Как эта ситуация отображается в Метрике?

Напомню, отчет я увидел в ходе проверки новой версии сервиса. Поэтому открыл статистику и построил отчет, аналогичный тому, что автоматически сгенерировал на bez-bubna.com:

Упс, кажется в сервисе глюк. Ведь переходов из Гугла на этот адрес — без слеша — быть не должно (см. первый скрин)! А их просто куча. Хотя погодите…

Я дописал в условие сегментации слеш на конце адреса — что же вы думаете? Отчет не изменился! Получается, что:

Яндекс.Метрика склеивает данные для страниц типа site.ru/page и site.ru/page/, данные по ним идентичны.

Откуда же тогда сервису знать про то, какие url на самом деле посещались? Все просто: в API отдаются полные данные с разбивкой.

Очевидно, это осознанный и правильный шаг со стороны команды Яндекс.Метрики. Они не стремятся загромождать статистику лишними данными — их все равно исключительно много. Метрика — это инструмент веб-, а не SEO-аналитики (удобный и эффективный инструмент, что бы ни говорили высокомерные любители Google Analytics). Путать маркетологов мизерными различиями между страницами, которые 99% пользователей не видны — ни к чему.

Те, кому эти различия важны (собственно SEO-специалисты) — могут получить их по API. Или через мой сервис, что еще лучше 🙂 .

Проверка на всякий случай

Ну хорошо, скажет въедливый читатель (а таким на этом блоге рады!). Допустим, даже данные в Метрике одинаковы. Но сервис все равно может врать — раз его через веб-интерфейс не проверить.

Для того, чтобы убедиться в адекватности отчета на первом скрине, сделал следующее:

  1. Определил, какой url выдается для Яндекса и для Google по запросам, соответствующим странице. Все как я предполагал: Гугл видит страницу со слешем, Яндекс — без.
  2. Поднял логи сервера и посмотрел заходы с поисковиков на эту страницу. Результат аналогичен.

Таким образом, данные в аудите верны, а Метрика через веб-интерфейс действительно показывает по страницам со слешем и без объединенные сведения.

Уфф, можно не переделывать отчет. Я счастлив!

Поделиться
Отправить
Плюсануть

Читайте также
Комментарии
  • Юрий
    08.09.2016

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

    Ответить
  • seoonly.ru
    08.09.2016

    Как мало надо для счастья)))

    Ответить
  • vpsadm
    09.09.2016

    Я просто смотрю отчет «Заголовки страниц», а не урлы.

    Ответить
    • Алексей Трудов
      09.09.2016

      Как правило у таких страниц заголовок идентичен

      Ответить
  • Артур
    30.09.2016

    По-моему, поиск такой стандартной ошибки легче (и быстрее, с учетом? что большинство оптимизаторов работают с небольшими сайтами, а для оптимизаторов, которые работают с большими сайтами сами смогут найти довольно быстро) осуществлять вручную после того как собраны все типовые страницы.
    Внести в свой чек-лист, где сразу проверять:
    — доступность страниц с www и без www
    — доступность страниц с https и с http + для обоих протоколов проверять доступность страниц с www и без www (в случае если у сайта есть https версия)
    — доступность страниц со / и без /
    — главное зеркало в Яндекс, Google

    Ответить

Добавить комментарий