Publicar un sitio estático con dominio propio
Del repositorio a un sitio en línea, con HTTPS y presencia en buscadores. El proceso es general, válido para cualquier plataforma de hosting estático; Vercel aparece solo como ejemplo en cuadros aparte.
Qué vamos a lograr y qué necesitas antes
Al terminar, tu sitio estático (HTML, CSS y JavaScript ya generados, sin servidor propio que mantener) estará disponible en tu propio dominio, servido por HTTPS, y con los medios básicos para que un buscador sepa que existe.
Antes de empezar, necesitas tres cosas: el código del sitio en un repositorio Git (GitHub, GitLab o Bitbucket, según lo que acepte tu plataforma de hosting); un dominio ya registrado a tu nombre; y acceso al panel donde se administra el DNS de ese dominio — normalmente el panel del registrador donde lo compraste, aunque a veces el DNS vive en un proveedor distinto.
Figura: el camino completo tiene cinco eslabones — repositorio, hosting, dominio propio, HTTPS y presencia en buscadores — y cada uno depende de que el anterior esté funcionando.
Equivalente textual del flujo
- Repositorio (código) — el punto de partida.
- Hosting (build) — construye y publica el sitio.
- Dominio propio — conectado al hosting por DNS.
- HTTPS — emitido una vez que el DNS es correcto.
- Buscadores — descubren e indexan el sitio ya publicado.
Desplegar el sitio
El primer paso no depende todavía del dominio: conectar el repositorio a una plataforma de hosting estático para que construya y publique el sitio en cada cambio. En el panel de la plataforma, autorizas el acceso a tu proveedor de Git, eliges el repositorio, y defines tres datos: el comando de build (el que genera los archivos finales listos para servir), el directorio de salida (la carpeta donde queda ese resultado) y la rama de producción (la rama cuyo contenido se publica en el dominio principal; el resto suele quedar como vistas previas, no en el dominio real).
Error típico: la plataforma no tiene permiso sobre el repositorio. Si tu organización en GitHub, GitLab o Bitbucket restringe el acceso de aplicaciones externas, el repositorio no aparece en la lista de importación hasta que alguien con permisos de administración autorice explícitamente esa integración.
main, esa es la que se usa por defecto.
Conectar el dominio
Conectar un dominio significa indicarle al sistema de nombres (DNS) que las visitas a ese dominio deben llegar al hosting donde publicaste el sitio. Hay dos caminos generales, y cuál conviene depende de dónde administras hoy el DNS.
Si tu DNS ya vive en un proveedor que usas para otras cosas — en particular el correo —, suele convenir mantenerlo ahí y solo agregar un registro A (si el dominio es la raíz, como tu-dominio.com) o un registro CNAME (si es un subdominio, como www.tu-dominio.com) que apunte al valor que indique tu plataforma de hosting. Si en cambio ese dominio no tiene nada más configurado, delegar los nameservers a la plataforma de hosting suele ser más simple: la plataforma administra entonces todo el DNS de ese dominio desde un solo lugar.
Antes de cambiar nameservers: revisa si el dominio tiene DNSSEC activado — cambiar de proveedor sin resolver eso primero puede dejarlo sin resolver durante días. Y antes de tocar cualquier registro, copia los que ya existen, en especial los de correo (MX, SPF, DKIM): perderlos corta la entrega de correos hasta que se restauren.
www. Para la vía de registro, el panel muestra el valor exacto de A o CNAME que debes copiar en tu DNS actual — usa siempre el valor que te muestre tu propia plataforma, nunca uno copiado de otro proyecto. Para la vía de nameservers, el panel entrega los nameservers propios de Vercel para pegarlos en tu registrador.
Figura: la elección entre registro A/CNAME o delegar nameservers depende de dónde administras hoy el DNS; en ambos casos, revisa DNSSEC y conserva los registros de correo antes de cambiar nameservers.
Equivalente textual del flujo
- Pregunta de partida: ¿dónde administras hoy el DNS?
- Camino 1: agregar un registro A o CNAME, manteniendo el DNS actual.
- Camino 2: delegar los nameservers a la plataforma de hosting.
- Ambos caminos: revisar DNSSEC y conservar los registros de correo (MX, SPF, DKIM) antes de cambiar nameservers.
La variante www
Tu dominio puede visitarse con o sin el prefijo www — para el DNS y para un buscador, www.tu-dominio.com y tu-dominio.com son direcciones distintas, aunque muestren el mismo sitio. Si ambas quedan activas sin relación entre sí, un buscador puede indexarlas por separado como contenido duplicado. La solución estándar es elegir una como principal y redirigir la otra hacia ella con una redirección permanente (código 308), para que tanto las personas como los buscadores entiendan que es el mismo sitio, no dos copias.
www y permite elegir, desde Domains → Edit → Redirect to, cuál de las dos redirige a la otra. Su propia documentación explica preferir www como principal porque el estándar de DNS no permite un registro CNAME directamente sobre un dominio raíz; esa es una particularidad técnica de cómo funciona el DNS, no una regla universal para cualquier plataforma.
HTTPS
La mayoría de las plataformas de hosting estático emite y renueva el certificado HTTPS de forma automática, apoyándose en un proveedor de certificados estándar de la industria — pero solo puede hacerlo una vez que el DNS de tu dominio apunta correctamente al hosting. Mientras el DNS esté mal configurado, o recién haya cambiado, es normal que el certificado tarde en aparecer o que el navegador muestre una advertencia temporal.
Verificar la propagación
Un cambio de DNS no llega a todo internet en el mismo instante: cada resolver (el servidor que tu red consulta primero) guarda la respuesta anterior durante un tiempo antes de volver a preguntar. Para ver qué está respondiendo realmente el DNS, en vez de solo tu navegador, usa nslookup tu-dominio.com 8.8.8.8 (o el comando equivalente de tu sistema) para consultar directamente un DNS público, sin pasar por la caché de tu proveedor de internet.
Si tu propia red todavía muestra una respuesta vieja o un error NXDOMAIN («dominio no encontrado»), probablemente sea su caché, no el DNS real. En Windows, ipconfig /flushdns limpia la caché local del equipo (no la de tu router ni la de tu proveedor de internet); otra forma rápida de descartar el problema es probar desde datos móviles, en una red distinta. Un verificador de propagación en línea muestra la respuesta que ven varios puntos del mundo a la vez: si la mayoría ya coincide con el valor correcto y solo quedan unos pocos distintos, es cuestión de tiempo, no un error de configuración.
Figura: tu navegador consulta al resolver DNS de tu red; si no tiene la respuesta en caché, pregunta al servidor autoritativo del dominio. Una caché vieja en tu red puede seguir mostrando NXDOMAIN hasta que expire o se limpie.
Equivalente textual del flujo
- Tu navegador consulta al resolver DNS de tu red.
- Si el resolver no tiene la respuesta en caché, consulta al servidor DNS autoritativo del dominio.
- El servidor autoritativo responde con la IP del hosting.
- Una caché vieja en tu red puede seguir devolviendo NXDOMAIN hasta que expire o se limpie manualmente.
Presencia en buscadores
Una vez que el sitio responde en tu dominio, el paso siguiente es decirle a los buscadores que existe. En Google Search Console, agregas una propiedad de tipo dominio (cubre todas sus variantes y subdominios a la vez) y la verificas con un registro TXT: Search Console te entrega un valor para pegar en el DNS, normalmente con el nombre/host en blanco o como «@»; una vez que ese registro se propaga —puede tardar de minutos a un par de días— confirmas la verificación desde la misma herramienta. Conviene no borrar ese registro después: Google puede revalidarlo periódicamente.
Con la propiedad verificada, envías tu sitemap.xml completo desde la sección Sitemaps, y puedes pedir explícitamente la indexación de la página principal desde la herramienta de inspección de URLs. Es normal, en un sitio recién publicado, que el estado inicial diga «Descubierta: actualmente sin indexar» — no es un error, solo significa que todavía no se revisó a fondo; eso puede tardar de días a semanas. Bing Webmaster Tools sigue un proceso equivalente (verificación de propiedad y envío de sitemap), con su propia interfaz.
Figura: cinco pasos — generar el registro TXT, agregarlo en el DNS, verificar la propiedad, enviar el sitemap y solicitar la indexación — terminan en un estado inicial que suele decir «Descubierta: actualmente sin indexar», normal en un sitio nuevo.
Equivalente textual del flujo
- Generar el registro TXT que entrega Search Console.
- Agregarlo en el DNS del dominio.
- Verificar la propiedad desde Search Console.
- Enviar el sitemap.xml.
- Solicitar la indexación de la página principal.
- Estado inicial normal: «Descubierta: actualmente sin indexar». Bing Webmaster Tools sigue un proceso equivalente.
Errores comunes
| Síntoma | Causa probable | Qué revisar |
|---|---|---|
| El dominio muestra «configuración inválida» en el hosting | El registro A o CNAME no coincide con el valor que pide la plataforma, o apunta a otro proyecto | Compara el valor exacto que muestra tu plataforma con el registro publicado en tu DNS |
El subdominio www no resuelve | Falta el registro CNAME de www, o usa un nombre distinto al que pide la plataforma | Agrega o corrige el registro CNAME de www con el nombre exacto que indique tu plataforma |
El dominio funciona sin www pero no con www (o al revés) | Solo se agregó y configuró uno de los dos en el proyecto | Agrega ambas variantes en el hosting y configura la redirección entre ellas |
| El correo deja de llegar tras el cambio de DNS | Se perdieron los registros MX, SPF o DKIM al delegar nameservers o editar el DNS | Restaura esos registros con los valores que daba tu proveedor de correo antes del cambio |
| El sitio sigue mostrando un estado anterior desde tu propia red | Caché DNS local o del proveedor de internet desactualizada | Limpia la caché DNS local, prueba con datos móviles, o espera a que expire el TTL |
| El certificado HTTPS no se emite o el navegador avisa de sitio no seguro | El DNS todavía no apunta correctamente al hosting, o cambió hace muy poco | Espera a que el DNS propague y a que la plataforma confirme el dominio como verificado |
| Search Console no logra verificar el dominio por TXT | El registro no se agregó en el host/nombre correcto, o no ha propagado todavía | Confirma que el campo Host/Nombre quedó vacío o como «@», y reintenta tras uno o dos días |
| El sitemap aparece como «no se pudo obtener» | La URL del sitemap no es accesible públicamente, o el archivo no es XML válido | Abre la URL del sitemap directamente en el navegador y confirma que carga sin errores antes de reenviarlo |
Verificación final
- El sitio responde con HTTPS en el dominio propio, sin advertencias del navegador.
- La variante con y sin
wwwfunciona, y una de las dos redirige de forma permanente a la otra. robots.txtresponde y permite el rastreo del sitio.sitemap.xmlresponde con las URLs reales del sitio, en formato válido.- Una ruta inexistente responde con un error 404 real, no con una página que simule el error.
Fuentes
-
Deploying Git Repositories with Vercel (enlace externo)
Documentación oficial de Vercel sobre conectar un repositorio, la rama de producción y los despliegues automáticos.
-
Adding & Configuring a Custom Domain (enlace externo)
Documentación oficial de Vercel sobre agregar un dominio, registros A/CNAME y nameservers.
-
Deploying & Redirecting Domains (enlace externo)
Documentación oficial de Vercel sobre la redirección entre la variante www y el dominio raíz.
-
Encryption and TLS (enlace externo)
Documentación oficial de Vercel sobre la emisión automática de certificados HTTPS y la redirección forzada a HTTPS.
-
Verify your site ownership (enlace externo)
Ayuda oficial de Google Search Console sobre la verificación de dominio mediante un registro TXT.
-
Sitemaps report (enlace externo)
Ayuda oficial de Google Search Console sobre enviar un sitemap y leer su estado.
-
Managing a custom domain for your GitHub Pages site (enlace externo)
Documentación oficial de GitHub sobre los registros A y CNAME para un dominio propio en GitHub Pages.
-
Bing Webmaster Tools — guía de verificación
Bing Webmaster Tools sigue un proceso equivalente (verificación de propiedad y envío de sitemap); no se encontró una URL de ayuda oficial estable para enlazar con confianza.
Revisión: 19 de octubre de 2026.