О пользе мета-тега «referrer» в эпоху шифрования

Автор: Сайрус Шепард (Cyrus Shepard) - сотрудник команды Moz, ранее занимался исключительно вопросами поисковой оптимизации, сегодня в большей степени сосредоточен на создании продвигающего контента и технических аспектах его распространения и отслеживания статистики. Сайрус Шепард не раз возглавлял кампании по продвижению в интернете крупных и авторитетных брендов.

Источник: http://moz.com

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

Усилия представителей поиска возымели эффект, и сегодня мы можем наблюдать в результатах поисковой выдачи все большее и большее число ресурсов, использующих протокол HTTPS. Результаты недавнего исследования MozCast свидетельствуют, что на сегодняшний день около 20% результатов, показывающихся на первой странице выдачи Google, ведут на защищённые страницы:

К сожалению, использование протокола HTTPS сайтами имеет и свои, довольно весомые недостатки. Переход с HTTP на HTTPS доставил массу трудностей и технических неудобств интернет-маркетологам.

Первая проблема была связана с вынужденным применением кода ответа сервера 301 для перенаправления пользователей на безопасные версии страниц. Исторически данный тип перенаправлений ассоциировался у профессионалов отрасли с потерей ссылающейся страницей ссылочного веса, как минимум на 15%, что само собой может привести к снижению её видимости в результатах поисковой выдачи. Одна только эта проблема способна перечеркнуть все обещанные Google преимущества.

Эксперт отрасли Росс Хадженс (Ross Hudgens) идеально сформулировал проблему в своём твите: «"HTTPS как фактор ранжирования". Перевод с HTTP на HTTPS с применением 301 редиректа ведет к потере ссылочного веса. Выгода от перехода на HTTPS - незначительная, зато потеря ссылочного веса – ощутима. Трафик теряется».

"HTTPS is a ranking factor". 301 HTTP to HTTPS. Links lose equity through 301. HTTPS gain is less than amount of equity loss. Lose traffic.

— Ross Hudgens (@RossHudgens) 15 июня 2015

Тем не менее, на пике событий многие оптимизаторы радостно делились историями успешного перевода своих ресурсов на безопасный протокол HTTPS, рапортуя о том, что видимость безопасных страниц в SERP Google даже улучшилась. Вскоре использование HTTPS на сайте было официально объявлено сигналом ранжирования для Google и даже вошло в список факторов ранжирования по итогам 2014 года. Трудно поверить, но перевод сайта на HTTPS дает чрезвычайно кратковременный эффект. Впоследствии позиции ресурса в выдаче и вовсе снижаются. Так перевод блога Moz на протокол шифрования, призванный обеспечить большую конфиденциальность работы с ресурсом для зарегистрированных пользователей, привел к снижению видимости страниц в результатах органической выдачи Google на 8-9%.

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

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

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

Когда трафик с сайтов, защищённых протоколом HTTPS, поступает на ресурсы, применяющие HTTP, реферальные данные не передаются, и вебмастеру становится невозможно определить, из каких источников он поступает.

Вот как выглядела статистика переходов на персональный блог автора данной статьи с ресурса Moz после перевода последнего на HTTPS:

Зачем нужен мета-тег «referrer»?

Поскольку решение проблемы традиционными методами становится затруднительным, приходится решать вопрос за счёт применения иных методов. Следует признать, что большинство интернет-маркетологов еще не слишком хорошо осведомлены о существовании альтернативных путей и возможностей отслеживания данных о входящем трафике. Выйти из ситуации, к примеру, помогает использование мета-тега «referrer», который появился несколько лет назад. Он позволяет контролировать процесс передачи реферальных данных. Мета-тег поддерживается всеми основными браузерами и передает данные о реферерах, согласно пользовательским настройкам. При этом трафик остается зашифрованным, а пользователи получают все преимущества от применения сайтом протокола HTTPS. Тем не менее, владелец ресурса получает возможность передавать данные о переходах на любые веб-сайты, включая те, которые до сих пор применяют протокол HTTP.

Как использовать мета-тег «referrer»?

Ниже представлены упрощенные инструкции по использованию мета-тега «referrer». Тем, у кого есть желание углубиться в тему подробнее, автор статьи рекомендует ознакомиться со следующим документом.

Полезными также могут оказаться и следующие ссылки:

Упомянутый выше мета-тег размещается в разделе <head> HTML-страницы и способен принимать 5 различных значений. От них впоследствии будет зависеть то, насколько полную информацию о реферерах будут передавать сайту браузеры.

Типы значений могут быть следующими:

  1. None: Никогда не передает реферальные данные:

    < meta name="referrer" content="none">

  2. None When Downgrade: Передает реферальные данные сайтам на HTTPS, в то время, как сайтам на HTTP данные не передаются.

    < meta name="referrer" content="none-when-downgrade">

  3. Origin Only: Передает данные о хостах и поддоменах. При этом URL , как правило, имеет следующий вид: https://moz.com/example.html would simply send https://moz.com (пример).

    < meta name="referrer" content="origin">

  4. Origin When Cross-Origin: Передает полные данные о URL в случаях, когда настройка произведена по схеме №3 вне зависимости от того, какой протокол использует сайт HTTP или HTTPS.

    < meta name="referrer" content="origin-when-crossorigin">

  5. Unsafe URL: Всегда передает полный URL реферера. Важно понимать, что данная настройка является наименее безопасной. Часть незашифрованных данных может быть передана. По умолчанию фрагменты URL , имя пользователя и пароли автоматически исключаются из URL-а.

    < meta name="referrer" content="unsafe-url">

Мета-тег в действии

Увидеть, как работает мета-тег «referrer», можно, совершив переход по следующей ссылке. Такое значение URL можно получить, если выбрать в качестве его настройки параметр «Origin». При такой настройке параметров тега данные о реферере передаются схеме: хост и поддомен. В данном случае в качестве итогового результата показывается следующий адрес сайта перехода: http://moz.com.

На практике данные аналитики до применения мета-тега «referrer» и после начала его использования выглядят так:

Чтобы упростить процедуру отслеживания и сделать её максимально безопасной, большинство представителей сайтов предпочитают использовать параметр «Origin» при настройке мета-тега «referrer». Однако у данного подхода есть свои недостатки. Один из главных минусов заключается в том, что при настройке тега соответствующим образом для ресурса Moz, аналитика системы AdRoll, которую ресурс использует для ретаргетинга объявлений, перестает работать. В своей аналитике AdRoll использует данные Moz о реферальных переходах, в то же время параметр «Origin» подразумевает, что единственный URL, с которого перешел пользователь был https://moz.com. Таким образом, аналитика становится недействительной.

Заключительные выводы

Полюбить мета-тега «referrer» можно только за то, что он хоть каким-то образом позволяет передаваться по сети данным о переходах с защищенных сайтов. Так, что жизнь не останавливается!

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

Два медовых месяца с «Минусинском»

Итак, с момента ввода алгоритма «Минусинск» прошло уже ровно два месяца. Думаю, можно уже сделать первые промежуточные выводы...

Подводные камни при работе с ключевыми словами в Яндекс.Директе

На первый взгляд, настройка контекстной рекламы - это проще-простого

Разбор алгоритма Минусинск. Практические выводы

Объявленная недавно Яндексом эпоха Минусинска внесла серьезную смуту в ряды оптимизаторов

Всё, что вы хотели знать об индексации мобильных приложений, но стеснялись спросить: беседа с Марией Моевой

Значение мобильных версий сайтов и приложений в современном интернете продолжает расти

10 полезных SEO-советов, которые помогут обойти конкурентов

Источник

Работа над семантикой сайта: от устаревших методов – к современным

Автор: Нэт Дэйм (Nate Dame) – руководитель и основатель агентства SEOperks, специалист в области ссылочного продвижения, автор множества практических статей, постоянный спикер...