Para conectar un dominio propio a ChatGPT Sites, añade el dominio desde la configuración del Site y configura en tu proveedor DNS los registros exactos que la plataforma indique. Después verifica el estado de la conexión y el funcionamiento de la dirección pública. No existe un valor DNS universal que debas copiar de este artículo.
Esta guía diferencia la conexión técnica de las tareas que la acompañan: conservar el correo, elegir entre dominio raíz y www, revisar HTTPS y evitar contradicciones entre redirecciones, canonical y sitemap. Si el dominio ya recibe visitas, prepara el cambio antes de modificar su destino.
1. Comprueba los requisitos previos
La guía oficial de Sites indica que debes poseer el dominio y tener acceso a sus DNS. La función admite apex o subdominio donde esté disponible; los dominios personalizados no están disponibles en Enterprise en el lanzamiento.
- Confirma que puedes administrar el Site y que aparece la opción de dominio.
- Identifica dónde se gestionan realmente los DNS; no siempre coincide con la empresa donde compraste el dominio.
- Guarda una copia de los registros actuales y anota qué servicio utiliza cada uno.
- Ten preparada la web de destino y una persona responsable del cambio.
- Si hay una web anterior, conserva acceso a ella y define cómo volver al estado anterior ante una incidencia.
No compartas contraseñas ni claves en el contenido del sitio. Si interviene un profesional, utiliza permisos acotados y conserva tú el control del dominio. Si aún no has creado el proyecto, empieza por qué es ChatGPT Sites y cómo funciona.
2. Elige el dominio principal: apex, www o subdominio
example.com es el dominio raíz o apex; www.example.com es un host distinto. campana.example.com puede identificar una sección o proyecto separado. Estos nombres son ejemplos didácticos: no son destinos DNS de Sites.
Si reemplazas una web existente, conservar su dirección principal puede reducir cambios innecesarios. Si empiezas de cero, decide una variante y úsala de forma coherente. No hay una ventaja SEO automática por elegir www o prescindir de él; lo importante es evitar que versiones equivalentes queden sin una política clara.
Escribe el resultado esperado: «la versión principal debe abrirse con HTTPS; la variante alternativa debe llevar a la misma ruta de la principal». Esa frase ayuda a probar la configuración más allá de la portada.
3. Añade el dominio y copia las instrucciones de tu proyecto
En la configuración del Site, selecciona Add domain, introduce el host y copia los tipos y valores DNS que se muestren. Añádelos en el proveedor y vuelve después a refrescar el estado. Esta secuencia procede de la documentación oficial; los controles pueden evolucionar.
Conserva un registro de lo solicitado: nombre del host, tipo de registro y destino o valor. Si no aparece ninguna instrucción, no adivines una IP ni reutilices la configuración de otra web. Primero resuelve la disponibilidad de la función o el estado del dominio con la plataforma.
4. Modifica únicamente los registros necesarios
Al introducir el nombre, comprueba cómo trabaja el panel DNS: algunos añaden el dominio automáticamente y otros esperan el nombre completo. Escribirlo dos veces puede crear un host equivocado. Revisa también que no haya un registro antiguo incompatible en el mismo nombre.
En términos generales, los registros A y AAAA apuntan a direcciones IP, CNAME relaciona nombres y TXT puede utilizarse para verificaciones. El TTL establece durante cuánto tiempo puede almacenarse una respuesta en caché. Esas definiciones no indican qué tipo exigirá tu Site: sigue su configuración concreta. Puedes consultar la referencia de registros DNS.
No elimines la zona completa. Los registros de correo, las verificaciones de servicios y otros subdominios pueden seguir siendo necesarios. Cambiar el destino de la web no implica cambiar de proveedor de email. Si se propone cambiar nameservers, exige primero un inventario y un plan de conservación de todos los servicios.
5. Distingue propagación DNS, conexión y HTTPS
Tras guardar, distintas redes pueden mostrar temporalmente resultados diferentes por la caché DNS. Refresca el estado en Sites y comprueba que el valor publicado coincide con el solicitado. Evita encadenar cambios sin anotar qué modificaste: dificulta saber qué configuración estás probando.
Que un nombre resuelva no demuestra que su certificado sea válido ni que la aplicación responda correctamente. Abre la dirección con HTTPS y revisa que el certificado cubra ese host, que no aparezcan advertencias y que los recursos principales también carguen de forma segura. No des por hecho un plazo fijo de activación del certificado.
Si la plataforma sigue mostrando una conexión pendiente, compara host, tipo y valor antes de culpar a la propagación. Esperar no corrige un nombre duplicado o un destino mal escrito.
6. Configura y prueba la variante alternativa
Conectar el apex no demuestra que www esté atendido, y viceversa. Revisa ambas direcciones. Si necesitas una redirección, debe ejecutarse en una infraestructura que reciba la petición del host alternativo y tenga HTTPS válido; un registro DNS por sí solo no es una redirección HTTP.
Prueba una página interior y, cuando corresponda, parámetros de campaña. El destino debería ser la página equivalente, no siempre la portada. Evita cadenas como www → versión HTTP → versión HTTPS → otra ruta cuando puede existir un destino directo.
7. Si existe una web anterior, conserva las rutas útiles
Prepara una lista de URLs que reciben tráfico, enlaces o solicitudes. Si las páginas siguen cumpliendo la misma función, procura conservar sus rutas. Para las que cambien, documenta un destino equivalente y verifica su redirección permanente. No redirijas indiscriminadamente todas las páginas antiguas al inicio.
Cuando solo cambia el alojamiento y se mantienen las URLs, no inventes una migración de dominio. La guía de Google para cambiar de hosting sin cambiar URLs ayuda a distinguir ambos escenarios. Los problemas y aprendizajes de proyectos publicados se desarrollan en nuestra experiencia con ChatGPT Sites en producción.
8. Alinea canonical, sitemap y enlaces internos
Revisa que cada página indexable declare la URL principal correcta y que el sitemap utilice esa misma versión. Los enlaces internos deberían llevar directamente a ella. Una canonical no sustituye una redirección ni impide que una dirección alternativa pueda visitarse.
Google considera las redirecciones y la canonical señales fuertes de preferencia, y el sitemap una señal más débil; no son una garantía de selección. Consulta sus indicaciones de canonicalización. Evita una canonical hacia la dirección técnica del alojamiento mientras el sitemap publica el dominio comercial.
Errores frecuentes y cómo acotar la causa
- La portada abre y una ruta da error: revisa el enrutamiento; no todo fallo procede del DNS.
- www falla: comprueba el host alternativo, su certificado y su redirección.
- El correo deja de funcionar: compara los registros actuales con la copia previa.
- Sites no verifica: revisa la zona autoritativa, el nombre completo y el valor indicado.
- Se sigue viendo la web antigua: distingue caché DNS, caché del navegador y configuración incorrecta.
- Google muestra una URL anterior: comprueba señales reales y fechas de rastreo antes de introducir más cambios.
Checklist final antes de dar la conexión por terminada
- El dominio principal responde con HTTPS sin advertencias.
- La portada y las páginas interiores correctas funcionan.
- La variante alternativa resuelve según la política acordada.
- Las redirecciones conservan destinos equivalentes.
- Correo, verificaciones y otros subdominios siguen operativos.
- Canonical, sitemap y enlaces internos coinciden.
- No quedan bloqueos de indexación propios de pruebas en páginas que deben ser públicas.
- Los formularios se prueban hasta confirmar recepción, no solo hasta ver un mensaje.
- La configuración final y el procedimiento de recuperación quedan documentados.
