Cabeceras de seguridad HTTP y SEO: HSTS, CSP, nosniff y cómo comprobarlas

Primero la advertencia: añadir cabeceras de seguridad no sube por sí solo las páginas en los resultados. No lo prometas ni a ti ni a un cliente.

Las conexiones reales son estas:

• HTTPS. La documentación de Google recomienda servir las páginas por HTTPS. La cabecera HSTS ayuda a mantener al visitante en HTTPS después de la primera visita.
• Renderizado de la página. Un CSP mal ajustado puede bloquear scripts, estilos o contenido incrustado que la página necesita. Entonces se ve distinta de lo que esperas, también para las herramientas que la renderizan.
• Tipos de archivo. La cabecera nosniff obliga al navegador a respetar el tipo MIME declarado. Un script o una hoja de estilos con el tipo equivocado se bloquea.
• Reglas de indexación. X-Robots-Tag es en sí una cabecera SEO: transporta instrucciones de indexación en HTTP.
• Un sitio hackeado. El spam inyectado, las redirecciones a direcciones desconocidas o los avisos de malware dañan la presencia del sitio en buscadores. La higiene de seguridad (CSP, atributos de cookies, actualizaciones) reduce ese riesgo, pero no lo elimina.

El enfoque honesto es este: las cabeceras de seguridad no aceleran el crecimiento, quitan riesgos que pueden frenarlo. Para los temas técnicos vecinos mira las guías de robots.txt y de la etiqueta canonical.

La cabecera Strict-Transport-Security (HSTS, definida en el RFC 6797) indica al navegador que abra el sitio solo por HTTPS durante un tiempo determinado. Un valor típico:

Strict-Transport-Security: max-age=31536000; includeSubDomains

El número de max-age está en segundos, aquí un año. Algunas reglas prácticas:

• Los navegadores respetan HSTS solo en respuestas recibidas por HTTPS. Por HTTP simple, la cabecera se ignora.
• Tras la primera visita, el navegador pasa a HTTPS por sí mismo, sin petición HTTP ni redirección. Para quien vuelve, eso ahorra un intercambio con el servidor.
• Empieza con un max-age corto, por ejemplo max-age=300. Si pasados unos días nada falla, auméntalo.
• includeSubDomains extiende la regla a todos los subdominios. Antes asegúrate de que cada uno funciona de verdad por HTTPS.
• El token preload, junto con includeSubDomains y un max-age de al menos un año, permite enviar el dominio a la lista de hstspreload.org. Salir de la lista es difícil, así que hazlo al final.

La cabecera está descrita en la documentación de MDN. HSTS no sustituye a la redirección de HTTP a HTTPS: la primerísima visita sin ella queda desprotegida.

La cabecera Content-Security-Policy (CSP) enumera desde dónde puede una página tomar scripts, estilos, imágenes y marcos. Es la defensa principal contra el código ajeno inyectado. Un ejemplo básico de política:

Content-Security-Policy: default-src 'self'; img-src 'self' data:; script-src 'self'; frame-ancestors 'self'

Desde el SEO, el riesgo principal es una política tan estricta que rompa la página. La analítica, un gestor de etiquetas, un chat, las fuentes de otro dominio: todo debe permitirse de forma explícita o no se cargará.

Por eso conviene implantar CSP por fases:

1. Activa Content-Security-Policy-Report-Only. El navegador solo informa de las infracciones y no bloquea nada.
2. Mira en la consola del navegador o en los informes qué recursos incumplen la política.
3. Añade los orígenes legítimos y elimina los que no necesitas.
4. Cambia la cabecera a Content-Security-Policy.

Evita 'unsafe-inline' en script-src sin nonce ni hash, porque esa política protege muy poco. Los bloques JSON-LD son datos y no scripts ejecutables, de modo que normalmente no necesitan nonce. Los detalles de sintaxis están en MDN sobre CSP y el marcado en sí, en la guía de JSON-LD.

Las demás cabeceras son más sencillas y cada una cubre su propio hueco.

X-Content-Type-Options

Tiene un único valor: X-Content-Type-Options: nosniff. El navegador deja de adivinar el tipo de un archivo por su contenido y confía en la cabecera Content-Type. Un script o una hoja de estilos con el tipo equivocado se bloquea, así que antes de activarla comprueba que el servidor envía los tipos correctos para .js y .css. Consulta MDN.

Referrer-Policy

Controla cuánta dirección se envía en la cabecera Referer cuando el visitante sigue un enlace a otro sitio. Los navegadores modernos usan por defecto strict-origin-when-cross-origin, que a otros dominios envía solo el origen. Fijarla de forma explícita hace el comportamiento predecible. Una política más estricta puede ocultar parte de los datos de referencia en la analítica. Más en MDN sobre Referrer-Policy.

Permissions-Policy

Desactiva funciones del navegador que el sitio no usa, por ejemplo Permissions-Policy: camera=(), microphone=(), geolocation=(). Consulta MDN.

Protección contra marcos

Para que otro sitio no muestre tu página en un marco oculto, usa la directiva frame-ancestors de CSP. El antiguo X-Frame-Options: SAMEORIGIN sigue siendo compatible y sirve como capa adicional.

Hay una cabecera HTTP que afecta directamente a las búsquedas: X-Robots-Tag. Funciona como la metaetiqueta robots, pero viaja en HTTP, por lo que sirve para archivos que no son HTML, como los PDF. Ejemplo:

X-Robots-Tag: noindex, nofollow

Por qué merece estar en una charla de seguridad: la configuración del servidor o de la CDN a veces añade esta cabecera a una zona entera, por ejemplo en un dominio de pruebas, y luego se cuela en producción. La página parece normal, el HTML no contiene ningún noindex y, sin embargo, desaparece del índice. Google la describe en su documentación sobre la metaetiqueta robots y X-Robots-Tag.

El escáner une las directivas de meta robots, googlebot, bingbot y X-Robots-Tag: gana la más restrictiva y una discrepancia entre la cabecera y la metaetiqueta se señala en el informe. Si controlas el rastreo con un archivo y no con una cabecera, consulta la guía de robots.txt.

Las cabeceras se definen en el servidor web, en una CDN o en el código de la aplicación. Un ejemplo de nginx para un bloque server con HTTPS:

add_header Strict-Transport-Security "max-age=300" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always;
add_header Content-Security-Policy-Report-Only "default-src 'self'" always;

El parámetro always hace que nginx añada la cabecera también a las respuestas de error, no solo a las correctas. Si usas add_header dentro de un bloque location anidado, las cabeceras del nivel superior no se heredan allí, así que repítelas.

Tras el cambio, la respuesta del servidor debería verse más o menos así:

HTTP/2 200
content-type: text/html; charset=utf-8
strict-transport-security: max-age=300
x-content-type-options: nosniff
referrer-policy: strict-origin-when-cross-origin
permissions-policy: camera=(), microphone=(), geolocation=()
content-security-policy-report-only: default-src 'self'

En una CDN las cabeceras suelen añadirse con reglas de transformación de respuestas, y en aplicaciones Node o PHP, mediante una capa intermedia. Elijas lo que elijas, verifica el resultado en la dirección real y no solo en la configuración.

El método más simple es la línea de comandos:

curl -sI https://example.com

La opción -I solicita solo las cabeceras. También las ves en la pestaña Network de las herramientas de desarrollo del navegador. Revisa algo más que la página de inicio: prueba plantillas típicas y páginas de error.

Resumen de las cabeceras:

El escáner de SEOAudit lee estas cabeceras en una respuesta normal. Valora como importantes la ausencia de HSTS, CSP y protección contra marcos, y como informativa la de nosniff. También informa de la falta de HTTPS, de la falta de redirección de HTTP a HTTPS, del contenido mixto, de los problemas del certificado, de los atributos de las cookies y de las cabeceras que revelan versiones del servidor. En HSTS la comprobación se aplica solo a respuestas HTTPS en nombres de host, no en direcciones IP, y frame-ancestors se lee únicamente de la cabecera.

Un punto importante: el escáner es pasivo. Solo lee cabeceras y nunca prueba exploits, así que no puede demostrar que un sitio sea seguro. Es una lista de observaciones, no un certificado. Para la parte SEO del mismo análisis mira la página de auditoría SEO y, para la preparación a la búsqueda con IA, la de visibilidad en IA.