Publicar · Infraestructura
Dominio, DNS, hosting y HTTPS
La mayoría de los problemas de un lanzamiento no están en la web: están en cómo se conecta al mundo. Y varios de ellos no tienen vuelta atrás rápida.
Respuesta directa
Hay que verificar cuatro cosas antes de considerar conectado un dominio: qué host es el canónico, que el certificado cubre lo que sirve, que las redirecciones terminan en un solo destino y que no queda contenido mixto.
Y hay una quinta que no es una verificación sino una decisión con consecuencias: HSTS. Conviene entender qué hace antes de activarlo.
Las cuatro verificaciones
| Qué | Cómo se comprueba | Qué falla si no |
|---|---|---|
| Host canónico | Elegir con o sin www y que todo lo demás redirija ahí, en un solo salto. | Contenido duplicado y señales repartidas entre dos hosts. |
| Certificado | Que cubra el host canónico y los subdominios que se sirvan. | Avisos de seguridad en el navegador, que espantan más que cualquier error de diseño. |
| Redirecciones | Que no haya cadenas: http → https → www → final. | Latencia añadida y pérdida de señales en cada salto. |
| Contenido mixto | Que ningún recurso se pida por http desde una página https. | El navegador bloquea recursos y la página se ve rota. |
HSTS: la decisión que no tiene marcha atrás rápida
La cabecera Strict-Transport-Security informa al navegador de que el host solo debe visitarse por HTTPS, y a partir de ese momento el navegador no permite al usuario saltarse errores de conexión segura, como un certificado inválido. Eso es una ventaja de seguridad real y también el motivo para no activarla a la ligera.
Dos detalles de la documentación oficial que conviene conocer antes:
max-agefija los segundos que el navegador recordará esa obligación. Y cada respuesta con la cabecera actualiza la caducidad sumandomax-ageal momento actual, de modo que un valor fijo puede impedir que HSTS expire nunca.includeSubDomainsextiende la política a todos los subdominios del host. Si alguno no sirve HTTPS correctamente, queda inaccesible durante lo que dure elmax-age.
El criterio KATA sobre HSTS
Nuestro criterio operativo es no emitir HSTS hasta haber verificado el dominio y todos sus subdominios, y hacerlo entonces con un max-age corto que se amplía después.
La razón es simple: un subdominio olvidado sin HTTPS correcto queda inalcanzable durante todo el max-age, y el navegador no ofrece al usuario forma de saltárselo. La documentación de MDN, además, no documenta con qué rapidez se retira un dominio de la lista de precarga, así que entrar en ella es una decisión que conviene tomar con los deberes hechos.
Preguntas frecuentes
¿Con o sin www?
Cualquiera de las dos, pero solo una. Lo que rompe cosas no es la elección: es tener las dos activas sirviendo el mismo contenido sin una canónica clara.
¿Debo activar HSTS desde el primer día?
Nuestro criterio es que no. Primero se verifica que el dominio y todos sus subdominios sirven HTTPS correctamente; después se activa con un plazo corto; y solo cuando eso lleva tiempo estable se amplía. Activarlo antes convierte un error de configuración en una caída sin salida rápida.
¿Y la lista de precarga?
Es un servicio que mantiene Google y que, según MDN, usan todos los navegadores, aunque no forma parte de la especificación y no debe tratarse como oficial. Exige un max-age de al menos un año. Es una decisión posterior, nunca del lanzamiento.
Fuentes primarias
Cada afirmacion sensible de esta pagina se apoya en una de estas fuentes, consultada en la fecha indicada. Las listas de bots, capacidades y borradores cambian: se reverifican en cada revision.
| Entidad | Documento | Consultada |
|---|---|---|
| MDN · Mozilla | Strict-Transport-Security (HSTS) | 2026-08-30 |
Los datos de configuración concretos de un hosting no son un hecho externo verificable de forma general: dependen del proveedor. Esta página solo cita como fuente lo que sí es documentación oficial de la tecnología.
Siguiente decisión
Continúa con una pregunta concreta
robots.txt, sitemap y canonical
Una lectura relacionada dentro del mismo método.
robots.txt, sitemap y canonical →
Webs corporativas y transaccionales
Qué podemos abordar contigo y cómo delimitamos el trabajo.
Webs corporativas y transaccionales →
Ilustraciones conceptuales; no son fotografías de clientes.