Referrer-Policy: что это и зачем вообще заморачиваться
Если упростить до минимума, заголовок Referrer-Policy — это настройка, которая говорит браузеру:
«Какую именно информацию о том, откуда пришёл пользователь, можно передавать дальше?».
Когда человек кликает по ссылке с вашего сайта на другой ресурс, браузер обычно отправляет HTTP-заголовок `Referer` (да, историческая опечатка) — адрес страницы-источника.
Заголовок Referrer-Policy определяет, сколько деталей из этого адреса будет видно:
- полный URL со всеми параметрами;
- только домен;
- ничего вообще.
И вот здесь начинается самое интересное: от выбранной политики зависит защита данных и SEO с помощью referrer policy. Можно случайно:
- слить конфиденциальные параметры в URL;
- сломать аналитику;
- испугать партнёров подозрительными реферами.
Основные режимы Referrer-Policy по-человечески
Не будем переписывать документацию, разберёмся по сути, как работает Referrer-Policy заголовок в реальных сценариях.
no-referrer
Браузер вообще не отправляет Referer.
Плюсы:
- максимальная приватность;
- никакие параметры, токены, UTM-метки не утекут.
Минусы:
- статистика переходов «ломается» — внешние сайты не видят, откуда к ним пришёл трафик;
- партнёрские программы и рекламные площадки могут быть недовольны.
Подходит, если у вас закрытый сервис, внутренние панели, CRM и вам все равно, кто что увидит вне вашей системы.
no-referrer-when-downgrade
Это старое поведение по умолчанию у многих браузеров:
- при переходе с HTTPS на HTTPS — отправляется полный Referer;
- с HTTPS на HTTP — реферер не отправляется.
С точки зрения безопасности — так себе компромисс. Для современного интернета считается устаревшим подходом.
origin
Отправляем только «происхождение», то есть схему, домен и порт:
- было: `https://site.ru/catalog/tovary/?utm_source=google`
- станет: `https://site.ru/`
Плюсы:
- приватность на уровне страниц и параметров;
- при этом видно, с какого домена пришёл пользователь — аналитика хоть и грубая, но жива.
Часто выбирают для корпоративных сайтов, лендингов, документации.
strict-origin-when-cross-origin
Один из наиболее адекватных современных вариантов, если нужны и безопасность, и данные:
- переходы внутри одного домена — с полным URL;
- переходы на другие домены — отправляется только origin;
- с HTTPS на HTTP — реферер не отправляется.
То, что чаще всего попадает в раздел referrer policy best practices для сайта в современной документации и гайдлайнах.
strict-origin / same-origin / unsafe-url
Коротко:
- `same-origin` — отправляем реферер только при переходах внутри того же домена.
- `strict-origin` — только origin, и только при переходах между защищёнными страницами (HTTPS → HTTPS).
- `unsafe-url` — всегда отправляем полный URL, со всеми параметрами, всем подряд. В 2025 году почти всегда плохая идея.
Referrer-Policy и SEO: где грань между приватностью и аналитикой
Миф: «чем меньше мы отправляем реферер, тем лучше для SEO».
На деле всё чуть сложнее.
Поисковые системы вроде Яндекса и Google и так часто скрывают часть реферера по своим причинам, но настройка заголовка Referrer-Policy тоже влияет:
- при жёсткой политике (`no-referrer`) внешние сайты не увидят, что к ним приходят пользователи именно от вас;
- сложнее доказывать партнёрам и рекламодателям эффективность размещения ссылок;
- анализ воронок, сквозная аналитика и атрибуция в целом становятся менее точными.
Если вы ведёте активное SEO-продвижение и работаете с рекламой, чаще всего разумнее выбрать политику вроде `strict-origin-when-cross-origin`.
Она даёт:
- приватность параметров (включая UTM и возможные ID пользователей);
- видимость домена-источника;
- предсказуемое поведение в разных браузерах.
Настройка заголовка Referrer-Policy: общие принципы
Вариантов внедрить политику несколько:
- через заголовки сервера (Nginx, Apache и др.);
- через `` в HTML;
- через настройки CDN или reverse-proxy.
Рекомендуется именно серверный вариант: он надёжнее и не зависит от HTML-разметки.
Что стоит сделать перед внедрением
- Проанализировать, где у вас в URL встречаются конфиденциальные данные:
- токены авторизации;
- e-mail в строке запроса;
- session-id;
- внутренние ID клиентов.
- Понять, какие внешние сервисы завязаны на реферер:
- платёжные системы;
- партнёрские программы;
- аналитика третьих сторон;
- виджеты и SaaS-сервисы.
После этого станет ясно, насколько жёстко вы можете ограничить передачу данных.
Настройка заголовка Referrer-Policy в Nginx
Теперь к конкретике. Настройка заголовка referrer policy nginx делается обычно в блоке `server` или `location`.
Пример (анализируем безопасный, практичный вариант):
```nginx
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
```
Пояснения по сути, а не по синтаксису:
- `strict-origin-when-cross-origin` — баланс безопасности и аналитики;
- `always` — заголовок будет добавлен и к успешным, и к ошибочным ответам (например, 404, 500), что снижает «дыры» в поведении.
Если у вас несколько сайтов или поддоменов, проверьте:
- нет ли конфликтующих заголовков в других конфигурационных файлах;
- не переопределяет ли что-то заголовки на уровне CDN (Cloudflare, Fastly и др.).
Частая ошибка при настройке в Nginx
Новички нередко:
- ставят одновременно разные политики в разных `location`-блоках;
- «копипастят» старые конфиги с `unsafe-url`, не понимая последствий;
- забывают перезапустить Nginx или проверить конфиг через `nginx -t`.
Результат — в одних разделах сайта у вас безопасная политика, в других льётся полный URL с параметрами наружу. На стороне аналитики и партнёров это выглядит как непредсказуемое поведение.
Как настроить Referrer-Policy в Apache
Для Apache принцип тот же — настраиваем заголовок сервера. Включаем модуль:
```apache
LoadModule headers_module modules/mod_headers.so
```
И добавляем правило, например, в конфиг виртуального хоста или `.htaccess`:
```apache
Header always set Referrer-Policy "strict-origin-when-cross-origin"
```
На что обращать внимание, когда решаете, как настроить referrer policy в apache:
- не дублируйте правила в `.htaccess` и основном конфиге одновременно;
- убедитесь, что не стоит другая политика в более «верхнем» уровне конфигурации;
- посмотрите, не добавляет ли хостинг свои заголовки автоматически.
Распространённые ошибки в Apache
- Использование нескольких разных заголовков Referrer-Policy — браузер будет ориентироваться на последний, а вы будете думать, что работает «первый».
- Применение `unsafe-url` на публичных сайтах, особенно с HTTPS.
- Пренебрежение тестированием: в продакшен влетает конфиг, который ломает аналитику или партнёрские интеграции.
Meta-тег referrer: когда он вообще нужен
Использовать `` стоит только если:
- у вас нет доступа к настройкам сервера;
- сайт на каком-нибудь конструкторе без нормального управления заголовками.
Но есть нюансы:
- серверные заголовки имеют больший приоритет у некоторых браузеров;
- не все старые браузеры корректно обрабатывают meta-опцию;
- сложнее поддерживать единообразие, если у вас несколько шаблонов и макетов.
Для серьёзного проекта лучше один раз настроить заголовок на сервере, чем латать HTML.
Типичные ошибки новичков при работе с Referrer-Policy
Ошибка 1: «Поставлю no-referrer — и всё будет безопасно и круто»
Итог:
- вы теряете ценную информацию о путях пользователя;
- партнёры жалуются, что у них «пустые рефереры»;
- аналитике приходится гадать, как ходит трафик между вашими проектами.
Решение:
- перед выбором радикальной политики оцените бизнес-процессы;
- если нет явной причины, используйте более мягкие политики (`strict-origin-when-cross-origin`, `origin-when-cross-origin`).
Ошибка 2: Игнорирование внутренних URL с чувствительными данными
Когда referrer policy что это ещё не до конца понято, разработчики иногда:
- передают ID пользователя, e-mail или токен в строке запроса (`?user_id=...`);
- используют такие URL в ссылках на внешние ресурсы;
- оставляют политику по умолчанию, которая раскрывает полный URL.
В результате внешние сайты получают лишние личные данные.
Решение:
- не передавать чувствительные данные через GET-параметры;
- если это неизбежно, ужесточать политику хотя бы на этих разделах;
- проверять рефереры в логах и инструментах отладки.
Ошибка 3: Отсутствие единой стратегии для домена
Частая картина:
- одни разработчики настраивают заголовки в Nginx;
- другие — добавляют meta-теги;
- третьи — что-то включают в CDN.
Получается мешанина, где разные части сайта ведут себя по-разному.
Решение:
- выбрать единую стратегию Referrer-Policy для домена;
- описать её в технической документации;
- централизованно управлять заголовками (сервер или CDN).
Ошибка 4: Выбор политики без учёта SEO и аналитики
Иногда безопасность рассматривают изолированно от маркетинга:
- ставят agressive-политику, не обсудив её с SEO-специалистами и аналитиками;
- через месяц все удивляются, почему «по статистике стало меньше переходов с партнёров».
Решение:
- внедрять изменения в Referrer-Policy только после обсуждения с:
- SEO-специалистом;
- аналитиком;
- при необходимости — юристом по персональным данным.
- протестировать политику на небольшом сегменте трафика (через A/B в CDN либо на одном поддомене).
Ошибка 5: «Скопировал с чужого блога — значит, всё нормально»
То, что подходит соседнему проекту, может повредить вашему:
- у них нет платных партнёрских ссылок — у вас есть;
- у них внутренний сервис — у вас публичный маркетплейс;
- у них нет сложной аналитики, а у вас — сквозная с кучей источников.
Для кого-то `no-referrer` — осознанное решение, для другого — потеря части бизнеса.
Решение:
- анализировать не только синтаксис, но и последствия;
- рассматривать referrer policy best practices для сайта как ориентир, а не догму.
Практические рекомендации по выбору политики
Чтобы не утонуть в теории, можно ориентироваться на простые сценарии.
Если у вас контентный сайт, блог, медиа
Обычно важно:
- видеть источники трафика;
- не передавать лишние параметры наружу.
Подходящие варианты:
- `strict-origin-when-cross-origin` — универсальный выбор;
- `origin-when-cross-origin` — если критично сохранять больше информации при переходах между HTTPS и HTTP-доменами (хотя HTTP уже редкость).
Если у вас приложение с личными кабинетами и чувствительными данными
Приоритет — приватность и соответствие требованиям по данным.
Рассмотрите:
- `same-origin` для защищённых разделов;
- `strict-origin` или даже `no-referrer` для некоторых внутренних панелей, административных интерфейсов.
Важно: не забывайте отделять публичную часть сайта (лендинги, маркетинг) от закрытой. Им могут быть нужны разные политики.
Если вы активно используете партнёрские программы
Здесь часто критично:
- чтобы партнёр видел чёткий реферер;
- не терялись переходы в статистике.
Компромисс:
- `strict-origin-when-cross-origin` — даёт домен, но скрывает хвосты URL;
- по договорённости с партнёрами можно обсуждать, достаточно ли им такой детализации.
Как проверить, что всё работает как задумано
После настройки не полагайтесь «на авось».
Полезные шаги:
- Откройте инструменты разработчика в браузере:
- вкладка Network;
- посмотрите любой запрос от страницы к внешнему ресурсу;
- убедитесь, что заголовок `Referer` выглядит так, как вы ожидали.
- Проверьте ответ сервера:
- в тех же DevTools удостоверьтесь, что в ответе есть заголовок `Referrer-Policy` с нужным значением.
- Протестируйте разные сценарии:
- переход внутри сайта;
- переход на внешний домен по ссылке;
- редиректы (особенно через HTTP→HTTPS и наоборот, если ещё где-то остался HTTP).
Итог: как подойти к Referrer-Policy без лишней боли
Если обобщить подход в несколько тезисов:
- Сначала разберитесь, что для вас важнее: максимум аналитики, максимум приватности или баланс.
- Не копируйте чужие настройки «как есть» — адаптируйте их под свои процессы.
- Для большинства современных сайтов разумным стартом будет `strict-origin-when-cross-origin`.
- Настраивайте политику на уровне сервера (Nginx/Apache), а не только в HTML.
- Избегайте крайностей вроде `unsafe-url`, если не понимаете, зачем они вам.
Так вы получите и защиту данных, и рабочую аналитику, а ваш заголовок Referrer-Policy будет не просто «галочкой в чек-листе безопасности», а реальным управляемым инструментом.
