Pocas cosas producen tanta sensación de impotencia como un sitio que no carga cuando el código está bien. No hay error que leer, no hay registro que revisar, no hay nada roto en el repositorio. Simplemente el dominio no lleva a ninguna parte, o el navegador avisa de que la conexión no es privada.
Casi siempre es una de tres cosas, y ninguna vive en el código. Entenderlas de una vez ahorra muchas tardes.
Tres piezas que se confunden todo el tiempo
Dominio, DNS y certificado suelen mencionarse juntos, y eso hace creer que son un mismo servicio. Son tres cosas separadas, con tres proveedores posiblemente distintos y tres formas distintas de fallar.
El dominio es un nombre que alquilas por un tiempo. No es tuyo para siempre: se renueva.
El DNS es la agenda que traduce ese nombre a la dirección de un servidor.
El certificado es lo que permite que la conexión vaya cifrada y que el navegador no muestre una advertencia.
La confusión viene de que muchos proveedores venden las tres juntas, así que parece una sola compra. Cuando algo falla, sin embargo, hay que saber cuál de las tres es, porque se arreglan en sitios diferentes.
Qué ocurre realmente cuando alguien escribe tu dominio
El recorrido completo tiene cuatro pasos y dura milisegundos, pero conocerlo convierte un problema difuso en una pregunta concreta.
Esa separación es la parte útil. Si el dominio resuelve a una dirección pero el sitio no carga, el DNS hizo su trabajo y el problema está en el servidor. Si ni siquiera resuelve, el problema está antes.
Distinguir las dos situaciones lleva un comando y evita horas de buscar en el sitio equivocado:
# ¿A qué dirección apunta el dominio ahora mismo?
dig +short midominio.com
# Si responde una IP, el DNS está bien y el problema es del servidor.
# Si no responde nada, el problema está en la configuración del dominio.Los registros que de verdad vas a usar
Un panel de DNS ofrece una docena de tipos de registro y casi ningún proyecto necesita más de cuatro.
| Registro | Para qué sirve | Cuándo lo tocas |
|---|---|---|
A | Apunta el dominio a una dirección IP | Al poner el sitio en un servidor propio |
CNAME | Apunta un nombre a otro nombre | Con plataformas que dan una dirección propia |
MX | Dice qué servidor recibe el correo | Al configurar correo del dominio |
TXT | Guarda texto: verificaciones y firmas de correo | Al verificar el dominio o configurar el envío |
Hay una regla que evita el error más común con el correo: los registros del dominio principal y los del correo son independientes. Cambiar dónde vive el sitio no debería tocar los MX, y más de una migración ha dejado a alguien sin recibir mensajes por arrastrar toda la configuración de golpe.
Por qué un cambio de DNS no se ve al instante
Este es el punto que más desconcierta. Se cambia un registro, se recarga la página y sigue apareciendo lo anterior. No es un fallo: es el funcionamiento previsto.
Cada registro lleva un tiempo de vida asociado, y durante ese lapso los resolvedores de medio mundo guardan la respuesta en memoria para no preguntar otra vez. Si el valor era de veinticuatro horas, habrá gente viendo la dirección anterior durante casi un día.
Baja el tiempo de vida del registro a cinco minutos al menos un día antes del cambio. Así, cuando llegue el momento, las cachés caducan rápido y la transición se nota en minutos.
Después de que todo esté estable, súbelo otra vez a un valor normal, que reduce consultas y hace el sitio ligeramente más rápido.
Bajarlo el mismo día no sirve de nada, porque el valor antiguo ya está guardado con su duración original. Es la clase de detalle que solo se aprende pasando por ello una vez.
Certificados: lo que cambió y lo que no
Durante años, poner un certificado en un sitio era un trámite pago y manual. Hoy es gratuito y automático en prácticamente cualquier plataforma, y esa es una de las pocas cosas del oficio que se volvió más fácil sin contrapartidas.
Lo que un certificado hace es cifrar la conexión y demostrar que el servidor que responde controla ese dominio. Lo que no hace, y conviene tener claro, es decir nada sobre quién está detrás del sitio ni sobre si es de fiar. El candado del navegador significa que nadie puede leer lo que viaja, no que el sitio sea legítimo.
La automatización tiene una consecuencia práctica: los certificados modernos duran poco y se renuevan solos. Eso es bueno, salvo cuando la renovación falla en silencio y nadie se entera hasta que el navegador muestra la advertencia.
Por eso lo único que hay que hacer es comprobar que la renovación automática funciona, una vez, en lugar de asumirlo.
Los tres fallos que explican casi todos los incidentes
Con estas piezas en la cabeza, los problemas se vuelven reconocibles.
- El dominio caducó. Suena a error de principiante y le pasa a empresas grandes todos los años. La tarjeta guardada expiró, el aviso llegó a un correo que nadie lee, y el dominio dejó de responder. Es el fallo más fácil de evitar y el más vergonzoso.
- El registro apunta a un sitio que ya no existe. Se migró el servidor, se apagó el antiguo y el registro siguió apuntando a la dirección vieja. El síntoma es un sitio que no carga sin ningún error en el servidor nuevo, porque nadie está llegando a él.
- El certificado no renovó. La advertencia del navegador espanta a cualquier visitante, y suele descubrirse porque alguien avisa, no porque el equipo lo detecte.
Los tres comparten una característica: no producen ningún error en el código ni en los registros de la aplicación, porque la aplicación está perfectamente bien. Por eso desconciertan tanto.
Las cuatro medidas que cierran el tema
Ninguna lleva más de unos minutos, y juntas evitan prácticamente todos los casos anteriores.
Pon la renovación del dominio en automático y verifica el correo de contacto. Ese correo no debería ser una dirección del propio dominio: si el dominio cae, el aviso no llega. Es un círculo que se cierra en el peor momento.
Activa el bloqueo de transferencia. Casi todos los registradores lo ofrecen y evita que el dominio se mueva sin autorización. Viene desactivado con más frecuencia de la que debería.
Anota quién controla qué. Dónde está registrado el dominio, quién gestiona el DNS, quién emite el certificado. Son tres cuentas que pueden estar en tres sitios y, cuando hay una urgencia, nadie recuerda en cuál entrar.
Vigila la caducidad del certificado desde fuera. Un aviso que te avise varios días antes convierte un incidente público en una tarea tranquila.
Subdominios: la pieza que evita mudanzas
Un subdominio es un nombre que cuelga del principal, como blog.midominio.com o api.midominio.com. No se compran aparte: se crean en el panel de DNS y no cuestan nada.
Su utilidad práctica es que cada uno puede apuntar a un sitio distinto. El sitio principal en una plataforma, el blog en otra, la documentación en un tercer servicio, y todo bajo el mismo nombre. Eso permite cambiar cualquiera de las piezas sin tocar las demás.
Conviene decidirlos antes de publicar, porque cambiar una dirección que ya circula cuesta caro: enlaces rotos, posicionamiento perdido y la necesidad de mantener redirecciones durante años. Un rato pensando la estructura al principio ahorra ese problema entero.
Hay una decisión relacionada que también se toma pronto y casi nunca se revisa: si el sitio vive con o sin el prefijo www. Cualquiera de las dos opciones está bien, pero hay que elegir una y redirigir la otra hacia ella. Servir el mismo contenido en las dos direcciones sin redirección reparte las visitas entre dos versiones y confunde a los buscadores.
Cuando el dominio es también tu correo
Usar una dirección del propio dominio proyecta seriedad, y trae consigo una responsabilidad que sorprende a quien la configura por primera vez: hay que demostrar que los mensajes salen de donde dicen salir.
Sin esa demostración, buena parte de los correos acaba en la carpeta de no deseados, y el remitente no se entera nunca, porque el envío no falla. Simplemente nadie responde.
Las tres piezas que lo resuelven viven en registros de tipo TXT y las configura el proveedor de correo, normalmente copiando y pegando lo que indica su panel. No hace falta entenderlas a fondo, pero sí saber que existen y que sin ellas el correo del dominio funciona a medias.
La comprobación que cierra el asunto es enviarte un mensaje a una cuenta de otro proveedor y mirar si llega a la bandeja principal o al buzón de no deseados. Es una prueba de un minuto que dice más que cualquier configuración revisada en pantalla.
Qué preguntar cuando la configuración la propone una IA
Pedirle a un modelo que configure un dominio produce una respuesta que suele ser correcta en la forma y ciega al contexto, porque no puede ver el estado actual de tus registros.
El riesgo concreto no es que la instrucción esté mal escrita, es que sustituya registros existentes que cumplían otra función. El caso más frecuente es el del correo: una configuración nueva que reemplaza los MX y deja al dominio sin recibir mensajes, algo que nadie nota hasta que un cliente pregunta por qué no le respondieron.
La forma de evitarlo es dar el estado actual antes de pedir el cambio. Pega tus registros tal como están y pide que te diga cuáles hay que modificar, cuáles añadir y, sobre todo, cuáles no se deben tocar.
Y antes de aplicar nada, una pregunta de control que rara vez se hace: qué pasa si esto sale mal y cómo se revierte. En DNS, revertir es sencillo si anotaste los valores anteriores, y bastante incómodo si no lo hiciste.
El orden en que conviene hacerlo todo
Para un proyecto que arranca, la secuencia que menos sorpresas da es siempre la misma.
Primero registra el dominio y comprueba que el correo de contacto funciona. Después decide dónde vivirá el sitio y crea el registro que apunta ahí, empezando con un tiempo de vida corto mientras pruebas. Cuando el sitio ya responda, deja que la plataforma emita el certificado y comprueba que carga sin advertencias. Solo al final, si vas a usar correo con el dominio, configura los MX y las firmas correspondientes.
Hacerlo en ese orden permite que cada paso se verifique por separado. Cuando se configura todo a la vez y algo no funciona, no hay forma de saber cuál de las cuatro cosas falló, y se acaba cambiando valores al azar hasta que algo responde.