Автор: Сайрус Шепард (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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

< 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» способствует укреплению взаимосвязей между ресурсами, обмену данными, является немаловажным аспектом в формировании ссылочных стратегий и в целом способствует оптимизации сайта.