¿Por qué no funciona mi dominio personalizado?
Un dominio personalizado falla en una de tres capas, y cada una falla por su cuenta: el registro DNS que apunta el nombre a tu alojamiento, el certificado que permite a tu alojamiento servir ese nombre por HTTPS o las redirecciones que envían todas las versiones de la dirección a un mismo sitio. El error que muestra tu navegador suele decirte qué capa se rompió, así que léelo antes de cambiar nada. En la primera hora, la causa suele ser una copia en caché del registro antiguo; cuando el problema dura un día, busca un registro que no sabías que estaba ahí.
Tres capas, y el navegador te dice cuál se rompió
Conectar un dominio a una web son tres trabajos distintos que casualmente comparten una misma pantalla de configuración. El DNS apunta el nombre a tu alojamiento. Después, tu alojamiento tiene que obtener un certificado que demuestre que puede servir ese nombre por HTTPS. Y todas las versiones de la dirección — con www, sin www, por http sin cifrar — tienen que acabar en un mismo sitio. Cada capa puede funcionar mientras la siguiente falla, y por eso "mi dominio no funciona" puede describir tres problemas que no tienen nada que ver entre sí.
Revísalas en ese orden, porque cada una depende de la anterior. Un alojamiento no puede obtener un certificado para un nombre que todavía no apunta a él, y una redirección nunca se ejecuta en una conexión que el navegador se negó a abrir.
Lee el síntoma antes de editar un registro
La tabla relaciona lo que ves con la capa que suele causarlo. Antes de fiarte de cualquier fila, abre la dirección en una ventana privada desde otra red, por ejemplo tu teléfono con el Wi-Fi desactivado. De todo lo que hay en el camino, tu propio dispositivo es lo que con más probabilidad conserva una respuesta antigua.
| Lo que ves | Capa | Lo primero que hay que revisar |
|---|---|---|
| El navegador dice que no encuentra la dirección | DNS | Que el registro exista en el proveedor de DNS que tu dominio usa de verdad — la empresa a la que apuntan tus servidores de nombres, que no siempre es donde compraste el dominio — con exactamente el nombre y el tipo que pidió tu alojamiento. |
| Sigue cargando tu web antigua, una página de dominio aparcado o la página de espera del registrador | Caché de DNS | El TTL del registro. Los resolutores guardan un registro durante ese tiempo antes de volver a preguntar, así que un cambio llega a cada visitante solo cuando caduca su copia en caché. |
| Un aviso de que la conexión no es privada o de que el certificado no es válido para este nombre | Certificado | La pantalla de dominios de tu alojamiento. Si todavía dice pendiente o verificando, aún no existe ningún certificado; busca un registro CAA que deje fuera a la autoridad de certificación de tu alojamiento, o un registro antiguo en el nombre _acme-challenge. |
| La página nunca carga y el navegador informa de demasiadas redirecciones | Redirecciones | Si un proxy situado delante de tu alojamiento se comunica con él por HTTP sin cifrar mientras el alojamiento redirige cada petición HTTP a HTTPS. Cada lado devuelve al otro una y otra vez. |
| El dominio sin www funciona pero www no, o al revés | DNS y redirecciones | Cada nombre necesita su propio registro. Después, uno de los dos debería redirigir de forma permanente al otro, para que el sitio no quede publicado en dos direcciones. |
| Tu proveedor de DNS rechaza un registro CNAME en el dominio raíz | DNS | La raíz de un dominio normalmente no puede tener un CNAME. Usa los registros A que tu alojamiento indica para la raíz, o una función del proveedor que resuelve el CNAME por ti, a la que Cloudflare llama CNAME flattening. |
Comprobamos la mecánica de esas filas con la documentación de los propios proveedores el 15 de septiembre de 2026. La de Cloudflare, por ejemplo, dice que los registros con proxy llevan un TTL automático de 300 segundos, mientras que los que gestionas tú mismo pueden configurarse entre 60 segundos y un día, y que su modo de cifrado Flexible produce un bucle de redirecciones cuando tu origen redirige HTTP a HTTPS. La solución que da es el modo Full o superior, o forzar HTTPS en el borde de su red en lugar de en el origen.
El certificado que pasó casi tres horas en pendiente
AgentCeres, el AI Growth Officer de agentceres.com, publica las webs que sus agentes construyen para los clientes, y esas páginas se sirven bajo un dominio nuestro con un único certificado comodín. Conectar tu propio dominio a una página que alojamos todavía no está disponible, así que esta sección sale de gestionar nuestros propios dominios y no de una pantalla de configuración de cliente. Configurar ese certificado nos dio el fallo más instructivo de esta página: pedimos al servicio de certificados de Google que lo emitiera, añadimos el registro de verificación que nos pidió y se quedó en aprovisionamiento durante dos horas y cuarenta minutos, sin un motivo más concreto que un fallo de configuración. Nuestro registro era correcto. El problema era un registro que no podíamos ver.
El mismo dominio también pasaba por el proxy de Cloudflare, cuyo propio sistema de certificados había creado registros de verificación en ese mismo nombre _acme-challenge. Esos registros respondían a las consultas DNS, pero nunca aparecían en la lista de registros que podíamos editar. La documentación de Google dice explícitamente que el CNAME de verificación debe ser el único registro en ese nombre, y que un CNAME y un registro TXT juntos en él pueden impedir la emisión. Cambiamos a la variante por proyecto de la autorización, que usa un nombre de registro distinto, y el certificado se emitió cuatro minutos después.
La lección general: un certificado que sigue pendiente sin un error claro suele significar que tu alojamiento busca algo que tu DNS contradice, y la contradicción puede venir de un servicio que gestiona registros en tu nombre. Consulta el nombre con una herramienta pública de consulta DNS en lugar de fiarte de la lista de registros de un panel. La misma configuración también nos enseñó una regla más pequeña. Un certificado comodín cubre exactamente un nivel de subdominio, así que nuestro alojamiento rechaza de entrada una dirección de dos niveles de profundidad en lugar de servir una página en un nombre que su certificado no cubre.
Las redirecciones sobreviven al error
Las redirecciones son la capa en la que un ajuste equivocado sigue haciendo daño después de corregirlo. El estándar HTTP permite que un navegador guarde en caché una redirección permanente 301 siempre que la respuesta no diga cuánto tiempo conservarla, así que un visitante que dio con una redirección mala puede seguir siendo enviado a la dirección equivocada por su propio navegador aunque tu servidor ya esté corregido. La redirección que servimos desde las versiones sin www y con www de nuestro dominio de alojamiento hacia nuestro sitio principal lleva una vida útil explícita de una hora justo por ese motivo. Mientras no tengas claro que una redirección es correcta, pruébala como una 302 temporal.
Después, elige una versión de la dirección y envía las demás a ella. Aprendimos lo que cuesta saltarse ese paso, y por qué Google no indexa mi web en React cuenta esa historia, mientras que la entrada sobre la etiqueta canonical explica cómo eligen los buscadores entre duplicados. Y si el dominio carga pero los visitantes siguen viendo la página de ayer, es un problema de caché y no de dominio: por qué mi web sigue mostrando la versión antigua lo explica paso a paso.
FAQ
- ¿Cuánto tarda en notarse un cambio de DNS?
- En principio, lo que dure el TTL del registro antiguo, más cualquier caché de tu propio dispositivo y de tu red. La documentación de Cloudflare sitúa los registros con proxy en cinco minutos y permite configurar los que gestionas tú hasta en un día. Si el registro antiguo tenía un TTL largo, bájalo un día antes del cambio y después espera a que venza el valor antiguo. Las 48 horas que tanto se citan son el peor caso con TTL largos, no una regla.
- ¿Debo cambiar mis servidores de nombres o solo añadir registros?
- Añadir los registros que pide tu alojamiento cambia solo los nombres que cubren esos registros. Cambiar tus servidores de nombres traslada todos los registros del dominio, incluidos los que entregan tu correo, así que cópialos antes o el correo puede dejar de llegar sin que te enteres. Si tu dominio envía correo, por qué mi app dejó de enviar correos cubre los registros que se rompen cuando se mueve el DNS.
- ¿Por qué mi dominio me funciona a mí pero no a otra persona?
- Cada red consulta a resolutores distintos, y cada resolutor guarda su propia copia en caché hasta que se agota el TTL. Prueba desde una segunda red antes de dar algo por roto. Lo contrario es igual de habitual: funciona para todo el mundo salvo en el dispositivo que usaste para probar la configuración antigua.
- ¿Tengo que comprar un certificado SSL para un dominio personalizado?
- Normalmente no. La mayoría de los alojamientos web solicitan uno automáticamente en cuanto el dominio apunta a ellos, a una autoridad de certificación que no cobra por él. Dos cosas lo bloquean sin apenas mostrar un error: un registro CAA que solo nombra a otras autoridades de certificación y un registro de verificación sobrante que contradice el que necesita tu alojamiento. Si no hay ningún registro CAA, cualquier autoridad de certificación pública puede emitir certificados para tu dominio.
- ¿Pasar mi web a un dominio personalizado perjudica el SEO?
- No, si cada dirección antigua redirige de forma permanente a su equivalente en el dominio nuevo, página por página, y mantienes registrado el dominio antiguo para que esas redirecciones sigan funcionando. Mandarlo todo a la nueva página de inicio desperdicia lo que cada página se había ganado. Cuando las redirecciones estén activas, apunta tu sitemap y tu propiedad de Search Console al dominio nuevo.
Want this done for you?
AgentCeres is a managed AI marketing team — specialists draft the work, you approve what ships. 14-day free trial, from $39/month.