La guía de HTTPS y seguridad de esta misma sección explica por qué el cifrado dejó de ser opcional para el SEO. Esta va un nivel más abajo: da por hecho que ya tienes un certificado instalado y entra en la configuración concreta que determina si ese HTTPS funciona de verdad en todos los navegadores, o solo en el tuyo. La diferencia entre "funciona en mi Chrome" y "funciona en todos los clientes que visitan mi web" está casi siempre en la cadena de certificados, la versión de TLS negociada y la cabecera HSTS, tres piezas que rara vez se revisan después de la instalación inicial.
La cadena de certificados: por qué algo puede fallar sin que tú lo veas
Un certificado SSL/TLS nunca se valida solo: el navegador construye una cadena de confianza que va desde el certificado de tu dominio (el certificado hoja) hasta una entidad raíz (root CA) que ya está integrada de fábrica en el sistema operativo o el navegador, pasando por uno o varios certificados intermedios emitidos por la autoridad certificadora. El servidor tiene que enviar esa cadena completa, no solo el certificado hoja, porque el navegador del usuario no tiene por qué conocer de antemano qué intermedio corresponde a qué raíz.
Aquí está el motivo técnico por el que una configuración "funciona en un navegador y falla en otro": los navegadores de escritorio modernos (Chrome, Firefox) suelen cachear certificados intermedios comunes que ya vieron en otras webs, así que si tu servidor no envía el intermedio, el navegador a veces lo reconstruye igualmente a partir de esa caché y la web se ve perfectamente segura. Un cliente que no tiene esa caché (un navegador móvil menos usado, una librería HTTP en un script de monitorización, un rastreador SEO, o el propio Googlebot en determinadas condiciones) no puede completar la cadena y trata la conexión como no fiable. El fallo, por tanto, puede llevar meses invisible para el equipo que solo prueba en su propio Chrome de escritorio.
# Comprobar la cadena completa que envía realmente el servidor
# (no lo que crees que envía, sino lo que sale por el cable)
openssl s_client -connect www.tudominio.com:443 -servername www.tudominio.com -showcerts
# Verificar además que la cadena resuelve sin depender de la caché local
openssl s_client -connect www.tudominio.com:443 -servername www.tudominio.com -verify_return_errorEl error de configuración más habitual, con diferencia, es instalar solo el certificado hoja y olvidar el archivo de la cadena intermedia (a menudo un archivo separado, tipo chain.pem o fullchain.pem, según lo entregue la autoridad certificadora) en la configuración del servidor web. Con Let's Encrypt, por ejemplo, la diferencia entre usar cert.pem (solo el certificado hoja) y fullchain.pem (hoja más intermedio) en la directiva SSLCertificateFile de Apache o ssl_certificate de Nginx es exactamente este problema, y es fácil equivocarse porque ambos archivos "funcionan" en las pruebas superficiales.
Versiones de TLS: por qué TLS 1.0 y 1.1 ya no deberían estar activas
TLS (Transport Layer Security) tiene varias versiones con distinto nivel de seguridad: TLS 1.0 (1999) y TLS 1.1 (2006) usan primitivas criptográficas hoy consideradas débiles y son vulnerables a ataques documentados como BEAST y POODLE; TLS 1.2 (2008) sigue siendo ampliamente compatible y seguro si se configuran bien sus cifrados; TLS 1.3 (2018) simplifica el protocolo, reduce la latencia del handshake inicial (una ida y vuelta menos) y elimina de raíz varias familias de cifrados inseguros que en TLS 1.2 seguían siendo, al menos en teoría, configurables por error.
Los navegadores principales desactivaron el soporte de TLS 1.0 y 1.1 de forma coordinada, y los estándares de la industria de pagos (PCI DSS) exigen desde hace años que no se usen en ningún entorno que procese tarjetas. Mantenerlos activos en el servidor no aporta ningún beneficio real (casi ningún cliente moderno los necesita) y sí amplía la superficie de ataque; el único caso legítimo para conservarlos es dar soporte a un cliente muy específico y conocido que no pueda actualizarse, nunca como configuración por defecto.
# Apache: desactivar TLS 1.0 y 1.1, dejar solo 1.2 y 1.3
SSLProtocol -all +TLSv1.2 +TLSv1.3
# Nginx: equivalente
ssl_protocols TLSv1.2 TLSv1.3;El impacto en SEO de este apartado no es una señal directa de ranking (Google no consulta la versión de TLS negociada como factor de posicionamiento), sino indirecto y con dos caras: por un lado, un servidor mal configurado en TLS que empieza a fallar handshakes con determinados clientes puede generar errores de rastreo intermitentes difíciles de diagnosticar porque no fallan siempre ni con todos los user-agents; por otro, herramientas de auditoría de seguridad y algunos navegadores muestran avisos explícitos de "conexión no del todo segura" en configuraciones obsoletas, lo que erosiona la confianza del usuario igual que lo haría un candado roto por contenido mixto.
HSTS en profundidad: max-age, preload, y por qué hay que probarlo antes de comprometerse
La guía de HTTPS ya presenta la cabecera Strict-Transport-Security básica. El matiz que falta ahí es la directiva preload y sus consecuencias, porque es la parte de HSTS que genera más errores irreversibles en producción:
Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"Sin preload, HSTS solo protege a un usuario a partir de su segunda visita: la primera petición todavía puede viajar por http:// antes de que el navegador reciba la cabecera y memorice la política. La lista de precarga HSTS (HSTS preload list), mantenida por Chromium y adoptada también por Firefox y Safari, resuelve ese hueco incluyendo el dominio directamente en el propio navegador, de forma que ni siquiera la primera visita se hace nunca por HTTP sin cifrar, para ningún usuario del mundo que use ese navegador.
El problema es que la inclusión en esa lista es, en la práctica, casi irreversible a corto plazo: una vez aceptado el dominio (tras comprobar que cumple los requisitos y ha mantenido HSTS activo un tiempo razonable), sacarlo de la lista puede tardar meses en propagarse a todos los navegadores ya actualizados, y mientras tanto todo el dominio y todos sus subdominios (por includeSubDomains) quedan forzados a HTTPS sin excepción, incluidos subdominios de prueba, entornos de staging con nombres reales, o cualquier servicio interno que por lo que sea todavía no tenga certificado propio. Antes de enviar un dominio a la lista de precarga (en hstspreload.org) conviene mantener la cabecera activa sin preload durante semanas, confirmando que ningún subdominio depende de servirse por HTTP, y solo entonces dar el paso.
Contenido mixto a escala: auditar todo el sitio, no una página suelta
Revisar la consola del navegador página a página, como sugiere la guía general de HTTPS, funciona para una comprobación puntual pero no escala a un sitio de miles de URLs. Dos enfoques técnicos permiten detectar contenido mixto a nivel de sitio completo. El primero es un rastreo masivo (con una herramienta tipo Screaming Frog, como se describe en la guía de metodología de auditoría) que extraiga todos los atributos src y href de cada página rastreada y filtre los que empiecen por http:// estando la página servida por https://. El segundo, más preciso porque captura también recursos cargados dinámicamente por JavaScript que un rastreo estático puede no ver, es activar temporalmente una Content-Security-Policy en modo solo-reporte, que no bloquea nada pero envía un informe a una URL propia cada vez que un navegador real detecta una carga insegura:
Content-Security-Policy-Report-Only: default-src https: 'unsafe-inline' 'unsafe-eval'; report-uri /csp-report-endpointEste segundo método tiene la ventaja de reflejar el contenido mixto que realmente encuentran los usuarios reales en producción (incluyendo casos que dependen de datos dinámicos, de un plugin concreto, o de una condición de carrera en el JavaScript) en vez de solo lo que un rastreo puede reconstruir de forma estática.
Qué ocurre técnicamente cuando un certificado caduca
La guía general de HTTPS describe el síntoma visible (una interstitial de advertencia a pantalla completa). A nivel de protocolo, lo que ocurre es que, durante el handshake TLS, el servidor sigue presentando el certificado tal cual, pero el cliente comprueba el campo notAfter del certificado y, al encontrarlo en el pasado, aborta la conexión antes de que se complete el intercambio de claves: no es un fallo del servidor en el sentido de que deje de responder, es un rechazo activo y deliberado por parte del cliente, lo que explica por qué el sitio parece "caído" incluso aunque el servidor esté funcionando con normalidad y sirviendo el resto de su infraestructura sin problema. Para Googlebot, el efecto es equivalente: no puede completar la conexión cifrada, así que la URL empieza a registrarse como error de rastreo, y si la situación se prolonga, Google puede llegar a retirar las páginas afectadas del índice por no poder verificar que siguen existiendo y siendo accesibles.
Preguntas frecuentes
¿Por qué mi certificado se ve correcto en Chrome pero falla en otras herramientas?
Casi siempre es un problema de cadena de certificados incompleta: el servidor no envía el certificado intermedio y Chrome lo reconstruye desde su propia caché, mientras que herramientas sin esa caché (curl, algunos rastreadores SEO, ciertos navegadores móviles) no pueden completar la validación y dan la conexión por no fiable.
¿Puedo desactivar TLS 1.0 y 1.1 sin comprobar nada antes?
En la inmensa mayoría de sitios sí, sin impacto perceptible, porque el tráfico real que todavía depende de esas versiones es ínfimo hoy. Si el sitio recibe tráfico de integraciones muy antiguas y conocidas (un sistema de pago heredado, por ejemplo), conviene revisar los logs de servidor por versión de TLS negociada antes de desactivarlas por completo.
¿Es seguro añadir mi dominio a la lista de precarga HSTS?
Solo después de haber mantenido la cabecera HSTS activa (sin preload) el tiempo suficiente para confirmar que ningún subdominio ni servicio interno depende todavía de HTTP sin cifrar, porque una vez incluido en la lista, revertirlo tarda meses en propagarse a los navegadores que ya la tienen descargada.
¿El modo solo-reporte de Content-Security-Policy afecta a los usuarios reales?
No: Content-Security-Policy-Report-Only nunca bloquea ningún recurso, solo registra lo que habría bloqueado una política real. Es la forma segura de auditar contenido mixto en producción antes de activar una política restrictiva de verdad.