Referrer-Policy y SEO: qué es el referrer y cómo controlarlo

Cuando en GA4 aparece un pico de tráfico «directo» sin explicación, o un socio de afiliación dice que no ve tus visitas, la causa suele ser una política de referrer: alguien puso no-referrer en la cabecera, un enlace llevaba rel="noreferrer" o la visita pasó de https a http. Casi nada de lo que se publica en español sobre el tema llega a ese punto; se queda en listar los ocho valores.

Aquí explico qué viaja en el referrer, cómo se controla, qué tiene que ver (y qué no) con el SEO y cómo lo tengo yo configurado en cristofercruz.net. Los comportamientos de la tabla los he medido en Chromium 141 con servidores locales, no los doy por la documentación sola.

Qué es el referrer y qué contiene

Cada vez que el navegador pide un recurso (una página tras un clic, una imagen, un script, un iframe) puede añadir la cabecera Referer con la dirección de la página desde la que sale la petición. Así el servidor de destino sabe de dónde llega el visitante. La cabecera se escribe con una sola «r» en medio por una errata histórica del estándar; la cabecera de control, Referrer-Policy, se escribe bien.

Según MDN, el valor puede incluir origen, ruta y parámetros de consulta, pero nunca el fragmento (#seccion) ni las credenciales de la URL. Y es una cabecera de petición prohibida: desde JavaScript no puedes ponerla a mano, solo influir en ella con la política. En el navegador también existe document.referrer, que es lo que leen la mayoría de las etiquetas de analítica en el cliente.

Conviene separar dos cosas. El referrer lo decide la página que enlaza, no la que recibe. Y la política que importa es la de la página de origen: la que pongas tú gobierna lo que sale de tu web, y la de los demás gobierna lo que llega a ti.

Los cuatro mecanismos y cuál gana

Puedes fijar la política en cuatro sitios, de lo más general a lo más concreto.

Hay una trampa de ortografía que MDN avisa expresamente: el valor de la meta lleva guion (no-referrer) y la relación del enlace no (noreferrer). Si te equivocas con un valor, el navegador lo ignora sin avisar y aplica el de por defecto; yo lo he visto con Referrer-Policy: noreferrer, que no impidió que se enviara el origen.

Sobre la precedencia, la especificación del W3C dice que cuando varias fuentes fijan política gana el último valor reconocido, y que la cabecera admite una lista separada por comas para dar un valor de reserva a navegadores antiguos. Lo he contrastado en Chromium 141, con una página en https y un destino en otro origen:

Los ocho valores y qué envía cada uno

MDN y el W3C coinciden en ocho valores. La tabla muestra qué recibió el destino en mi prueba con Chromium 141: la página de origen tenía una ruta y parámetros, y probé el clic a un enlace del mismo origen, a otro origen en https y a un destino en http. La última fila es lo que ocurre sin ninguna política declarada.

«Origen» es esquema, dominio y puerto: https://cristofercruz.net/, sin ruta. «URL completa» incluye la ruta y los parámetros, nunca el fragmento. Las filas coinciden con las tablas de MDN, salvo un matiz: origin envía el origen incluso en una degradación a http, y por eso no es «estricto».

La degradación de https a http es el caso que más confunde. Si tu web enlaza a un destino en http (o te llega una visita a una variante http, algo que pasa mientras convivan las variantes http, https y www de un mismo sitio), los valores «strict» y no-referrer-when-downgrade no envían nada. Por eso un destino sin https pierde la fuente de todo el tráfico que le mandas, tengas la política que tengas.

El valor por defecto: de dónde sale y por qué fijarlo

El valor por defecto actual es strict-origin-when-cross-origin. MDN explica que se aplica cuando no hay política o el valor no es válido, y que antes era no-referrer-when-downgrade. En Chrome el cambio llegó con la versión 85, según el artículo de Chrome de julio de 2020, y solo afecta a los sitios que no declaran política propia.

La consecuencia práctica de aquel cambio es que, desde entonces, quien te enlaza ya no te manda la ruta completa de su página sino solo su dominio, salvo que declare otra política. Chrome lo avisó así: los registros del servidor y la analítica que dependan de la URL completa del referrer ven menos granularidad.

web.dev recomienda no depender del defecto y fijar de forma explícita una política que proteja la privacidad, como strict-origin-when-cross-origin o una más estricta, porque los valores por defecto varían entre navegadores y pueden cambiar. Yo la declaro por la cabecera, como verás más abajo.

Qué tiene que ver con el SEO y qué no

Sobre posicionamiento, lo que puedo afirmar es poco y conviene decirlo así: no he encontrado ninguna documentación de Google que presente el referrer, o Referrer-Policy, como señal de ranking. La página de Google sobre cómo calificar los enlaces salientes documenta tres valores de rel (nofollow, sponsored y ugc) y no menciona noreferrer ni noopener. Que no esté documentado no equivale a demostrar que no influya, pero no hay nada en lo que apoyar lo contrario, y yo no lo trato como palanca.

Tampoco tengo documentación que diga si Googlebot envía la cabecera Referer al rastrear. En los logs que he mirado suele aparecer vacía; compruébalo en los tuyos antes de dar nada por hecho (lo explico en el artículo de análisis de logs SEO).

Es decir, el efecto en SEO es indirecto y pasa por la medición. Si no puedes atribuir la visita, tomas peores decisiones sobre qué contenido funciona.

Analítica: por qué te aparece tráfico directo

La ayuda de GA4 define el canal Direct como el de los usuarios que llegan «mediante un enlace guardado o escribiendo tu URL», y Referral como el de los que llegan por enlaces no publicitarios desde otros sitios, con medio referral, app o link. Lo que esa ayuda no describe es qué pasa cuando el referrer se suprime. En la práctica, una visita sin Referer y sin parámetros de campaña no tiene nada a lo que atribuirse y acaba como directa. Esto último es una consecuencia habitual, no una frase de la documentación de Google.

Los escenarios en los que lo he visto o que están documentados:

• Quien te enlaza usa rel="noreferrer" o no-referrer. Tu analítica no puede saber de dónde viene el clic.
• El enlace salta de https a http. Con la política por defecto no viaja nada.
• El referrer llega recortado al origen. Es el efecto del cambio de Chrome: sigues viendo el dominio, no la página. Plausible lo resume así: la analítica «seguirá mostrando la fuente de tu tráfico pero solo a nivel de dominio»; el total de tráfico oscuro no cambia, pero ya no sabes qué hilo o qué entrada te enlazó.
• Tus propios dominios. GA4 no registra como referral el tráfico cuyo referrer coincide con el dominio de la página o con sus subdominios, y permite excluir hasta 50 dominios no deseados por flujo de datos. Esa exclusión no es retroactiva. Si cruzas dominios, mira cómo encaja con lo que cuento en el artículo sobre subdominios y SEO.

Hay una afirmación que circula sobre los enlaces de la respuesta generada por IA de Google: que llevarían noreferrer y por eso su tráfico aparece como directo. La encontré en un artículo de un proveedor de analítica que no cita ninguna fuente primaria de Google, y yo no la he verificado. Si te importa, la comprobación es sencilla: inspecciona el HTML de uno de esos enlaces y mira si lleva rel="noreferrer".

Dentro de tu propio sitio ocurre lo contrario: con la política por defecto, la URL completa viaja en los saltos internos, así que tus páginas se ven entre sí con su ruta. Es otra razón para no tocar el valor global a la ligera, y un detalle que importa cuando analizas cómo funciona tu enlazado interno con datos de recorrido.

Enlaces salientes: noreferrer, noopener y nofollow

Son tres cosas distintas que se confunden porque suelen ir juntas en el mismo atributo rel.

Según MDN, target="_blank" ya aporta por sí solo el comportamiento de noopener, de modo que añadirlo es redundante en los navegadores actuales, aunque inofensivo. El efecto sobre backlinks es el que cabe esperar: el enlace sigue en el HTML con su href, y lo que no llega es tu dominio en la analítica del destino. Si el programa de afiliación al que enlazas atribuye por el referrer, un noreferrer te puede costar comisiones. Si marcas enlaces patrocinados, usa sponsored y deja el referrer en paz; si quieres que el destino sepa al menos de qué sitio llega, origin en el atributo referrerpolicy basta.

Iframes e incrustaciones de terceros

El atributo referrerpolicy también existe en <iframe>, con los mismos ocho valores y el mismo defecto. Los atributos restantes del iframe y su relación con la indexación los trato en el artículo de iframes y SEO; aquí solo me interesa el referrer.

El caso real es YouTube. Su documentación para desarrolladores dice que quien use el reproductor incrustado «debe proporcionar identificación mediante la cabecera HTTP Referer», que no hay que fijar una política que la suprima y que recomiendan strict-origin-when-cross-origin. Para window.open pide no usar noreferrer. La página indica como última actualización el 14 de septiembre de 2026.

No es teórico. En diciembre de 2025, Simon Willison documentó vídeos incrustados que fallaban con el error 153 («Video player configuration error») porque el middleware de seguridad de Django enviaba por defecto Referrer-Policy: same-origin, que no manda nada a otros orígenes. La solución fue pasar a strict-origin-when-cross-origin. Lo que no he comprobado yo es si otros proveedores (mapas, formularios, pasarelas de pago) exigen lo mismo; solo lo he visto documentado para YouTube.

<iframe
  src="https://www.youtube.com/embed/ID_DEL_VIDEO"
  title="Título descriptivo del vídeo"
  loading="lazy"
  referrerpolicy="strict-origin-when-cross-origin"
></iframe>

Errores típicos

En una auditoría SEO miro la cabecera, las metas y los atributos de enlaces e iframes juntos, porque es habitual que una política global bien puesta quede anulada por un atributo suelto en una plantilla.

Cómo enviar la cabecera en Apache y Nginx

La cabecera es la opción más limpia: una línea para toda la web, incluidas las respuestas de error. En Apache necesitas mod_headers:

<IfModule mod_headers.c>
  Header always set Referrer-Policy "strict-origin-when-cross-origin"
</IfModule>

En Nginx, el parámetro always es el que marca la diferencia:

add_header Referrer-Policy "strict-origin-when-cross-origin" always;

Los he probado en Apache 2.4.58 (con el bloque anterior en un .htaccess) y en Nginx 1.24.0, con curl -sI. Resultado: ambos enviaron la cabecera en un 200 y en un 404. Nginx sin always solo la envió en el 200; en un 403 y en el 404 no apareció. La misma regla de Apache también cubre los errores, y lo sé porque lo vi en la prueba. No he probado otras configuraciones, como un proxy inverso delante o una CDN que reescriba cabeceras.

Cómo lo tengo en mi web

Esto es lo que consta en el código de cristofercruz.net y lo que he comprobado en producción.

• El .htaccess envía Referrer-Policy: strict-origin-when-cross-origin con Header always set, dentro de IfModule mod_headers.c, junto con X-Content-Type-Options: nosniff y X-Frame-Options: SAMEORIGIN.
• En producción, curl -sI devuelve esa cabecera en la home, en una entrada del blog, en robots.txt y en un 404 (comprobado el 8 de octubre de 2026). El hosting añade además content-security-policy: upgrade-insecure-requests, que no está en el repositorio.
• No hay ninguna meta referrer en las plantillas ni ningún atributo referrerpolicy en el código del sitio. Tampoco uso iframes en plantillas ni en los artículos.
• Los botones de compartir del artículo (LinkedIn, X y Facebook) llevan rel="noopener noreferrer", así que esas redes no reciben mi referrer. El enlace al proveedor de la política de cookies también.
• Los enlaces a redes sociales del pie y de contacto llevan rel="me noopener", y las referencias de los artículos rel="noopener": reciben el origen https://cristofercruz.net/, que es lo que busco.
• Las etiquetas de analítica (GA4, GTM, Clarity, píxeles) son plantillas inertes que no se cargan sin consentimiento. Cuando se activan, sus peticiones salen de mi página con el origen como referrer.

Lo que no puedo darte son datos: no he medido qué parte de mi tráfico directo en GA4 se debe a referrers suprimidos, así que no te cuento cifras de efecto. Y una decisión que sigue abierta: los botones de compartir con noreferrer hacen que Facebook, X y LinkedIn no vean de dónde llega el enlace; es deliberado de seguridad, pero es un dato de analítica que renuncio a tener.

Cómo auditarlo

Hay cuatro comprobaciones, de la más rápida a la más fina.

1. La cabecera. curl -sI https://ejemplo.com/ | grep -i referrer. Pruébala en la home, en un 404 y en un recurso estático. Si falta en alguno, tienes un problema de always o de ámbito.
2. La meta y los atributos. En el código fuente, busca name="referrer", referrerpolicy y noreferrer. Una meta o un atributo pueden anular la cabecera.
3. Lo que se envía de verdad. En DevTools, pestaña Network, abre una petición y mira Referrer Policy y la cabecera Referer. web.dev indica que Chrome, Edge y Firefox lo muestran; Safari enseña el Referer enviado pero no la política.
4. Cómo reacciona tu servidor. Con curl -e "https://origen.com/pagina?x=1" URL envías esa cabecera y ves cómo responde o qué registra tu log. En una prueba mía contra un servidor que escribía la cabecera recibida, el valor llegó tal cual, con el parámetro, y sin el fragmento cuando se lo quité al construir la petición.

Para el análisis agregado, el campo Referer del log y el informe de adquisición de GA4 comparados dan una idea de cuánto tráfico directo es sospechoso.

Preguntas frecuentes

Referencias y fuentes

1. Referrer-Policy MDN Web Docs
2. Referer MDN Web Docs
3. Referrer Policy W3C
4. Referer and Referrer-Policy best practices web.dev
5. A new default Referrer-Policy for Chrome Chrome for Developers
6. Cómo calificar tus enlaces salientes a Google Google Search Central
7. Default channel group Ayuda de Google Analytics
8. Identify unwanted referrals Ayuda de Google Analytics
9. YouTube API Services: Required Minimum Functionality Google for Developers
10. YouTube embeds fail with a 153 error Simon Willison
11. How Chrome's default referrer policy affects your site analytics Plausible