Meta name referrer content origin: HTML/Директива referrer (Элемент meta)

Содержание

HTML/Директива referrer (Элемент meta)

Синтаксис

HTML

XHTML

<head>
  ...
  <meta name="referrer"
        content="[значение]">
  ... 
</head>

Описание

Директива referrer (от англ. «referrer» ‒ «ссылающаяся страница») управляет содержимым HTTP-заголовка «Referer», прикрепляемого к любому запросу, отправляемому из текущего документа.

Поддержка браузерами

Chrome

Поддерж.

Firefox

Поддерж.

Opera

Поддерж.

Maxthon

Поддерж.

IExplorer

Поддерж.

Safari

Поддерж.

iOS

Поддерж.

Android

Поддерж.

Спецификация

Верс.	Раздел
HTML
2.0	Associated Meta-information: META	Перевод
3. 2	META
4.01	The META element name = name [CS]… DTD: `Transitional Strict Frameset`
5.0	4.2.5.1 Standard metadata names
5.1	4.2.5.1. Standard metadata names
XHTML
1.0	Extensible HyperText Markup Language DTD: `Transitional Strict Frameset`
1.1	Extensible HyperText Markup Language

Дополнительные ресурсы:

Сайт	Тема
wiki. whatwg.org	WHATWG Wiki MetaExtensions (Расширенный список имён метаданных)
wiki.whatwg.org	Meta referrer
w3c.github.io	Referrer Политика

Значения атрибута «content»

no-referrer: Запрещает отправку HTTP заголовка «Referer».
no-referrer-when-downgrade: Отправляет происхождение (источник) документа как ссылку на надёжный адресат (с «https» на «https»).
Примечание: на менее безопасный адресат ссылка не отправляется (с «https» на «http»).
origin-only: Отправляет происхождение (источник) документа.
origin-when-crossorigin: Отправляет полный URL-адрес (зачищенный от параметров) при выполнении запроса от того же источника (домена). При запросе с другого источника (домена, поддомена) отправляется только источник документа (домен, поддомен без указания полного адреса документа).
unsafe-url: Отправляет полный URL-адрес (зачищенный от параметров) при выполнении запроса от того же источника.

Значение по умолчанию: «no-referrer-when-downgrade».

Примечание: под происхождением или источником документа понимается URL-схема (например, «http», «https» и т.д.), хост (например, «example.com», «programmerbook.ru», «subdomen.programmerbook.ru» и т.п.) и порт (например, «example.com:80», ««example.com:8080»» и т.п.) текущего документа.

Пример использования

Листинг кода

<!DOCTYPE html>
<html>
<head>
<meta charset=»utf-8″>
<title>Директива referrer</title>
<meta name=»referrer» content=»no-referrer»>
</head>
<body>
<h2>Пример использования директивы «referrer»</h2>

<p>Документ без отправки HTTP заголовка «Referer».

</p>
</body>
</html>

Директива referrer

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

8 июля 2015

Анастасия Матвеева

14470

Автор: Сайрус Шепард (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». Тем, у кого есть желание углубиться в тему подробнее, автор статьи рекомендует ознакомиться со следующим документом.

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

Where did all the HTTP referrers go?
Tighter Control Over Your Referrers
Geek guide to Direct Traffic Analysis
W3C Referrer Policy

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

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

None: Никогда не передает реферальные данные:
< meta name=»referrer» content=»none»>
None When Downgrade: Передает реферальные данные сайтам на HTTPS, в то время, как сайтам на HTTP данные не передаются.
< meta name=»referrer» content=»none-when-downgrade»>
Origin Only: Передает данные о хостах и поддоменах. При этом URL , как правило, имеет следующий вид: https://moz.com/example.html would simply send https://moz.com (пример).
< meta name=»referrer» content=»origin»>
Origin When Cross-Origin: Передает полные данные о URL в случаях, когда настройка произведена по схеме №3 вне зависимости от того, какой протокол использует сайт HTTP или HTTPS.
< meta name=»referrer» content=»origin-when-crossorigin»>
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» способствует укреплению взаимосвязей между ресурсами, обмену данными, является немаловажным аспектом в формировании ссылочных стратегий и в целом способствует оптимизации сайта.

Статьи
SEO

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

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

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

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

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

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

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

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

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

Источник

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

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

Тег мета-реферера: продвижение для SEO и Интернета [Name=»referrer»]

Взгляды авторов являются полностью их собственными (за исключением маловероятного случая гипноза) и могут не всегда отражать взгляды Moz.

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

HTTPS в результатах поиска растет. Последние данные MozCast от доктора Пита показывают, что почти 20% результатов Google на первой странице теперь используют HTTPS.

К сожалению, у HTTPS есть и недостатки.

Маркетологи сталкиваются со своей первой проблемой, когда они переключают обычные HTTP-сайты на HTTPS. Технически сложный, переход обычно включает в себя маршрутизацию вашего сайта через серию переадресаций 301. Исторически сложилось так, что эти типы редиректов связаны с потерей ссылочного веса (предположительно около 15%), что может привести к потере рейтинга. Это может свести на нет любое SEO-преимущество, о котором заявляет Google.

Росс Хадженс прекрасно описал это в своем твите:

«HTTPS является фактором ранжирования». 301 HTTP на HTTPS. Ссылки теряют капитал из-за ошибки 301. Прибыль HTTPS меньше суммы потерь капитала. Потерять трафик.
— Росс Хадженс (@RossHudgens) 15 июня 2015 г.

Многие оптимизаторы поделились анекдотичными историями о HTTPS-сайтах, хорошо зарекомендовавших себя в результатах поиска Google (и наши данные о рейтинговых факторах, которые скоро будут опубликованы, похоже, подтверждают это). Однако краткосрочный эффект большой миграции может быть трудно принять. Когда Moz недавно перешел на HTTPS, чтобы обеспечить лучшую безопасность для наших зарегистрированных пользователей, , мы увидели падение нашего органического поискового трафика на 8-9% .

Проблема номер два является предметом этого поста. Это связано с потерей реферальных данных. Как правило, когда один сайт отправляет трафик на другой, отправляется информация, которая идентифицирует исходный сайт как источник трафика. Эти бесценные данные позволяют людям видеть, откуда поступает их трафик, и помогают распределять поток информации по сети.

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

Этот процесс останавливается, когда трафик с сайта HTTPS поступает на незащищенный сайт HTTP . В этом случае данные реферера не отправляются. Веб-мастера не могут знать, откуда приходит их трафик.

Вот как выглядели данные перехода на мой личный сайт, когда Moz перешел на HTTPS. Я потерял всякую видимость того, откуда пришел мой трафик.

Это (не предусмотрено) все сначала!

Введите метатег реферера

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

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

Более того, тег позволяет вам контролировать, как передается информация о вашем реферере.

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

Как использовать метатег реферера

Ниже приведены чрезвычайно упрощенные инструкции по использованию метатега реферера. Для более глубокого понимания мы настоятельно рекомендуем обратиться к рабочему проекту спецификации W3C.
Мета-тег реферера размещается в разделе вашего HTML-кода и ссылается на одно из пяти состояний, которые управляют тем, как браузеры отправляют информацию о реферере с вашего сайта. Пять состояний:
Нет: Никогда не передавать реферальные данные

Нет При переходе на более раннюю версию : отправляет информацию о реферере на защищенные сайты HTTPS, но не на небезопасные сайты HTTP.

Только источник: Отправляет схему, хост и порт (в основном, субдомен) без полного URL-адреса в качестве реферера, т. е. https://moz.com/example.html просто отправляет https://moz. ком
Источник при перекрестном происхождении : Отправляет полный URL-адрес в качестве реферера, когда цель имеет ту же схему, хост и порт (т. сайты . (примечание: В официальной спецификации есть опечатка. В будущих версиях должно быть «исходное-при-перекрестном происхождении»)

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

Метатег реферера в действии
Мы установили метатег реферера для Moz на «происхождение», что означает, что когда мы ссылаемся на другой сайт, мы передаем нашу схему, хост и порт. Конечным результатом является то, что вы видите http://moz.com в качестве реферера, лишенного полного пути URL (/meta-referrer-tag).
Обычно Moz посещает мой личный сайт несколько раз в день. Вот как выглядели мои аналитические данные до и после того, как мы внедрили метатег referrer.
Для простоты и безопасности на большинстве сайтов может потребоваться реализовать состояние «исходное», но у него есть недостатки.
Одним из негативных побочных эффектов было то, что как только мы внедрили метатег реферера, наша аналитика AdRoll, которую мы используем для ретаргетинга, перестала работать. Оказывается, AdRoll использует нашу информацию о реферере для аналитики, но состояние «происхождения» метатега реферера означало, что единственный URL-адрес, который они когда-либо видели, был https://moz.com.
Заключение

Нам нравится мета-тег referrer, потому что он поддерживает поток информации в Интернете. Именно так и должна работать сеть!
Это помогает маркетологам и веб-мастерам точно знать, откуда поступает их трафик. Это поощряет участие, общение и даже создание ссылок, что может привести к улучшению SEO.
Полезные ссылки:
Куда делись все рефереры HTTP? (относится к более старой спецификации)
Более жесткий контроль над вашими реферерами
Руководство для компьютерщиков по прямому анализу трафика
Политика реферера W3C
SEO для HTTPS-сайтов: стоит ли внедрять тег Meta Referrer?
Узнайте, как использование метатега реферера может помочь людям понять трафик веб-сайта, даже с сайтов HTTPS.
В нашем постоянно подключенном мире безопасность важна настолько, что Google предпринял шаги, чтобы побудить владельцев веб-сайтов использовать HTTPS для защиты своих веб-сайтов. Но хотя эта повышенная безопасность может помочь обеспечить безопасность конфиденциальной информации, она вызвала некоторую головную боль в мире SEO.
Если вы отслеживаете трафик своего веб-сайта в Google Analytics, вас, вероятно, больше всего интересует, как люди находят ваш сайт. Вы хотите знать, откуда идет ваш трафик, но по мере того, как все больше и больше сайтов используют HTTPS, эта информация не отслеживается. Это связано с тем, что при отправке трафика с HTTPS-сайта на незащищенный HTTP-сайт никакие реферальные данные не отправляются. Это означает, что вы упускаете ценные данные, которые можно использовать для определения успеха или неудачи ваших стратегий входящего маркетинга и поисковой оптимизации (SEO).
Хотите узнать больше о мире SEO? Загрузите нашу информативную электронную книгу: «SEO и искусство поиска».
Решение: Мета-тег Referrer
Лучший способ помочь людям понять, как проходит трафик в Интернете, — это использовать сравнительно недавно появившийся HTML-тег под названием Meta Referrer Tag . Включение этих тегов в раздел HTML-кода вашего сайта позволит вам указать, какая информация отправляется, когда люди переходят по ссылкам с вашего HTTPS-сайта на любой другой сайт, независимо от того, использует ли он HTTPS или HTTP.
Существует пять «состояний» политики, которые можно указать с помощью метатега referrer, предлагая различные уровни информации о трафике, поступающем с вашего сайта. Это:
Обновление от 15 марта 2017 г.: с 26 января 2017 г. политика реферера была обновлена и использует следующие значения: тег, чтобы никогда не передавать какие-либо реферальные данные с вашего сайта:

Нет реферера при переходе на более раннюю версию (ранее «none-when-downgrade»): при использовании следующего тега полный URL-адрес страницы перехода будет отправлен на HTTPS-сайты, но не будет отправлена информация о реферере на HTTP-сайты:

Тот же источник – при использовании этого тега полный URL-адрес ссылающейся страницы будет отправляться только для запросов в домене вашего веб-сайта.

Origin — при использовании этого тега будет отправлен только домен или поддомен вашего сайта, а не полный URL-адрес. Ссылка с https://www.yoursite.com/example-page.html будет отправлять https://www.yoursite.com.

Strict Origin – при использовании этого тега информация о переходе будет отправляться только с сайта HTTPS на другой сайт HTTPS. Отправленные реферальные данные будут включать только домен или поддомен вашего сайта, а не полный URL-адрес. Ссылка с https://www.yoursite.com/example-page.html будет отправлять https://www.yoursite.com. Рефералы на сайт, не поддерживающий HTTPS, не будут отправлять реферальные данные.

Origin When Cross-Origin — этот тег будет отправлять полный URL-адрес вашей ссылающейся страницы при ссылке на ваш сайт, но будет отправлять только домен или субдомен при ссылке на внешние сайты:

Strict Origin When Cross-Origin — при использовании этого тега будет отправляться реферальная информация только с сайта HTTPS. на другой HTTPS-сайт. Этот тег будет отправлять полный URL-адрес вашей ссылающейся страницы при ссылке на ваш сайт, но будет отправлять домен или поддомен только при ссылке на внешние сайты. Рефералы на сайт, не поддерживающий HTTPS, не будут отправлять реферальные данные.

Небезопасный URL-адрес — этот тег всегда будет отправлять полный URL-адрес ссылающихся страниц:

Пустая строка – если тег реферера оставлен пустым для определенной страницы или ссылки, ссылки будут использовать политику реферера, определенную в другом месте. Если политика не определена, ссылки по умолчанию будут иметь значение «без реферера при переходе на более раннюю версию».

Для получения дополнительной информации об использовании метатега referrer см. страницу W3C Referrer Policy.
Почему следует использовать тег Meta Referrer?
Хотя безопасность важна, важно, чтобы каждый мог видеть, как информация передается в Интернете. По мере того, как все больше HTTPS-сайтов внедряют метатег реферера, все больше людей смогут понять, откуда поступает трафик на их сайт. Кроме того, когда вы ссылаетесь на внешний веб-сайт со своего сайта, вы можете захотеть, чтобы они могли отслеживать эту ссылку и ссылаться на вас. Предоставление этой информации владельцам сайтов может гарантировать, что люди понимают, кто на кого ссылается, поощряя создание ссылок, которое по-прежнему является важным фактором в SEO.
Какую политику тегов мета-реферера следует использовать?
Вы захотите определить, какой объем информации о вашем сайте вы хотите предоставить в свободном доступе при выборе политики для использования. Если у вас есть определенные страницы или документы, которые вы не хотите публиковать, вам следует использовать политику происхождения или происхождения при перекрестном происхождении при создании ссылок с этих страниц, а также политику строгого происхождения или строгого происхождения, когда политики перекрестного происхождения, чтобы ограничить реферальную информацию только сайтами HTTPS.
No related posts.