Crear y desplegar un sitio con IA

Antes, en Migrar una página estática con IA, vimos el proceso de migrar una página estática ya creada a un servicio basado en contenido gestionado por WEEGLOO. Esta vez abarcamos un flujo más amplio, incluyendo la fase de crear la página desde cero.

En esta guía aprovechamos un agente LLM y WEEGLOO MCP para partir de cero y realizar cinco tareas en orden. Primero completamos el diseño y la implementación de la página con una herramienta de diseño basada en IA; a continuación analizamos la página generada para definir automáticamente los Content Type y después cargamos como Content los datos que estaban escritos en la página. Luego modificamos el código para que la página obtenga los datos a través de CDA y, por último, publicamos la página al exterior con el Web Hosting de WEEGLOO.

Al recorrer este proceso, puede completar todo el recorrido (desde el diseño hasta la gestión de contenido y el despliegue) únicamente con un agente LLM y WEEGLOO, sin tener que construir usted mismo ninguna infraestructura aparte.

Requisitos previos

Antes de empezar, debe tener preparadas tres cosas.

Primero, debe existir un nuevo Space creado y vacío en WEEGLOO. Tanto los Content Type como los Content que va a crear se gestionarán dentro de este Space. Los detalles sobre Organization y Space se tratan en Acceso y permisos.

Segundo, el agente LLM debe estar conectado a WEEGLOO MCP. Esta guía se desarrolla tomando como referencia Cursor IDE, pero puede seguir el mismo flujo en cualquier entorno que admita MCP, como Claude Desktop. El método de instalación se trata en MCP.

Tercero, necesita una herramienta de IA que cree automáticamente el diseño y la implementación de la página. Por comodidad, esta guía usa Vercel v0, pero sirve cualquier herramienta que cree el diseño y el código a la vez solo con peticiones en lenguaje natural, como Lovable o Bolt.new. Si está más acostumbrado a un entorno donde escribe el código directamente, también puede pedir el diseño y la implementación a un agente LLM de uso habitual como Cursor IDE.

Diseño e implementación de la página

Lo primero que hay que hacer es completar el diseño y la implementación de la página. En esta fase resume en lenguaje natural qué página quiere crear y se lo transmite tal cual a la herramienta de IA.

En esta guía usamos como ejemplo una página de documentación de API para un servicio de API de análisis ficticio. Muchos equipos de desarrollo adoptan una herramienta de documentación aparte o una plantilla externa para mantener la documentación de su API, pero en este enfoque la forma y el contenido de la documentación suelen estar fuertemente acoplados, lo que dificulta cambiar la estructura con libertad o adaptar la operación al flujo del equipo. Esta vez construiremos nosotros mismos todo el proceso, desde el diseño hasta la gestión de contenido, para darle una forma que se pueda operar con libertad según las necesidades.

La página incluye información sobre la propia API (nombre, eslogan, breve introducción) junto con información sobre cada endpoint (método HTTP, ruta, resumen, descripción). La forma concreta de la página o el número de endpoints que abarca se pueden decidir con libertad según la API que opere, y se pueden ampliar cuanto haga falta sobre la marcha. Estos requisitos se transmiten a la herramienta de IA expresados en lenguaje natural de la siguiente manera.

Hey, I want to build a docs site for an analytics API called Pulse.
Standard API reference layout — an overview area with the API's name,
tagline, and a short intro, plus an endpoint reference section showing
the HTTP method, path, summary, and description for each. Clean,
dev-friendly, not too colorful — think Stripe-style readable.

La herramienta de IA que recibe la petición crea una propuesta de diseño y, acorde con ella, escribe también el marcado y los estilos correspondientes. En este punto todavía no hay conectado un sistema de gestión de contenido, así que todos los datos que se ven en la página están escritos directamente dentro del código.

Descargue el código de la página así creada y llévelo a un entorno de agente LLM como Cursor IDE. Todo el trabajo posterior se realiza sobre este código y atraviesa las mismas fases que el flujo visto en Migrar una página estática con IA.

Modelado de contenido

En esta fase se define como Content Type la estructura de datos de la página generada antes. Un Content Type es como el plano de los datos: define de antemano qué Field tendrán los datos que se gestionarán en WEEGLOO.

Si observa el código de la página, la información sobre la propia API y la información sobre cada endpoint están juntas, y los dos tipos de datos forman una relación de uno a muchos. Por eso esta página se divide de forma natural en dos: un Content Type que contiene la información de la API y un Content Type que contiene la información de los endpoints.

Este análisis y la creación de los Content Type se realizan automáticamente con solo pedírselo al agente LLM de la siguiente manera.

Hey, I just dropped the page from v0 into the project.
The data's all hardcoded for now (the API info up top, the endpoints down
below).
 
I want to migrate it over to Weegloo so the page can pull its content from
a CMS instead of having it all baked in. Let's take it step by step rather
than doing the whole thing in one go.
 
To kick things off, could you take a look and figure out
what content types would make sense for it, then go ahead and create them
in Weegloo? We'll deal with the actual content and the API wiring in the
following steps.

El agente LLM que recibe la petición examina la estructura del código para inferir los tipos de datos y sus relaciones, decide el tipo adecuado para cada Field y luego crea los Content Type mediante WEEGLOO MCP.

Cuando termina el trabajo, si abre la página de Content Type del estudio de contenidos de WEEGLOO verá que se han creado dos Content Type nuevos: uno que representa la API y otro que representa los endpoints. El Content Type de la API incluye Field como nombre, eslogan e introducción, y el Content Type de los endpoints incluye método HTTP, ruta, resumen y descripción, junto con un Field de referencia (Reference) que indica a qué API pertenece.

Una vez definidos así los Content Type, queda todo listo para cargar los datos reales sobre esa estructura. Los detalles sobre los Content Type se tratan en Modelado de Content.

Creación de contenido

Los Content Type solo definen el formato de los datos; en sí mismos no contienen datos. En esta fase, partiendo de los Content Type definidos antes, trasladamos a Content los datos reales que estaban escritos en el código de la página.

Si le pide al agente LLM lo siguiente, este analiza los datos del código, crea los Content acordes con los Content Type y se encarga también de publicarlos.

Alright, the content types look good. Now let's move on to actually loading
the data.
 
Could you go through project again, pull out the actual content
that's hardcoded in there, and create entries in Weegloo using the content
types we just made? Once everything's in, go ahead and publish them too
so they're ready to be served.

El agente LLM que recibe la petición vuelve a analizar el código, separa los datos por elementos y luego registra en orden, mediante WEEGLOO MCP, la información de la API y la de cada endpoint. Los Content registrados se publican a la vez para que se puedan consultar desde el exterior.

Cuando termina el trabajo, si abre la lista de Content del estudio de contenidos de WEEGLOO verá que tanto la información de la API como la de los endpoints están registradas y publicadas. A partir de este momento, sin modificar directamente el código de la página, puede cambiar los datos con libertad desdel estudio de contenidos o con el agente LLM.

Los detalles sobre la redacción y publicación de Content se tratan en Redacción y publicación de Content.

Integración con CDA

Si ya tiene listos también los datos, esta vez modificamos el código para que la página, en lugar de usar los datos escritos directamente en el código, obtenga los datos a través de CDA de WEEGLOO. CDA es una API de solo lectura que se ofrece para consultar los Content publicados desde servicios externos, y permite que una página web o una aplicación móvil traiga y use directamente los datos de WEEGLOO.

Este trabajo también se realiza automáticamente si le pide al agente LLM lo siguiente.

Okay, almost there. The content's all in Weegloo and published, so now
let's hook the page up to actually use it.
 
Could you update project so that instead of having all that data
hardcoded in the markup, it fetches from Weegloo's CDA on load and
renders the page from the response? Basically the same page as before,
just pulling from the API now.

El agente LLM que recibe la petición retira los datos estáticos incrustados en el código y, en su lugar, rellena el código que aplica a la pantalla las llamadas a CDA y los datos de respuesta. Donde estaba la información de los endpoints entra una llamada a CDA que consulta la lista de Content de endpoints, y donde estaba la información de la API entra una llamada que consulta de forma individual el Content de la API.

Si ejecuta en local la página modificada y abre la pestaña Network de las herramientas para desarrolladores del navegador, podrá comprobar que, al cargar la página, se envían peticiones reales a CDA de WEEGLOO y llegan las respuestas. Los detalles sobre CDA se tratan en Content Delivery API.

Alojamiento web

La última fase consiste en publicar al exterior la página creada hasta ahora. WEEGLOO ofrece la función Web Hosting para poder alojar la página directamente. Gracias a ella, puede publicar la página terminada en un estado accesible para cualquiera sin tener que montar usted mismo una infraestructura de alojamiento aparte.

Pídale al agente LLM lo siguiente.

Last thing — let's get this live.
 
Could you set up a WebHosting in Weegloo for this project and deploy the
page to it?

El agente LLM que recibe la petición sube el resultado de la compilación de la página a Web Hosting y despliega la página para que sea accesible desde el exterior a través de un subdominio que se emite automáticamente.

Una vez terminado el despliegue, puede acceder a la página desde cualquier lugar mediante la dirección del subdominio emitido. A partir de este momento, basta con modificar los Content en el estudio de contenidos de WEEGLOO para que los cambios se reflejen de inmediato en el sitio en vivo, sin necesidad de compilar ni volver a desplegar aparte. Tareas que ocurren con frecuencia al operar documentación de API, como añadir un nuevo endpoint o cambiar la descripción de uno existente, también se pueden gestionar sin tocar el código.

Si más adelante, durante la operación, quiere usar su propio dominio, puede conectar un Custom Domain desdel estudio de contenidos de WEEGLOO. Los detalles sobre Web Hosting y Custom Domain se tratan en Despliegue de un sitio web.

Hasta aquí hemos completado, partiendo de cero, todo el recorrido (diseño e implementación, gestión de contenido y despliegue) únicamente con un agente LLM y WEEGLOO. El mismo flujo se puede aplicar tal cual a sitios más complejos, y tareas como añadir nuevos Content Type o aumentar la cantidad de Content durante la operación también se pueden enlazar de forma natural de la misma manera.