¿Qué es una Cookie?

El HTTP es un protocolo sin estado: cada petición que el navegador hace a un servidor se trata como si fuera la primera, sin memoria de la anterior. Las cookies nacieron para resolver justo ese problema. Cuando visitas una web, el servidor puede incluir en su respuesta la cabecera Set-Cookie, con un par nombre-valor y, opcionalmente, una fecha de caducidad, un dominio y varios atributos de seguridad.

El navegador guarda ese archivo pequeño y lo devuelve automáticamente en la cabecera Cookie cada vez que vuelve a pedir algo al mismo dominio. Así es como una tienda online recuerda lo que llevas en el carrito entre una página y otra, o cómo un sitio te mantiene con la sesión iniciada sin pedirte la contraseña en cada clic. La especificación técnica RFC 6265 la describe como un mecanismo de gestión de estado sobre un protocolo que, de fondo, sigue sin tenerlo.

No todas las cookies sirven para lo mismo. Las hay imprescindibles para que la web funcione, como la de sesión o la del carrito, otras que solo guardan preferencias como el idioma o la moneda, y otras que existen para medir tráfico o mostrar publicidad. Esa última categoría es la que más relación tiene con el SEO técnico, porque condiciona qué scripts se cargan antes o después de que el usuario dé su consentimiento.

La frontera entre ambas no depende del contenido de la cookie, sino de quién la coloca y desde qué dominio se sirve. Un mismo proveedor de analítica puede operar como cookie propia si se configura en el dominio del sitio, o como cookie de terceros si carga su script directamente desde su propio dominio.

Una cookie de sesión no lleva fecha de caducidad: vive mientras el navegador está abierto y desaparece al cerrarlo. Es la que mantiene, por ejemplo, un formulario a medio rellenar o una sesión de usuario activa. Una cookie persistente, en cambio, incluye el atributo Expires o Max-Age y sobrevive días, meses o incluso años, hasta esa fecha o hasta que el usuario la borre a mano.

El atributo SameSite decide si una cookie viaja también cuando la petición viene de otro dominio. Con Strict solo se envía en peticiones que nacen en el propio sitio; con Lax, el valor por defecto en la mayoría de navegadores modernos, también se envía al navegar directamente a la página; con None viaja en cualquier contexto, pero exige el atributo Secure y conexión HTTPS. Este control nació como respuesta a ataques CSRF, donde una web maliciosa aprovechaba que el navegador enviaba cookies de sesión de otro sitio sin que el usuario lo supiera.

Junto a SameSite, dos atributos más cierran el candado: HttpOnly impide que JavaScript lea la cookie desde el navegador, y Secure obliga a que solo viaje por HTTPS. Cuando una cookie de terceros queda bloqueada, algunos anunciantes recurren a técnicas alternativas como el píxel de seguimiento o el fingerprinting, cada una con sus propios límites técnicos y legales.

En la Unión Europea, instalar cualquier cookie que no sea estrictamente necesaria para el funcionamiento del sitio requiere el consentimiento previo del usuario, según el artículo 5.3 de la Directiva ePrivacy (2002/58/CE). Si esa cookie permite identificar a una persona, además entra en juego el RGPD como marco de protección de datos. Por eso todo banner de cookies que de verdad bloquea scripts hasta que el usuario decide cumple una función legal concreta, más allá de la estética.

La postura de los navegadores frente a las cookies de terceros ha dado varios giros. Safari las bloquea por defecto desde 2020 con Intelligent Tracking Prevention, y Firefox hace lo mismo desde 2019 con Enhanced Tracking Protection. Chrome, que llevaba años anunciando su desaparición, cambió de rumbo: en abril de 2025 confirmó que mantendría las cookies de terceros sin el aviso adicional que había planeado, y en octubre de 2025 retiró la mayoría de las APIs de Privacy Sandbox que había construido como alternativa, al no lograr suficiente adopción del sector publicitario.

Para quien gestiona una web, esto tiene una lectura práctica: las cookies propias siguen siendo la base más estable para analítica y personalización, mientras que depender de cookies de terceros implica aceptar que Safari y Firefox seguirán bloqueándolas, aunque Chrome ya no las elimine. Cualquier auditoría de SEO técnico debería revisar qué cookies se cargan antes del consentimiento, un fallo habitual que penaliza cumplimiento y velocidad de carga.

• Clasifica cada cookie por finalidad (necesaria, preferencias, estadística, marketing) antes de escribir la política de cookies, no después.
• Configura SameSite=Lax como valor por defecto y reserva None solo para las cookies que de verdad necesitan viajar entre dominios.
• Añade Secure y HttpOnly a toda cookie de sesión para reducir el riesgo de robo por script malicioso.
• Bloquea la carga de scripts de terceros hasta que el usuario dé su consentimiento explícito; retrasar solo el registro de la cookie no basta.
• Pon una fecha de caducidad realista a las cookies persistentes: una cookie de preferencias no necesita vivir dos años si el usuario cambia de idea antes.
• Documenta en la política de cookies el nombre real de cada cookie, su proveedor y su duración, no una descripción genérica.

• Cargar el script de analítica o de un píxel de seguimiento antes de que el usuario acepte, aunque el banner de consentimiento ya esté visible en pantalla.
• Confundir "cookie propia" con "cookie respetuosa con la privacidad": una cookie propia también puede recoger datos sensibles si no se diseña con cuidado.
• Fijar cookies de sesión sin Secure en sitios que sirven parte del contenido por HTTP, dejando la sesión expuesta en redes no cifradas.
• Dar por hecho que Chrome ya eliminó las cookies de terceros, una idea que circula desde 2020 y que la propia Google desmintió en abril de 2025.
• Usar SameSite=None por defecto en todas las cookies "por si acaso", ampliando la superficie de ataque CSRF sin necesidad real.