Chrome 154 ya pregunta antes de abrir tu sitio HTTP: la auditoría de 30 minutos, aplicada al nuestro

Chrome 154 ya está en el canal estable desde el 22 de septiembre de 2026 y activa «Usar siempre conexiones seguras» (Always Use Secure Connections) por defecto para sitios públicos: cuando alguien haga clic en un enlace http:// o escriba esa dirección, y el sitio no responda por HTTPS, el navegador mostrará un permiso antes de continuar por HTTP. La parte que casi nadie explica: el aviso no es un castigo para todos los enlaces viejos. Chrome intenta HTTPS primero, así que la mayoría de los enlaces en texto plano se actualizan en silencio y nadie ve nada. El prompt aparece solo donde el HTTPS falle: dominios olvidados, certificados vencidos, subdominios que nadie revisa. Eso convierte el asunto en un problema de higiene de enlaces, no en un proyecto de seguridad.

La fecha que te prometieron ya no es la fecha real

Google lo anunció en octubre de 2025 con una frase muy concreta: «con el lanzamiento de Chrome 154 en octubre de 2026, cambiaremos la configuración predeterminada». Luego, en marzo de 2026, Chrome pasó a un ciclo de release cada dos semanas en lugar de cada cuatro, y los hitos se movieron sin que nadie actualizara el blog. El resultado es el que comprobamos hoy: el hito que Google nombró ya está estable desde el 22 de septiembre, fecha que confirmamos con el anuncio del canal estable de Chrome y que además habíamos publicado nosotros mismos el 26 de agosto en el calendario del ciclo de dos semanas. La compilación corriente es la 154.0.8037.98, con fecha de build del 2 de octubre según Chromium Dash.

La guía de adopción de Chromium, leída el 5 de octubre, sigue diciendo sin ambigüedad: «Chrome empezará a pedir permiso al usuario antes de navegar a páginas HTTP por defecto en Chrome 154». Es decir, la fecha de calendario y el nombre del hito ya no coinciden, y la lección práctica es simple: no esperes a que «llegue octubre» para revisar tu sitio. Si quieres certeza sobre tu compilación exacta, activa la opción y pruébala, que es justo lo que Google recomienda en esa misma guía.

Además, este mismo hito trae otros cambios de interfaz que ya cubrimos en nuestro análisis de Chrome 154: lo nuevo aquí es el aviso de navegación, no las funciones de CSS.

Qué dispara el aviso y qué no

La distinción importa porque decide en dos minutos si tienes trabajo pendiente o no. Según la guía de adopción de Chromium, el aviso aparece cuando Chrome no pudo conectarse por HTTPS pero cree que el HTTP podría funcionar:

Un detalle operativo que se pasa por alto: Chrome recuerda la decisión del usuario durante 15 días y la renueva cada vez que la persona vuelve al sitio. No estás pagando un intersticial en cada visita, sino uno por dominio cada dos semanas. El coste real no es el rebote: es que el aviso caiga justo en el primer contacto — el clic de un QR, el enlace de una newsletter de 2019, el PDF de un catálogo que sigue en circulación.

La auditoría que corrimos sobre mintec.co

Nosotros vendemos arquitectura web y decisiones de mantenimiento, así que el primer cliente de esta auditoría tenía que ser nuestro propio sitio. Cinco chequeos, ejecutados el 5 de octubre de 2026:

1. Cabeceras de la raíz. https://mintec.co/ responde HTTP/2 200. No envía cabecera Strict-Transport-Security. Nada de HSTS, ningún fallback forzado.
2. Certificado. Vigencia del 19 de septiembre al 19 de diciembre de 2026: rotación automática de 91 días, sin intervención manual.
3. Censo de referencias en texto plano. Sobre src/content/ contamos 13 hostnames distintos referenciados como http://, en 81 apariciones. La distribución:

4. Alcance real. De los 13 hostnames, 11 responden por HTTPS hoy — actualización silenciosa, cero avisos. Los dos que no responden son exactamente los que requieren una prueba manual con la opción activada.
5. Dominio propio y subdominio www. Ambos responden 200 sobre HTTPS; el problema de cabecera es el mismo: sin HSTS.

La conclusión de nuestro censo: el grueso de nuestro archivo ya está cubierto por la actualización silenciosa, y el riesgo se concentra en un solo host heredado con 45 referencias. Ese es el patrón que vemos en casi todos los proyectos: el homepage está perfecto y el peligro vive en el archivo viejo.

Lo que estamos cambiando

• Normalizar las 81 referencias en texto plano. Las 45 apuntan a un dominio heredado que hay que decidir si sigue bajo control: si responde por HTTPS, se actualiza el enlace; si ya no es nuestro, se desenlaza. Dejarlas como están es aceptar que una parte del archivo dependa de decisiones que tomó alguien en otra época.
• Encender HSTS por rampa. Primero un max-age corto (1 día), luego 30, luego un año con includeSubDomains, y solo al final considerar preload. El orden importa: HSTS elimina el fallback HTTP, así que un certificado vencido deja de ser un redireccionamiento y pasa a ser un error duro. No se enciende antes de comprobar que la renovación automática cubre todos los subdominios. Detalle del sitio que nos obliga a hacerlo en ese orden: acabamos de ver que la raíz no envía la cabecera.
• Inventario de certificados con dueño. El certificado de la raíz está bien; la pregunta es por los subdominios que solo existen en la memoria de alguien. Un certificado vencido no dispara el aviso nuevo, dispara el de siempre — pero para el usuario es la misma conversión perdida.
• Chequeo mensual fijo. Dos comandos en la rutina de mantenimiento: cabecera HSTS presente y días restantes de certificado. Si quieres profundizar en cómo decidimos esto junto a nuestra migración de alojamiento, está explicado en Cloudflare Pages a Workers con Astro.

La auditoría de 30 minutos

1. Activa el comportamiento nuevo en chrome://settings/security → «Usar siempre conexiones seguras» → «Avisar antes de sitios públicos inseguros». Así pruebas el futuro por ti mismo y no dependes de la fecha del blog.
2. Recorre tus veinte puntos de entrada reales: landing de campañas, newsletters archivadas, códigos QR impresos, PDFs, documentación, enlaces de soporte. Ahí aparecen los dominios que el tráfico normal nunca toca.
3. Haz el censo en tu repositorio: grep -rhoE 'http://[a-zA-Z0-9.-]+' src/ | sort | uniq -c. En nuestro caso devolvió 13 hostnames y 81 apariciones; en repositorios con más historia, la cifra sube rápido.
4. Comprueba cada hostname por HTTPS: curl -sI https://tudominio/. Si responde, actualización silenciosa y listo. Si no responde, es tu pendiente.
5. Mira tu cabecera: curl -sI https://tudominio/ | grep -i strict-transport. Si no aparece, aún no has cerrado el fallback.
6. Confirma el salto http → https en el borde y que la renovación de certificados cubre cada subdominio con tráfico propio.

El aviso de Chrome 154 no cambia cómo se construye la web: cambia lo que cuesta tener escombros sin levantar. Tu homepage ya está listo; el trabajo está en los enlaces que nadie ha mirado en años, y una auditoría de media hora los pone a la vista antes de que lo haga un usuario con el permiso en pantalla.

Si prefieres que alguien ejecute esta revisión sobre tu sitio antes de tocar nada, lo hacemos en diseño y desarrollo web como parte del mantenimiento, no como un proyecto aparte.