Crear una página web con ChatGPT puede ser rápido. Convertir esa primera versión en un activo digital profesional es otra disciplina. Durante proyectos reales con ChatGPT Sites hemos trabajado mucho más allá de la generación visual: diseño, migración, publicación, DNS, dominios, SEO, blogs, bases de datos, formularios, email transaccional, Search Console, Schema, sitemaps y rendimiento.
Esta guía recoge lo que conviene saber antes de elegir ChatGPT Sites para una empresa o una agencia. No es una review promocional ni una lista de funciones. Es una lectura técnica y crítica de los problemas que aparecen cuando el sitio debe conservar URLs, recibir leads, ser rastreable, medir resultados y seguir funcionando después del lanzamiento.
Qué es ChatGPT Sites y cuál es su situación actual
ChatGPT Sites permite crear, alojar, iterar y publicar sitios web, aplicaciones ligeras y experiencias interactivas desde ChatGPT. OpenAI lo mantiene en beta pública. A 29 de agosto de 2026, la documentación oficial indica disponibilidad para ChatGPT Plus, Pro, Business, Enterprise y Edu, con límites específicos por plan que se comparten entre los Sites de la cuenta. El Help Center resume el acceso como disponible para cuentas Plus, Pro y workspaces elegibles y advierte que el despliegue puede no haber llegado todavía a todas las cuentas.
Las dos formulaciones reflejan fases distintas del rollout, no necesariamente una contradicción: la página de producto enumera los planes admitidos, mientras que el Help Center añade condiciones de activación, administración y despliegue progresivo. Sites no está disponible en Free ni Go y, según la documentación vigente, no está disponible en el EEE, Suiza o Reino Unido en el lanzamiento. En Enterprise, los administradores controlan el acceso y la publicación pública; los dominios personalizados no estaban disponibles para Enterprise en el lanzamiento.
Los límites pueden impedir crear un Site, añadir almacenamiento o mantener público un proyecto de uso elevado, aunque la gestión de Sites existentes siga disponible. OpenAI recomienda consultar los límites mostrados en la propia experiencia, porque pueden cambiar durante la beta. No conviene convertir ninguna condición actual en una garantía futura.
Generar la web es la parte fácil
La generación inicial resuelve una parte valiosa: traduce objetivos y referencias en una interfaz funcional con gran velocidad. Pero un sitio preparado para producción añade capas que no aparecen necesariamente en la primera vista:
- Arquitectura: rutas, jerarquía, plantillas, datos y relaciones entre páginas.
- Producción: entorno público, dominio, certificados, DNS y manejo de errores.
- QA: responsive, navegación, accesibilidad, estados vacíos y pruebas de integraciones.
- SEO: canonical, robots, sitemaps, redirecciones, metadatos, Schema y enlazado interno.
- Operaciones: formularios, correo, analítica, bases de datos, secretos y mantenimiento.
En nuestras implementaciones, las operaciones que combinan investigación, cambios de código, escritura de datos, publicación y comprobaciones pueden consumir bastante tiempo de procesamiento. No existe un tiempo universal: depende del alcance, el modelo, el contexto, las herramientas y el número de verificaciones. El aprendizaje operativo es claro: conviene agrupar operaciones relacionadas y evitar tests, deploys y comprobaciones redundantes. Esto reduce consumo, acorta ciclos y disminuye el riesgo de validar una versión distinta de la que finalmente se publica.
ChatGPT Sites con dominio propio: el detalle de www
Cuando la función está disponible, Sites permite conectar un dominio que ya pertenece al usuario. La plataforma no registra el dominio: hay que configurar en el proveedor DNS los valores que entrega el panel. El punto delicado es que el dominio raíz y su variante con www son hosts diferentes.
Puede ocurrir que https://dominio.com responda correctamente mientras https://www.dominio.com no esté resuelto o no redirija. Para una implementación profesional, la regla habitual es:
dominio.com/* → HTTP 200
www.dominio.com/* → HTTP 301 → dominio.com/*La redirección debe conservar la ruta y los parámetros cuando proceda. Así, un enlace histórico a www.dominio.com/servicio llega a dominio.com/servicio, no solo a la home. La solución puede implementarse con Cloudflare, un servicio especializado de redirección o infraestructura equivalente. No recomendamos cambiar nameservers indiscriminadamente: primero hay que inventariar DNS, correo, verificaciones y servicios que dependen de la zona actual.
El 301 permanente alinea experiencia de usuario y señales de canonicalización, reduce duplicidades y conserva mejor el valor de enlaces históricos. Debe validarse con respuestas reales: el dominio principal devuelve 200 y www devuelve 301 hacia la URL canónica equivalente.
Search Console después de cambiar de plataforma
Cambiar Wix, WordPress u otro hosting por ChatGPT Sites no obliga automáticamente a verificar de nuevo Search Console si la propiedad sigue verificada. La verificación puede depender del dominio, de un registro DNS o de otro método que continúa vigente aunque cambie el hosting.
Después de publicar conviene comprobar:
- que la propiedad adecuada sigue verificada;
- que la URL pública responde y Google puede rastrearla;
- que robots y meta robots permiten indexar;
- que el canonical apunta a la variante correcta;
- que el sitemap incluye las URLs canónicas;
- que las variantes antiguas redirigen de forma permanente;
- que la inspección de URL refleja la versión publicada.
Si se consolida www hacia el dominio sin www, es normal que las URLs antiguas aparezcan como “Página con redirección”. No es un error cuando el 301 es intencional, conserva la ruta y lleva a una página equivalente. Es la consecuencia esperada de retirar esa variante del índice.
Sitemaps: un HTTP 200 no garantiza que el XML sea válido
Un sitemap puede cargar en el navegador y responder HTTP 200, pero contener valores que Search Console no puede interpretar. En proyectos reales encontramos fechas <lastmod> generadas con un formato de base de datos como:
2026-08-27 17:27:25Una representación W3C sencilla y válida es:
2026-08-27<lastmod> informa de la última modificación significativa de la URL. No debería cambiar en cada despliegue técnico si el contenido no se ha actualizado. Convertir la fecha almacenada al formato correcto no implica inventarla ni recalcularla: solo normaliza su representación.
Una revisión editorial sustancial sí puede justificar una nueva fecha: añadir un resumen útil, nuevas secciones, una reorganización relevante, FAQs necesarias, contenido adicional o información actualizada. Un cambio puramente visual, un ajuste de CSS o un deploy sin cambios editoriales no debería presentarse automáticamente como actualización del artículo.
Migrar un blog: conservar la historia antes de optimizar
Migrar decenas o cientos de artículos no consiste en copiar texto. Cada entrada tiene identidad y señales acumuladas: slug, URL, contenido, title, meta description, fechas, categorías, imágenes, enlaces y datos estructurados. La migración debe separar fidelidad de optimización. Primero se reproduce el original con seguridad; después se mejora editorialmente.
Las URLs con ñ, tildes, Unicode o slugs largos requieren especial cuidado. Normalizarlas porque “parecen raras” puede crear una URL nueva y romper enlaces, referencias externas y señales históricas. Si la URL ya existe y recibe tráfico o enlaces, el slug debe preservarse literalmente o redirigirse con un mapa explícito. Nunca debería limpiarse en masa sin evaluación.
Para un blog grande, una base de datos y una plantilla dinámica /post/[slug] son más mantenibles que cientos de páginas creadas manualmente. La plantilla centraliza el renderizado; cada registro conserva el contenido y los metadatos. Esto permite importar de forma idempotente, auditar por estados y corregir componentes globales sin reescribir cada artículo.
D1 y contenido dinámico: separar datos de presentación
Una base de datos como D1 permite separar contenido, metadata, categorías, tags, excerpts, estado editorial y plantilla. Conceptualmente, el artículo es un registro; las categorías y etiquetas son relaciones; el frontend consulta datos y los convierte en una página canónica.
Esta separación facilita migraciones grandes porque permite validar antes de importar, detectar duplicados, conservar Unicode, bloquear una incidencia sin detener todo el lote y ejecutar cambios editoriales de forma controlada. También evita que un ajuste de diseño obligue a tocar el cuerpo de 100 artículos. La arquitectura concreta puede variar; lo importante es que la fuente de verdad sea coherente y que el renderizado no genere versiones divergentes del mismo dato.
Paginación: tener los posts en la base no basta
Otro problema real aparece cuando todos los artículos existen en la base de datos, pero /blog consulta o renderiza solo un límite. El contenido está almacenado, pero no todo es navegable desde el índice. La solución no suele ser cargar cientos de tarjetas en una sola página.
Una paginación robusta mantiene un número razonable de artículos por página, evita duplicados entre páginas y usa enlaces HTML rastreables con números, Anterior y Siguiente. Los hubs de categorías deben aplicar la misma lógica cuando superan el límite. Así se conservan rendimiento, accesibilidad y descubrimiento sin depender exclusivamente de un botón JavaScript de “cargar más”.
Formularios: enviar no significa recibir un email
Esta distinción evita una de las falsas sensaciones de seguridad más comunes. Una interfaz puede mostrar “Formulario enviado correctamente” porque recibió una respuesta del frontend, aunque nunca se haya entregado una notificación en el buzón.
El recorrido completo tiene al menos siete etapas:
- Formulario: recoge y valida los campos.
- Captura: envía los datos a un endpoint.
- Almacenamiento: guarda el lead cuando la arquitectura lo requiere.
- Procesamiento: sanitiza, aplica reglas y registra errores.
- Notificación: construye un mensaje comprensible para el equipo.
- Envío transaccional: un proveedor acepta y transmite el correo.
- Recepción: el mensaje llega al buzón o queda identificado como rechazado, diferido o spam.
Según el proyecto puede integrarse Resend, Formspree o una solución equivalente. Ninguno es obligatorio por definición. Lo imprescindible es probar el circuito completo y mantener la clave de API como secreto del servidor, nunca expuesta en el navegador.
Remitente, destinatario y autenticación
El destinatario es el buzón que recibe la consulta. El remitente técnico pertenece al dominio autenticado por el proveedor transaccional. Si el usuario dejó su correo, puede utilizarse como Reply-To cuando la plataforma lo permite, pero no conviene falsificarlo como remitente. SPF y DKIM ayudan a demostrar que el proveedor está autorizado; DMARC y las políticas del receptor influyen en el tratamiento final.
El proveedor donde está alojado el buzón corporativo no tiene que ser el mismo proveedor que realiza el envío transaccional. Puede mantenerse el correo corporativo con un proveedor y autenticar un subdominio específico para los formularios en otro. Hay que proteger datos, reducir spam, limitar abuso y registrar errores sin almacenar información sensible innecesaria.
Structured Data: una migración visual puede perder la entidad
Reproducir páginas y diseño no garantiza conservar la información semántica que ayudaba a describir la organización. En una migración conviene auditar Organization, LocalBusiness o el tipo apropiado para las sedes, WebSite, BlogPosting y BreadcrumbList.
También deben revisarse direcciones visibles, sedes, redes sociales, mapas y alcance comercial. sameAs relaciona la entidad con perfiles oficiales o representaciones equivalentes; hasMap enlaza el mapa de una ubicación. Un enlace de Google Maps no es una red social.
Si una empresa tiene oficinas en dos países y atiende internacionalmente, ubicación física no equivale a área de servicio. Las sedes describen dónde existe presencia; areaServed puede expresar el mercado hispanohablante cuando eso coincide con el contenido visible. Todas las ubicaciones deben relacionarse con una organización principal coherente, evitando varios Organization contradictorios para la misma entidad.
Cómo auditar Schema manualmente
- abre el código fuente de la página y localiza los bloques
application/ld+json; - revisa IDs, URLs, tipos y relaciones en Schema Markup Validator;
- utiliza Rich Results Test para los tipos compatibles con resultados enriquecidos;
- compara el JSON-LD con la información visible;
- vuelve a validar después de publicar, porque el template o el servidor pueden alterar el resultado.
Rich Results Test no valida necesariamente todos los tipos y propiedades de Schema.org. Que no muestre una entidad como resultado enriquecido no significa por sí solo que el marcado sea inválido; para cobertura general, Schema Markup Validator sigue siendo necesario.
llms.txt: mapa curado, no promesa de visibilidad
llms.txt es una propuesta abierta, publicada originalmente por Jeremy Howard y actualizada como convención, para ofrecer a agentes y modelos un documento Markdown breve que explique un sitio y enlace sus recursos de mayor valor. Intenta reducir ruido y ayudar a construir contexto fiable.
En un sitio corporativo recomendamos tratarlo como un mapa editorial: entidad, servicios, especialización, mercados, blog, hubs y recursos estratégicos. No debería convertirse en otro sitemap con cientos de artículos individuales. Para eso ya existen el índice del blog, sus categorías y el sitemap.
llms.txt no sustituye robots.txt, sitemap, Schema ni contenido. No es un factor confirmado de ranking de Google. Tampoco garantiza aparecer en ChatGPT, Gemini o Perplexity. Es una capa de descubrimiento y contexto cuyo soporte depende de cada sistema.
Precio de ChatGPT Sites en agosto de 2026
Esta sección necesita distinguir tres cosas: la suscripción de ChatGPT, la inclusión temporal de Sites y un eventual precio específico del producto.
Precio de ChatGPT
La documentación oficial consultada el 29 de agosto de 2026 mantiene ChatGPT Plus en USD 20 al mes. Pro parte de USD 100 al mes en la tabla vigente, mientras que Business muestra precios por usuario y Enterprise/Edu requiere condiciones de workspace. Estos son precios de planes de ChatGPT, no tarifas unitarias de Sites.
Precio específico de ChatGPT Sites
OpenAI indica que Sites está incluido en planes elegibles durante la beta pública, hasta límites específicos por plan. No ha anunciado en esas páginas una estructura definitiva independiente por Site. Por eso es incorrecto afirmar que “ChatGPT Sites cuesta USD 20”. Plus cuesta USD 20; Sites está incluido actualmente dentro de ese plan elegible y sujeto a límites que pueden cambiar.
Disponibilidad y rollout
Sites figura para Plus, Pro, Business, Enterprise y Edu. El rollout puede ser progresivo, los administradores pueden controlar el acceso y existen restricciones regionales. Free y Go no tienen Sites en la documentación vigente. Las condiciones de publicación pública, dominios y límites varían por plan o workspace.
Punto de equilibrio: un ejemplo, no una previsión
Supongamos, solo para comparar, un constructor tradicional hipotético de USD 7 por sitio al mes y una cuenta Plus de USD 20. La aritmética sería:
| Sitios | Constructor hipotético |
|---|---|
| 1 | USD 7/mes |
| 2 | USD 14/mes |
| 3 | USD 21/mes |
| 4 | USD 28/mes |
| 5 | USD 35/mes |
| 7 | USD 49/mes |
Matemáticamente, el cruce aparece alrededor de tres sitios. Esto no significa que OpenAI vaya a permitir indefinidamente varios Sites por USD 20. La comparación tampoco incorpora futuros precios de Sites, créditos, límites de uso, almacenamiento, tráfico, dominios, email, formularios, servicios externos ni mantenimiento.
Dos escenarios financieros posibles
Escenario A: beta actual
Si una cuenta elegible permite varios proyectos dentro de sus límites, Sites puede ser económicamente atractivo para ecosistemas multisitio. La ventaja no es solo alojamiento: la misma experiencia ayuda a producir, iterar y mantener. Aun así, cada proyecto consume capacidad y puede requerir servicios externos.
Escenario B: modelo definitivo
OpenAI podría restringir Sites a determinados planes, introducir precio por Site, aplicar créditos, medir almacenamiento o tráfico, o modificar límites. No hay base oficial para inventar tarifas. La recomendación prudente es no construir un modelo financiero a largo plazo suponiendo que el régimen actual de beta será permanente.
La cuenta y los activos deberían pertenecer al cliente
En proyectos profesionales suele ser conveniente que la cuenta, suscripción, dominio y activos principales pertenezcan al cliente. La agencia puede administrar, desarrollar y acompañar, pero el cliente conserva control de infraestructura, facturación y continuidad.
Esto reduce dependencia operativa, facilita cambios de proveedor y deja más claro quién autoriza publicaciones, dominios y secretos. La relación profesional mejora cuando propiedad y permisos están definidos desde el inicio.
Rendimiento: el potencial existe, pero no se promete
En proyectos reales hemos observado resultados técnicos muy altos en PageSpeed Insights. No publicamos cifras identificables ni prometemos 100/100, porque el rendimiento cambia con imágenes, JavaScript, fuentes, componentes, integraciones y contenido.
Una base ligera ayuda, pero el trabajo continúa: tamaños de imagen, carga diferida, fuentes, scripts de terceros, caché y estabilidad visual siguen siendo decisiones de implementación. El objetivo debe ser una experiencia rápida y estable, no perseguir una puntuación aislada.
Ventajas y desventajas de ChatGPT Sites
Ventajas
- reduce mucho el tiempo entre una idea y una experiencia funcional;
- permite iterar sobre código, diseño y contenido en un mismo flujo;
- puede evolucionar prototipos hacia producción;
- admite dominios, datos persistentes e integraciones según el proyecto;
- resulta atractivo para equipos y agencias capaces de resolver las capas técnicas.
Limitaciones actuales
- producto en beta y condiciones económicas cambiantes;
- rollout, región y permisos del workspace condicionan el acceso;
- límites compartidos entre Work, Codex y Sites según el plan;
- operaciones complejas pueden requerir bastante procesamiento;
- formularios y correo necesitan integración y pruebas reales;
- DNS, www, redirecciones y correo siguen siendo responsabilidad del proyecto;
- el control y la operación difieren del hosting tradicional;
- la plataforma y sus capacidades seguirán evolucionando.
¿Para quién tiene sentido ChatGPT Sites?
Muy interesante para:
- webs corporativas y de servicios profesionales;
- landings y proyectos rápidos;
- prototipos que deben evolucionar a producción;
- ecosistemas multisitio dentro de límites razonables;
- agencias técnicamente preparadas para DNS, SEO, datos e integraciones.
Conviene evaluar con más cuidado para:
- backends muy específicos;
- sistemas con requisitos regulatorios complejos;
- arquitecturas privadas altamente especializadas;
- modelos cuya rentabilidad depende de precios futuros no confirmados.
Checklist para publicar un ChatGPT Site profesional
- dominio principal conectado y respondiendo HTTP 200;
- www con redirección 301 permanente y conservación de rutas;
- canonical coherente en todas las páginas;
- robots y meta robots adecuados al entorno;
- sitemap accesible, canónico y sin fechas inválidas;
lastmoden formato W3C y basado en cambios reales;- Search Console verificada e inspección de URLs clave;
- Schema validado: Organization, sedes, redes, WebSite, BlogPosting y BreadcrumbList;
- URLs históricas preservadas o redirigidas con mapa explícito;
- responsive, teclado, contraste y estados de foco;
- PageSpeed y Core Web Vitals revisados con contenido real;
- formularios probados desde el navegador hasta el buzón;
- SPF y DKIM configurados cuando correspondan al remitente transaccional;
- privacidad, sanitización, rate limiting y protección de secretos;
- paginación rastreable y todos los posts enlazados;
- enlaces internos hacia servicios, hubs y recursos útiles;
- analytics y eventos de conversión verificados;
llms.txtconciso cuando aporte contexto;- versionado y rollback disponibles antes de cambios críticos.
Conclusión: de una web generada a un activo profesional
ChatGPT Sites reduce enormemente el esfuerzo de producción web, pero no elimina SEO, arquitectura, DNS, correo, integraciones, datos estructurados ni criterio profesional. La diferencia entre una web generada con IA y un activo digital profesional está en resolver correctamente todas esas capas.
Si estás evaluando la plataforma, consulta nuestra página sobre ChatGPT Sites para proyectos profesionales. También puedes revisar cómo trabajamos el diseño web y el diseño web con inteligencia artificial. La herramienta puede acelerar mucho el camino; la arquitectura y el criterio deciden si el resultado está preparado para crecer.
