(not provided): por qué ya no puedes ver las keywords que te traen tráfico

Por Santos Jaimes · 22 de agosto de 2026 ·

Si alguna vez abriste Analytics buscando las palabras clave que traían tráfico a tu sitio y te topaste con un enorme y deprimente "(not provided)", ya conoces el problema. La respuesta corta: es un poco de tecnología y bastante de decisión. La larga es más entretenida.

Primero: la época dorada en la que sí veíamos todo

Hubo un tiempo — más o menos hasta 2011 — en el que quien hacía SEO vivía como rey. Sabíamos exactamente qué palabra escribió cada persona antes de llegar a nuestro sitio.

¿Qué es el referrer?

Cada vez que haces clic en un enlace, tu navegador le manda al sitio de destino una nota que dice: "oye, este señor viene de tal página". Esa nota es una cabecera HTTP llamada Referer. Los servidores la guardan en sus logs junto con la IP, la fecha y el navegador.

Un log típico de Apache se veía así:

99.23.161.18 - - [10/Oct/2008:21:15:07] "GET /menu.html HTTP/1.1" 200 2225
"http://www.google.com/search?q=pizza+napoletana+denver" "Mozilla/5.0..."

¿Ves esa parte del final? ?q=pizza+napoletana+denver. Ahí estaba el oro. La URL de búsqueda de Google incluía el parámetro q= con la keyword completa, y a veces hasta la posición en la que estaba tu resultado.

Así que si eras el dueño de Little Italy Kitchen, restaurante italiano en Denver, podías abrir tu informe y ver esto:

Sabías qué palabras traían gente, cuáles traían gente que reservaba mesa, y cuáles solo traían curiosos. Era hermoso. Era tener rayos X del cerebro de tus clientes.

Luego llegó octubre de 2011 y se acabó la fiesta

En octubre de 2011 Google anunció su movimiento hacia la búsqueda segura por HTTPS. Al usar el protocolo seguro, el referrer ya no pasaba la keyword. Matt Cutts, entonces jefe del equipo antispam, dijo que solo afectaría a un porcentaje de un solo dígito de las búsquedas.

Spoiler: no fue un porcentaje de un solo dígito. Fue prácticamente todo.

Primero fue Google.com para usuarios con sesión iniciada, luego Chrome, y después Firefox también adoptó la búsqueda segura por defecto, lo que hizo crecer sin parar la cantidad de keywords marcadas como "(not provided)". Y dependiendo del dispositivo, muchos ya llevaban tiempo usando búsqueda segura sin enterarse: Safari desde iOS 6, por ejemplo.

Para 2013 y 2014, el "(not provided)" era básicamente el 100% del tráfico orgánico de Google.

Ahora sí: ¿fue la tecnología o fue Google?

Aquí está la parte interesante, porque la mayoría de la gente repite "es que HTTPS encripta todo" y eso es medio verdad y medio mito.

El argumento técnico real, que sí existe

La especificación de HTTP tiene una regla vieja y muy sensata: un navegador no debe enviar la cabecera Referer cuando el usuario va de una página HTTPS a una página HTTP.

¿Por qué? Porque si estás en una página segura y encriptada, y haces clic hacia una sin encriptar, ese referrer viajaría en texto plano por la red. Cualquiera en el mismo wifi del café podría leer de dónde venías. Y esa URL de origen podría contener información sensible: un token, un identificador de sesión, o simplemente el hecho de que estabas buscando algo íntimo.

Así que sí: hay un motivo técnico legítimo. Es una regla de seguridad de sentido común, y sigue aplicando hoy.

Pero aquí viene la trampa

Esa regla explica el problema solo si tu sitio sigue en HTTP. Y hoy en día casi nadie está en HTTP. Prácticamente toda la web migró a HTTPS hace años.

Entonces... si Google está en HTTPS y tu sitio está en HTTPS, el referrer sí se envía normalmente. HTTPS → HTTPS no tiene ese problema. La cabecera viaja perfecta.

¿Entonces por qué seguimos sin ver las keywords? Porque Google decidió quitarlas a propósito.

La jugada del meta referrer

Google implementó una etiqueta llamada meta referrer — y políticas de referrer equivalentes — que le dice al navegador: "cuando alguien salga de aquí, manda solo el dominio, no la URL completa".

El resultado es que los clics desde búsquedas de Google reportan su referrer simplemente como https://www.google.com, o el dominio de Google que corresponda, sin ningún dato de keyword asociado.

O sea: el sobre llega, pero viene vacío. Google podría mandar la keyword sin ningún riesgo de seguridad. Simplemente eligió no hacerlo.

El veredicto

HTTPS fue el vehículo, no el conductor. Google usó la migración como el momento perfecto para cortar el flujo de datos, pero la decisión de cortar las keywords fue una política de producto, no una limitación técnica insuperable.

¿Y por qué lo hizo? Las dos versiones de la historia

Aquí hay dos bandos y ambos tienen argumentos decentes. Te presento los dos y tú decides.

Versión A: fue por privacidad

Es la versión oficial de Google, y el argumento es serio: no debería descartarse a la ligera. Regímenes represivos — y algunos que no lo parecen tanto — monitorean agresivamente el comportamiento de búsqueda. Si tu búsqueda viaja en texto plano hacia cada sitio que visitas, tu proveedor de internet, tu gobierno o cualquiera que espíe la red sabe exactamente qué buscaste.

Piénsalo con casos reales: alguien buscando síntomas de una enfermedad estigmatizada, o un abogado de divorcio, o un grupo de apoyo para adicciones. Cada una de esas búsquedas viajando abiertamente hacia cada sitio que visita esa persona es un problema de verdad, no un tecnicismo.

Y no fue solo Google: Yahoo! también anunció el cambio a HTTPS por defecto, y la tendencia general del sector fue hacia proteger la privacidad de las búsquedas.

Versión B: fue por dinero

El argumento crítico más citado en el sector señala algo incómodo: Google dice que es por privacidad, pero los escépticos sostienen que en realidad estaba oscureciendo los referrers de keywords para hacer su plataforma de anuncios más valiosa. Y apuntan a una inconsistencia difícil de esquivar: si es una invasión de privacidad para el tráfico orgánico, también debería serlo para el tráfico pagado.

Ese es el punto que más duele. Durante años, los anunciantes sí seguían viendo sus keywords. La privacidad protegía al usuario del SEO gratuito, pero no del anunciante que pagaba. Difícil no levantar una ceja.

Mi lectura, para lo que vale

Probablemente ambas cosas son ciertas a la vez. Las empresas rara vez toman decisiones por una sola razón. Google tenía un motivo legítimo de privacidad y un incentivo comercial que apuntaba en la misma dirección. Cuando la ética y el negocio coinciden, la decisión se toma sola.

¿Qué significa esto en la práctica?

Volvamos al restaurante. Marco, el dueño de Little Italy Kitchen, quiere saber si su nueva página sobre catering italiano para bodas en Denver está funcionando.

Antes de 2011, Marco abría Analytics y veía: "italian wedding catering denver — 45 visitas — 3 reservas". Fin del análisis.

Hoy, Marco abre su analítica y ve: "Búsqueda orgánica — 45 visitas — 3 conversiones". ¿Qué buscaron? Misterio. Como pedir que te describan una pizza sabiendo únicamente que era redonda.

Como explica The Art of SEO, Google simplemente no pasa los datos de keyword a tu sitio web, y por eso ningún paquete de analítica puede listar las consultas de búsqueda del tráfico orgánico entrante. No es que tu herramienta sea mala: es que el dato no llega.

Entonces, ¿qué sí podemos hacer hoy?

No todo está perdido. El sector se adaptó. Estas son las salidas reales.

1. Search Console: el consuelo oficial

Google te quitó la keyword del referrer, pero te la devuelve parcialmente por otra puerta. Search Console te muestra clics, impresiones, CTR y posición media por consulta. No es lo mismo, pero es lo mejor que hay.

Según The Art of SEO, el dato de visitantes más valioso de Google no viene de Analytics, sino de Search Console, en forma de clics e impresiones por consulta.

2. Cruzar Search Console con Analytics

Puedes configurar tu analítica para saber qué páginas reciben ese tráfico orgánico, y luego usar Search Console para ver qué consultas llevan a esas páginas. Uniendo ambas fuentes reconstruyes buena parte del rompecabezas.

Marco no sabrá la keyword exacta de cada visita, pero sí sabrá que su página de catering recibe tráfico orgánico y que en Search Console esa misma página aparece para "wedding catering denver", "italian catering colorado" y "buffet italiano boda denver". Junta las piezas y ya tienes el 80% de la película.

3. Analizar por landing page, no por keyword

Este es el cambio mental más importante de todos. En vez de preguntarte "¿qué keyword convierte?", pregúntate "¿qué página convierte?". Cada página está optimizada para un grupo de términos relacionados, así que el rendimiento de la página es un sustituto bastante decente del rendimiento de sus keywords.

4. Herramientas de terceros

Existen herramientas diseñadas específicamente para reconstruir datos de comportamiento por keyword dentro de la analítica, combinando fuentes para estimar qué consulta trajo a cada usuario. Son aproximaciones estadísticas, no verdad absoluta. Úsalas con criterio.

5. Los logs del servidor siguen ahí

Aunque no traigan keywords de Google, tus logs siguen siendo la herramienta más vieja y más honesta de la caja. Te dicen qué pidió cada visitante, cuándo, con qué navegador y de qué dominio vino. Para SEO técnico — seguimiento de Googlebot, errores 404, presupuesto de rastreo — siguen siendo insustituibles.

6. Los datos de referrer NO desaparecieron del todo

Ojo con esto, porque mucha gente lo confunde: solo se perdieron las keywords de búsqueda. El referrer de otros sitios sigue funcionando perfecto.

Y hay un detalle valiosísimo ahí: los datos de referrer siguen sirviendo para identificar de dónde viene tu tráfico no orgánico, y muchas veces descubres enlaces nuevos en los informes de referrer antes de que tus herramientas de backlinks los reporten.

Si un blog de comida de Denver enlaza a Little Italy Kitchen, Marco lo ve en sus referrers ese mismo día. Eso no se perdió.

→ Más sobre cómo conseguir esos enlaces aquí

Un detalle de contexto: HTTPS también trajo cosas buenas

Para no quedarnos con el sabor amargo: la migración no fue solo pérdida de datos. En 2014 Google anunció que la seguridad de la página era un factor de ranking, y que las páginas en servidor seguro recibían un pequeño impulso.

Hoy HTTPS es simplemente el estándar. Un sitio en HTTP puro se ve tan anticuado como un menú en Comic Sans.

→ Más sobre redirecciones 301 y canonicalización aquí

Conclusión: la web se volvió más privada, y nosotros más creativos

Resumiendo en tres frases:

1. La tecnología dio la excusa: la regla HTTPS→HTTP de no enviar referrer es real y es sensata.
2. Google tomó la decisión: con el meta referrer, eligió no mandar la keyword ni siquiera cuando técnicamente podía.
3. El sector se adaptó: Search Console, análisis por landing page y herramientas de terceros llenaron buena parte del hueco.

¿Fue justo? Depende de a quién le preguntes. Lo que sí es cierto es que perder el dato de keyword nos obligó a dejar de obsesionarnos con palabras sueltas y empezar a pensar en temas, intención de búsqueda y páginas completas — que, irónicamente, es exactamente lo que Google quería que hiciéramos desde el principio.

Marco no sabe qué escribió exactamente el turista alemán que terminó cenando osso buco en Little Italy Kitchen. Pero sabe que llegó por la página de "authentic italian dining downtown Denver", que se quedó cuatro minutos, y que reservó mesa.

A veces eso es suficiente.

Bibliografía

1. theartofseo.txt — The Art of SEO (Enge, Spencer, Stricchiola). "Web Logs, Search Console Reports, and Analytics", p. 153: el hecho de que Google no pasa los datos de keyword al sitio y por tanto ningún paquete de analítica puede listarlos. "Valuable SEO Data in Web Analytics", p. 388: Search Console como fuente más valiosa de datos de visitantes, y la utilidad persistente de los referrers para identificar tráfico no orgánico y descubrir enlaces nuevos antes que las herramientas de backlinks. "Server-Side Log Analysis", p. 97: análisis de logs del lado del servidor. "HTTP and HTTPS pages", p. 264: el impulso de ranking anunciado en 2014, el riesgo de contenido duplicado al mantener ambas versiones e implementación de HSTS. Tabla 8-3, p. 400: diferencias entre Search Console y la analítica, incluida la retención de 16 meses.
2. seoallinone.txt — SEO All-in-One For Dummies. Libro 7, "Handling Secure Server Problems", p. 602: la regla de la especificación HTTP sobre no enviar el referrer en transiciones de HTTPS a HTTP y su justificación de seguridad. Libro 8, "Employing Site Analytics", pp. 619–620: el crecimiento del "(not provided)" en los informes conforme Chrome y Firefox adoptaron la búsqueda segura por defecto.
3. SEOWarrior.txt — SEO Warrior (John I. Jerkovic). Capítulo 6, "Web Stats Monitoring", pp. 102–103: formatos de log NCSA Common y NCSA Combined, incluido el campo referrer y el ejemplo de una entrada con el parámetro de consulta completo. Capítulo 5, "External Ranking Factors", pp. 94–95: uso histórico de los datos de referrer para análisis de keywords.
4. Fuentes en línea consultadas — el anuncio de búsqueda segura de Google de octubre de 2011 y la declaración de Matt Cutts sobre el impacto esperado; la documentación del sector sobre la implementación del meta referrer en 2012 y su efecto de reducir el referrer al dominio; la adopción de SSL por defecto en Chrome y Firefox; y el comportamiento actual de document.referrer en transiciones HTTPS→HTTP. Estos hechos son posteriores o ajenos a los libros del proyecto y se citan como fuentes externas.