¿El HTTPS afecta al SEO? La respuesta honesta para 2026

Qué significa de verdad “la seguridad como señal de ranking”

La seguridad no es un único factor de ranking que Google sume o reste a una puntuación. Es un conjunto de cosas. Algunas son directas, como el HTTPS. La mayoría son indirectas: afectan a los Core Web Vitals, al comportamiento de rastreo, a las señales de confianza del usuario y a cómo interpreta Google el sitio en general.

Si has venido buscando una cabecera mágica que mejore tu ranking, no existe. Lo que sí existe es un conjunto de prácticas que evitan que tu web sea penalizada, sospechada o ignorada en silencio. De eso va este post.

HTTPS primero

Google posiciona el HTTPS por encima del HTTP desde 2014. En 2026, una web HTTP es básicamente invisible para consultas serias. Chrome la marca como “No seguro” en la barra de direcciones, los usuarios se van en segundos, y Google interpreta ese rebote como una señal de calidad.

Si tu sitio sigue en HTTP, nada de lo que viene después importa todavía. Consigue un certificado primero. La mayoría de los hostings te dan uno gratis, y si el tuyo no, cambia de hosting.

Algunos casos comunes:

• Tu dominio principal está en HTTPS pero www. no. Ambos tienen que funcionar y redirigir a una versión canónica.
• Tu subdominio del blog está en HTTPS pero assets. o cdn. no. Los subdominios cuentan.
• Tu sitio está en HTTPS pero cargas imágenes desde una fuente HTTP. Eso es contenido mixto, y lo veremos enseguida.

Cabeceras de seguridad y Core Web Vitals

Cabeceras como HSTS, CSP y X-Frame-Options no son factores directos de ranking. Google ha sido claro en esto. Pero afectan indirectamente a los Core Web Vitals, que sí son factores directos, así que el efecto es real.

Una Content-Security-Policy estricta que bloquee scripts de terceros desconocidos puede mejorar LCP y CLS de dos formas. Primero, evitando que scripts lentos de anuncios y analítica bloqueen el render. Segundo, evitando saltos de layout causados por widgets que llegan tarde y empujan tu contenido.

HSTS también ayuda, en menor medida. Al decirle al navegador “usa siempre HTTPS para este dominio”, eliminas la redirección HTTP a HTTPS en visitas repetidas. Es un viaje de ida y vuelta menos en cada carga.

Si ya estás corriendo una arquitectura Zero Trust en el frontend, la mayoría de estas cabeceras ya están en tu configuración por defecto. Bien. Si no, empieza por lo básico y aprieta poco a poco.

Contenido mixto

El contenido mixto ocurre cuando una página HTTPS carga un recurso por HTTP. Una imagen, un script, una hoja de estilos, una fuente. El navegador bloquea scripts y estilos directamente. Las imágenes muestran un aviso. En cualquier caso, el icono del candado desaparece y Chrome muestra “No seguro” de alguna forma.

A Google no le gusta esto. La página sigue funcionando, pero pierde la señal de confianza que el resto de tu configuración HTTPS le da.

Para auditarlo, abre las DevTools, ve a la consola y recarga la página. El contenido mixto aparece como avisos. O usa la pestaña Security de Chrome DevTools, que lista cada recurso y su origen. Arregla el problema actualizando la URL a HTTPS o alojando el recurso tú mismo.

Estado del certificado

Un certificado caducado es peor que no tener certificado. Los navegadores muestran una advertencia a pantalla completa, los usuarios huyen y Google se entera.

La mayoría de los hostings modernos auto-renuevan. Si estás en Vercel, Cloudflare, Netlify o una plataforma similar, los certificados se renuevan sin que hagas nada. Verifícalo una vez y olvídate.

Si gestionas tus propios certificados, usa Let’s Encrypt con Certbot y configura el cron job. Después pon un recordatorio en el calendario para revisar los logs de renovación una vez al trimestre. Un certificado que falla al renovarse porque el cron job ha muerto en silencio es una emergencia de ranking habitual.

Algunas cosas a vigilar:

• El certificado cubre todos tus subdominios, o tienes certificados separados para cada uno.
• El certificado usa un algoritmo de firma actual, no algo obsoleto.
• La cadena del certificado está completa, sin intermedios faltantes. SSL Labs te lo dirá.

Cobertura de subdominios

Cada subdominio necesita su propio certificado y su redirección a HTTPS. Un certificado wildcard cubre todos a la vez, que suele ser la configuración más limpia.

Huecos comunes:

• staging.tusitio.com en HTTP porque a nadie le ha apetecido moverlo. Los buscadores lo encuentran igualmente.
• Un subdominio antiguo como old.tusitio.com sirviendo contenido de un CMS anterior, en HTTP, sin redirección.
• Un subdominio de proveedor como email.tusitio.com apuntando a un servicio de correo, con su certificado caducado o mal configurado.

Esto son lastres para el ranking. Audita tus registros DNS, lista cada subdominio, comprueba cada uno en un navegador, arregla o mata lo que no debería estar.

Checklist práctico de seguridad para SEO

Si quieres una lista funcional para copiar:

• HTTPS en cada página, cada subdominio, cada asset.
• Cabecera HSTS configurada, idealmente con preload cuando confíes en que el sitio es totalmente HTTPS.
• Una CSP básica que al menos defina default-src 'self' y una allowlist explícita de lo que usas de verdad.
• frame-ancestors 'none' (o una allowlist específica) en lugar del antiguo X-Frame-Options.
• Certificados válidos, con auto-renovación, cubriendo todos los subdominios.
• Nada de contenido mixto. Consola de DevTools limpia en cada plantilla.
• Archivo security.txt en /.well-known/security.txt para que los investigadores puedan reportar problemas.

Esto no es una política de seguridad completa. Es una base que evita que tu SEO sufra por motivos técnicos.

E-E-A-T y señales de confianza más allá de las cabeceras

Google mira señales de confianza que no tienen nada que ver con cabeceras HTTP. El marco E-E-A-T (Experiencia, Pericia, Autoridad, Confianza) es el término paraguas. En la práctica significa:

• Información real del autor en los posts, con nombre real, biografía real, e idealmente enlaces a un perfil o a LinkedIn.
• Información de contacto real en el sitio, con dirección física si la tienes, y una forma de contactar con un humano.
• Una política de privacidad que describa de verdad qué haces con los datos del usuario, no un boilerplate genérico copiado de una plantilla.
• Términos de uso que coincidan con cómo funciona el sitio en realidad.
• Una página “Sobre nosotros” que explique quién lleva el sitio y por qué existe.

Esto es lo que le dice a Google que hay un negocio real detrás del sitio. Nada de esto es una cabecera. Nada de esto recibe una nota de un escáner de seguridad. Pero todo cuenta para la confianza, y la confianza es una señal de ranking en sentido amplio.

Una nota sobre las puntuaciones de terceros

Herramientas como Mozilla Observatory, Security Headers y SSL Labs te dan una nota con letra. Son útiles como checklist, no como métrica de ranking.

A lo que voy: una nota B en Security Headers no significa que Google te posicione más bajo. Google no consulta esa nota. Pero las cosas que te dan una B (CSP ausente, sin HSTS, política de referrer débil) pueden afectar a los Core Web Vitals o a las señales de confianza de formas que sí afectan al ranking.

Así que trata la nota como una manera de encontrar lo que falta, no como un número que optimizar. Llega a una nota razonable y sigue. El trabajo de verdad son las cosas que vienen detrás de esa nota: páginas más rápidas, menos fugas a terceros, menos avisos de confianza.

Qué hacer esta semana

Si quieres una versión corta de por dónde empezar:

1. Pasa tu sitio por Security Headers y SSL Labs. Apunta lo que sale en rojo.
2. Abre DevTools en tres o cuatro páginas clave y revisa la consola buscando avisos de contenido mixto.
3. Lista tus subdominios y confirma que cada uno está en HTTPS con un certificado válido.
4. Comprueba que la auto-renovación de tu certificado se está ejecutando de verdad. Mira la fecha de la última renovación.
5. Lee tu política de privacidad. Si es boilerplate genérico, reescribe al menos las partes que describen cómo manejas los datos de verdad.

Con eso arreglas la mayoría de lo que podría estar perjudicándote por motivos de seguridad. Nada de esto es glamuroso. Todo importa.

Preguntas frecuentes

¿Sigue siendo el HTTPS un factor de ranking en 2026?

Sí. Lo es desde 2014, y el listón solo ha subido. Los navegadores tratan una web HTTP como poco fiable, y para consultas competitivas es prácticamente invisible.

¿Añadir una Content-Security-Policy mejora mi ranking?

No directamente. La CSP no es un factor de ranking. Pero una buena CSP puede mejorar LCP y CLS bloqueando scripts de terceros lentos, y esos sí son factores directos. El efecto es real, solo que indirecto.

Mi nota en SSL Labs es B. ¿Está perjudicando mi SEO?

Probablemente no de forma directa. Google no lee las notas de SSL Labs. Pero una B suele significar que falta algo, como HSTS o una suite de cifrado moderna, y esos huecos pueden afectar a los Core Web Vitals o a las señales de confianza. Usa la nota como un checklist, arregla lo señalado y sigue.

¿Y los certificados caducados?

Un certificado caducado rompe los navegadores al instante. Los usuarios ven una advertencia a pantalla completa y se van. Google nota el pico de rebote y la conexión rota en su propio rastreo. Las posiciones caen hasta que el certificado se reemite. Usa auto-renovación para que esto no pase nunca.

¿Le importa a Google mi política de privacidad para el ranking?

Forma parte del E-E-A-T, que es parte de cómo Google evalúa el sitio en general. Una política de privacidad real que coincida con lo que hace el sitio es una señal de confianza. Una copia genérica no es una señal positiva, y en temas sensibles (salud, finanzas) puede perjudicar.