«Las cabeceras de seguridad mejoran el posicionamiento», «HSTS te hace ganar puestos»: estas afirmaciones circulan mucho, y rara vez con una fuente. Sin embargo, Google documenta con bastante precisión lo que tiene en cuenta. Este artículo separa las señales oficiales (HTTPS, Core Web Vitals) de los efectos indirectos (URL canónica, advertencias del navegador) y de lo que no tiene ningún efecto documentado en el posicionamiento, y después enumera los errores de configuración que sí cuestan tráfico de verdad.
HTTPS: una señal oficial, pero ligera
El 7 de agosto de 2014, Google anunció que usaba HTTPS como señal de posicionamiento. La entrada la calificaba de señal «muy ligera», que afectaba a menos del 1 % de las consultas a nivel mundial y pesaba menos que señales como la calidad del contenido, aunque dejaba la puerta abierta a reforzarla en el futuro. Desde diciembre de 2015, Google indexa por defecto la versión HTTPS de una página cuando existe.
Hoy, HTTPS aparece en la documentación sobre la experiencia en la página (actualizada el 22 de septiembre de 2026), como pregunta de autoevaluación: ¿se sirven tus páginas de forma segura? La misma página precisa que no existe una señal única de «experiencia en la página»: los sistemas de posicionamiento tienen en cuenta varias señales, y Google añade que obtener buenas puntuaciones en los informes no garantiza un buen posicionamiento. Pasar a HTTPS sigue siendo imprescindible, pero por la seguridad y la confianza de los visitantes mucho más que por una ganancia de posiciones medible.
El efecto indirecto más concreto: la URL canónica
Cuando una página existe en HTTP y en HTTPS, Google tiene que elegir cuál mostrar. Su documentación sobre la canonicalización (actualizada el 10 de julio de 2026) indica que prefiere la versión HTTPS, salvo que haya un problema: certificado no válido, recursos no seguros que no sean imágenes, página HTTPS que redirige a HTTP o etiqueta rel="canonical" que apunta a HTTP. Las redirecciones de HTTP a HTTPS, una etiqueta canonical a HTTPS y HSTS refuerzan esa preferencia.
Dicho de otro modo, una migración a HTTPS mal terminada produce duplicados y señales contradictorias. En un sitio WordPress, comprueba que la dirección del sitio en Ajustes, Generales empieza por https://, que los enlaces internos y los medios antiguos se han actualizado en la base de datos y que tu plugin de SEO no genera una canonical en HTTP.
HSTS: seguridad, y un viaje de ida y vuelta menos
La cabecera Strict-Transport-Security indica al navegador que solo acceda al sitio por HTTPS: cualquier intento por HTTP se convierte antes incluso de enviarse. La guía de web.dev sobre la activación de HTTPS destaca dos ventajas: frustra los ataques de tipo «SSL stripping» y evita el coste del viaje de ida y vuelta de la redirección 301. Este segundo punto mejora ligeramente el tiempo de carga para los visitantes que vuelven.
- Ignorada en HTTP: el navegador solo tiene en cuenta la cabecera si la recibe por HTTPS.
- Debilidad del primer acceso: mientras el navegador no haya recibido nunca la cabecera, la primerísima petición por HTTP sigue expuesta. La lista de precarga corrige este punto.
- Precarga exigente: hstspreload.org pide un
max-agede al menos 31 536 000 segundos (un año),includeSubDomains,preloady una redirección de HTTP a HTTPS en el mismo host. - Difícil de deshacer: el sitio advierte de que una inscripción no se cancela fácilmente y de que una baja tarda meses en llegar a los usuarios a través de las actualizaciones de Chrome.
- Subida progresiva: web.dev aconseja empezar con un
max-agebajo y aumentarlo cuando el funcionamiento en HTTPS sea fiable, porque un navegador que conoce el sitio con HSTS rechazará cualquier error de certificado.
La puesta en marcha paso a paso, certificado incluido, se detalla en nuestro artículo sobre HTTPS, los certificados y HSTS.
Chrome y HTTPS por defecto
El 28 de octubre de 2025, Google anunció que Chrome 154, previsto para octubre de 2026, activaría por defecto la opción «Usar siempre conexiones seguras» para los sitios públicos: Chrome pedirá entonces permiso al usuario antes de abrir un sitio público que no ofrezca HTTPS. Se anunciaba una primera etapa en Chrome 147, en abril de 2026, para los más de mil millones de usuarios de la protección mejorada de Safe Browsing. Google precisaba que la advertencia solo aparece al visitar un sitio nuevo o que no se ha visitado recientemente.
Para un sitio que todavía está en parte en HTTP (un subdominio olvidado, una antigua página de pago, un enlace en un correo), es una pantalla de advertencia más entre tus visitantes y tu contenido. El efecto en el tráfico no pasa por el posicionamiento, sino por los visitantes que se echan atrás.
Las demás cabeceras de seguridad: ningún efecto documentado en el posicionamiento
Content-Security-Policy, X-Frame-Options, Referrer-Policy, Permissions-Policy y X-Content-Type-Options no figuran en ninguna documentación de Google como señal de posicionamiento. Limitan la inyección de scripts, el secuestro de clics, las fugas de direcciones y la interpretación abusiva de los archivos. Su interés es la protección de los visitantes, que se detalla en nuestra guía de las cabeceras de seguridad HTTP. De forma indirecta, un sitio que resiste mejor las inyecciones corre menos riesgo de spam SEO o de una advertencia de Safe Browsing, que sí hacen perder tráfico.
Core Web Vitals: donde se cruzan seguridad y rendimiento
Google indica que sus sistemas de posicionamiento utilizan las Core Web Vitals. Miden tres aspectos de la experiencia real, en el percentil 75 de las cargas de página, por separado en móvil y en ordenador. INP sustituyó a FID como métrica de capacidad de respuesta el 12 de marzo de 2024.
Las medidas de seguridad pueden influir en estas métricas en los dos sentidos. Una cadena de redirecciones de http:// a https:// y después a www retrasa la visualización; la guía de migración de Google recomienda redirigir directamente al destino final. Un script de protección pesado cargado en todas las páginas públicas puede empeorar el INP. Un desafío antibots mostrado a pantalla completa a los visitantes legítimos se parece a un intersticial intrusivo, que la documentación sobre la experiencia en la página invita a evitar. En cambio, HSTS ahorra un viaje de ida y vuelta, y una caché de páginas bien configurada absorbe tanto a los robots como a los visitantes.
Los errores que de verdad cuestan tráfico
| Error | Consecuencia | Corrección |
|---|---|---|
| Certificado caducado o no válido | Página de error en el navegador; Google puede dejar de preferir la versión HTTPS | Renovación automática y vigilancia de la caducidad |
| Contenido mixto | Scripts HTTP bloqueados por la mayoría de los navegadores; imágenes actualizadas a HTTPS o sin cargar | Sustituir las direcciones HTTP en la base de datos, el tema y los widgets |
| Canonical o sitemap en HTTP | Señales contradictorias, duplicados | Comprobar la dirección del sitio y el plugin de SEO |
| Cadena de redirecciones | Latencia, rastreo más lento | Una sola redirección a la URL final |
X-Robots-Tag: noindex añadido por error | Páginas retiradas del índice | Comprobar las cabeceras con la inspección de URLs |
| CSP demasiado estricta | Analítica, consentimiento o formularios rotos | Empezar en modo Content-Security-Policy-Report-Only |
HSTS includeSubDomains con un subdominio sin HTTPS | Subdominio inaccesible para los visitantes que ya han pasado por el sitio | Pasar todos los subdominios a HTTPS antes de activar la opción |
El caso de X-Robots-Tag merece destacarse: esta cabecera acepta todas las reglas de la etiqueta meta robots, incluida noindex. Basta con copiar un bloque de configuración de un entorno de preproducción a producción para desindexar un sitio entero sin que cambie nada en pantalla.
Configurar las cabeceras con WP Masquerade
La versión gratuita añade la cabecera X-Content-Type-Options: nosniff desde el primer nivel de bastionado. La versión Pro gestiona las cabeceras de seguridad (HSTS, X-Frame-Options, Referrer-Policy, CSP...) desde la administración, sin modificar los archivos del servidor. Hay dos precauciones válidas sea cual sea la herramienta: una cabecera añadida por WordPress puede faltar en una respuesta servida por una caché intermedia, y HSTS solo debe activarse cuando todo el sitio, subdominios incluidos, se sirva por HTTPS. La comparativa de versiones detalla el reparto entre la versión gratuita y la Pro.
Las demás palancas de posicionamiento de un sitio WordPress están reunidas en nuestra guía para optimizar el SEO de WordPress.
Lo esencial
- HTTPS es una señal oficial pero muy ligera desde 2014; su peso real está en la confianza y en la URL canónica.
- Los sistemas de posicionamiento utilizan las Core Web Vitals, sin garantía de posición.
- CSP, X-Frame-Options y Referrer-Policy no tienen ningún efecto documentado en el posicionamiento: protegen a los visitantes.
- Chrome 154 debe avisar antes de abrir sitios públicos en HTTP.
- Los errores (certificado, contenido mixto, noindex en una cabecera) cuestan mucho más que la falta de una cabecera.
Fuentes
- Google Search Central Blog, HTTPS as a ranking signal (7 de agosto de 2014) (se abre en una pestaña nueva)
- Google Search Central Blog, Indexing HTTPS pages by default (diciembre de 2015) (se abre en una pestaña nueva)
- web.dev, Web Vitals (se abre en una pestaña nueva)
- web.dev, Largest Contentful Paint (se abre en una pestaña nueva)
Otras fuentes consultadas: documentación oficial y páginas oficiales de los editores.
