En octubre de 2026 Chrome va a empezar a pedirle permiso al visitante antes de abrir un sitio que sólo existe en HTTP. No es una multa ni una baja de posiciones: es una pantalla entre tu visitante y tu página.
La fecha no es una estimación. Google la publicó con número de versión, y conviene revisar el sitio antes que después.
Qué cambia exactamente, y cuándo
La función se llama «Always Use Secure Connections» y ya existe en Chrome desde hace tiempo, apagada. El calendario publicado por el equipo de seguridad de Google es este:
- Chrome 147, abril de 2026: quedó activa para los usuarios de Navegación Segura Mejorada, más de mil millones de personas.
- Chrome 154, octubre de 2026: queda activa por omisión para todos.
Cuando está activa, Chrome intenta primero la versión cifrada de la dirección. Si el sitio responde bien por HTTPS, el visitante no ve nada raro y la conexión simplemente sube sola. Si el sitio sólo existe en HTTP, ahí aparece el aviso y el visitante tiene que decidir si entra.
Google explica que entre el 95% y el 99% de las navegaciones en Chrome ya son HTTPS. El aviso apunta a ese resto.
El detalle que casi nadie está contando
Chrome no repite el aviso en los sitios que la persona visita con frecuencia. En las pruebas de Google, el usuario mediano ve menos de un aviso por semana.
Eso suena tranquilizador y es exactamente al revés para un negocio. Tus clientes de siempre casi no lo van a ver, porque entran seguido. El que sí lo va a ver es el visitante nuevo, el que llegó por una búsqueda o por un enlace que le compartieron. Es decir: el aviso cae justo sobre la persona que todavía no te conoce y que estaba por decidir si te compra.
También hay exclusiones razonables. Quedan fuera las direcciones IP locales del tipo 192.168.0.1, los nombres de una sola etiqueta y las intranets, donde conseguir un certificado sigue siendo complicado. Si administras algo interno, esto no te afecta.
«Yo ya tengo SSL» no es lo mismo que «no me queda nada en HTTP»
Acá está el punto. Casi todos los sitios chilenos tienen certificado. Igual hay tres situaciones muy comunes en las que algo sigue respondiendo sin cifrado.
| Situación | Qué pasa en Chrome 154 | Cómo se arregla |
|---|---|---|
| El dominio principal redirige, pero un subdominio quedó sin certificado | El aviso aparece al entrar a ese subdominio | Emitir o renovar el certificado para cada subdominio en uso |
| La redirección quedó a medias: la versión sin cifrado responde con la página en vez de redirigir | Quien llegue por un enlace viejo ve el aviso | Forzar la redirección a HTTPS en todo el sitio, incluido www |
Enlaces y recursos escritos a mano como http:// en la base de datos | El navegador bloquea parte del contenido y el candado se cae | Reemplazar esas direcciones, con respaldo previo de la base de datos |
Cómo revisar tu sitio en dos minutos
La comprobación no necesita herramientas de pago. Desde un terminal:
curl -sI http://tusitio.cl/
Lo que tiene que aparecer es un 301 —o un 308— y una línea Location: que apunte a https://. Si en cambio te devuelve un 200, tu sitio está sirviendo contenido sin cifrar y ahí es donde va a caer el aviso.
Repite la misma línea con www.tusitio.cl y con cada subdominio que uses de verdad: el de la tienda, el de reservas, el del sistema interno. Es habitual que el principal esté impecable y un subdominio olvidado sea el que falla.
El segundo control es la cabecera de la versión cifrada:
curl -sI https://tusitio.cl/ | grep -i strict-transport
Si aparece strict-transport-security, el navegador ni siquiera va a intentar la conexión sin cifrar la próxima vez. Es el remate, no el requisito.
Y una advertencia honesta sobre esa cabecera: es difícil de deshacer. El plazo que declares queda guardado en el navegador de cada visitante, así que si más adelante necesitas servir algo sin cifrado, vas a tener que esperar a que ese plazo expire en cada equipo. Se activa cuando el sitio ya funciona completo por HTTPS, nunca antes.
Por qué esto no es lo que te contaron sobre HTTPS y Google
Durante años el argumento para pasar a HTTPS fue el posicionamiento: que Google premia los sitios cifrados. Eso sigue siendo cierto y lo explicamos en qué es SSL y por qué Google penaliza los sitios sin HTTPS, pero es un efecto indirecto y difuso.
Lo que viene en octubre es otra cosa y se mide distinto: no es una posición en una lista, es una pantalla que el visitante tiene que pasar. Un sitio puede estar primero en Google y perder la visita en ese paso.
Y si te están cobrando un adicional por el certificado, conviene leer qué compras de verdad cuando pagas un certificado: el de validación de dominio es gratuito, se renueva solo, y desde marzo de 2026 ningún certificado dura más de 200 días.
El orden en que conviene hacerlo
- Uno. Inventario: lista todos los nombres que apuntan a tu sitio, incluido
wwwy los subdominios. - Dos. Certificado para todos ellos. Si tu panel emite certificados automáticamente, revisa que los haya emitido para cada nombre, no sólo para el principal.
- Tres. Redirección forzada a HTTPS en todo el sitio.
- Cuatro. Arreglar los enlaces internos y los recursos que sigan escritos con
http://, con respaldo antes de tocar la base de datos. - Cinco. Recién ahí, la cabecera de transporte seguro.
Si en el camino te aparecen códigos de error que no habías visto, en qué significa cada código de error está de quién es cada uno. Y si estás cambiando dónde apunta tu dominio, los tiempos reales están en cuánto tarda de verdad un cambio de DNS.
Qué pasa si no haces nada
Si tu sitio ya responde bien por HTTPS —y la mayoría lo hace— no pasa nada: Chrome sube la conexión solo y el visitante no ve ningún aviso. Este artículo es para el caso contrario y para los tres descuidos de la tabla, que son más frecuentes de lo que parece.
Si quieres asegurarte antes de octubre, revisamos tu dominio, tus subdominios y tus redirecciones y te decimos exactamente qué queda sirviéndose sin cifrar. Escríbenos desde altahosting.cl con tu dominio y te mandamos el detalle.
