Reconstruimos dailybot.com para la era de los agentes: de un CMS de edición visual a Astro

Durante la mayor parte de los últimos cinco años, dailybot.com vivió en un CMS de edición visual. A comienzos de 2026, la velocidad de la era de los agentes y los cambios constantes que hacíamos en el resto del stack lo estaban empezando a convertir en un cuello de botella. El proyecto que forzó la decisión ya estaba en el roadmap: un rebranding completo de Dailybot — nueva identidad visual, nueva escala tipográfica, nuevo espaciado, librería de componentes rediseñada — que iba a tocar cada página del sitio.

El problema no era el rendimiento. El problema era la velocidad. Cada otra superficie de la empresa había empezado a moverse a velocidad de agente: una propuesta de cambio escrita el lunes por la tarde podía estar en staging el martes por la mañana. El sitio de marketing se movía a velocidad de CMS: abrir el editor, encontrar la página, recordar las particularidades del bloque que estás editando, publicar, ver la errata, corregirla, volver a publicar. Una actualización al sistema de diseño que debía tomar un día terminaba tomando un trimestre. Una landing nueva para una funcionalidad que lanzábamos esa misma semana muchas veces era imposible.

Este post cuenta cómo movimos más de 700 páginas por idioma — inglés, español y portugués — a Astro, y por qué la combinación de un framework static-first con un ciclo de agentes nos dio una velocidad que no habríamos alcanzado con ninguno de los dos por separado.

Lo que teníamos antes

Nuestro sitio anterior estaba construido en Webflow. Nos sirvió durante cuatro años. Incorporamos a varias personas del equipo de marketing sin abrir un solo ticket de ingeniería; el editor visual era la forma más rápida para un equipo pequeño de ser dueño de su superficie pública, y el flujo de publicación era lo bastante limpio como para que nadie perdiera una tarde por un deploy roto.

Dejó de tener sentido cuando cambió la forma de nuestro trabajo, no porque la herramienta empeorara.

Por qué no podíamos quedarnos

Dos presiones se alinearon hacia fines de 2025.

El sitio creció más allá de la herramienta. dailybot.com se había vuelto una propiedad de contenido: artículos de blog extensos, una sección de academia, un help center, una galería de plantillas, páginas de integraciones, docs para developers — 16 tipos de página, cientos de páginas por idioma. Cada cambio estructural se multiplicaba sobre todas ellas. Un ajuste de layout que en nuestra app de producto era un cambio de CSS de cinco minutos, en el CMS era un ejercicio de varios días.

Y los agentes habían llegado — pero no podían editar un CMS no-code lo suficientemente rápido como para que valiera la pena. El cambio más consecuente fue cultural. En toda la empresa, el ritmo se había vuelto: pensar en voz alta con un agente, redactar, refinar, publicar. Nuestra plataforma de coordinación existe precisamente para que ese ritmo funcione a escala de equipo — ver nuestro post de lanzamiento de Dailybot 3. Pero nuestro sitio de marketing vivía en una superficie donde ese ritmo no aterrizaba. El editor estaba diseñado para una persona haciendo clic. Podríamos entrenar a un agente para que hiciera clic a través de un editor, pero no es ahí donde los agentes son productivos. Enseñarle a uno a redactar páginas controlando un navegador no es un flujo de trabajo; es pura fricción.

Intentamos quedarnos. Durante unas dos semanas reconstruimos el nuevo sistema de diseño dentro del CMS existente, página por página, para ver si podíamos sacar el rebranding sin cambiar de plataforma. El ritmo era incompatible con lo que necesitábamos. A esa velocidad, solo el rebranding se comía el trimestre, y el resto del sitio tenía que seguir moviéndose.

Por qué Astro, y por qué ahora

Una vez descartado quedarnos, evaluamos dos caminos: pasar a un CMS headless — uno que solo gestiona el contenido y lo expone por API — con un frontend propio, o pasar a un framework de sitios estáticos donde el contenido viva como archivos en el repositorio.

Ya había escrito el caso largo de por qué Astro — y por qué combinarlo con Svelte — en mi blog personal: Astro y Svelte: el futuro del desarrollo web. Ese post es el argumento completo de por qué Astro. Esta sección es la versión corta: las cuatro propiedades que pesaron para esta migración.

• Salida static-first. Las páginas de marketing son casi puramente estáticas. El comportamiento por defecto de Astro es renderizar HTML en build y no enviar JavaScript a menos que un componente lo pida. Para un sitio de contenido, ese es el default correcto.
• Islas para las partes que sí se mueven. Cuando una página realmente necesita interactividad — una calculadora de precios en vivo, una comparación interactiva, una pequeña demo animada — Astro nos permite insertar una isla dinámica desde cualquier framework moderno: React, Vue, Svelte. Elegimos Svelte. No pagamos por interactividad que no usamos.
• Content Collections. Un post de blog en Astro es un archivo: frontmatter, MDX, listo. Un esquema de Zod valida cada entrada en build. “¿Este post tiene hero image válida y fecha de publicación?” se convierte en un error de tipo, no en una sorpresa en producción.
• MDX cuando necesitamos composición. Para piezas largas — artículos de academia, análisis a fondo, historias del changelog — queríamos componentes reutilizables: callouts, citas destacadas, bloques antes/después. MDX nos deja componerlos sin salir del artículo.

La propiedad decisiva fue que Astro es un codebase. Un agente puede leerlo, ejecutarlo, extenderlo y abrir un pull request contra él igual que una persona ingeniera. Esa propiedad no es exclusiva de Astro, pero era la condición que nuestro flujo necesitaba. El CMS alojado no la tenía.

Dicho de otra forma: Astro sigue siendo un CMS para nosotros — uno donde el contenido vive como archivos, el esquema es tipado, y cada edición es un diff. No abandonamos la categoría. Cambiamos con qué tipo de CMS trabaja nuestro equipo.

Cómo fue la migración

Con eso descartado, corrimos la prueba de migración. Dedicamos un día con los agentes a portar la base del sistema de diseño, varias páginas principales, el blog y buena parte del contenido. Ese era el criterio de decisión: si migrar una sola página iba a tomar una semana, no íbamos a terminar el proyecto en un trimestre.

Todo eso entró en un solo día.

Un día más cerró la primera versión completa. Un ingeniero, Cursor y Claude Code, dos días. Aun así, quedaba mucho trabajo por delante, pero la estructura ya vivía en el codebase y el sitio renderizaba desde ahí.

La migración completa corrió durante seis semanas. Alcance en números:

• 16 tipos de página × 3 idiomas — alrededor de 700 páginas por idioma, más una versión markdown gemela de cada una para que los agentes puedan leer el sitio.
• El rebranding salió en la misma ventana — nueva identidad, nueva escala tipográfica, nuevo espaciado, nueva librería de componentes. Ejecutarlo por separado habría significado tocar cada página dos veces.
• El contenido no paró. El blog y la academia siguieron publicando en el sitio anterior hasta el día que lanzamos el nuevo.

Con la base montada, aún teníamos una montaña de trabajo por delante — y la mayor parte no era trabajo de ingeniería. Era copy que revisar en cientos de páginas, pulido de diseño contra el Figma, los triplets EN / ES / PT por completar, decisiones de visión sobre cada sección, un calendario de contenido que tenía que seguir publicando.

Ese tipo de trabajo tradicionalmente necesita feedback y ediciones del lado no-técnico del equipo: producto, diseño, growth. Y ese handoff — el momento en que el equipo no-técnico tiene que volver a ingeniería para que alguien aterrice sus cambios — suele ser donde proyectos como este se atascan. Nosotros lo resolvimos por el lado opuesto: pusimos a los agentes en el medio.

Entre las personas que son dueñas del contenido — nuestra product manager, nuestra diseñadora y nuestro growth lead — y el codebase. Dos horas de onboarding: una sesión corta sobre fundamentos de git, cómo funciona Cursor, y cómo darle a un agente una instrucción que realmente aterrice; luego ayudamos a cada persona a configurar su entorno local.

Ese entorno era Cursor — y ahí es donde su navegador integrado dejó de ser una feature de ingeniería y se volvió, literalmente, el editor visual del sitio. Abres la vista previa en vivo al lado del editor, usas el inspector para apuntar a un elemento específico, y le dices al agente qué cambiar. Esa idea de antes — “Astro sigue siendo un CMS” — dejó de ser un replanteo abstracto: Cursor era el editor visual, debajo de cada clic estaba el codebase real, y cada edición era un diff.

Al día siguiente los tres estaban abriendo pull requests: pantallas nuevas, ediciones de copy, ajustes de layout, páginas enteras nuevas. En una semana se movían más rápido de lo que ninguno de nosotros esperaba. Y la sorpresa real no fue la velocidad — fue verlos desbloquear habilidades que no sabían que tenían. No aprendieron a programar. Aprendieron a trabajar con agentes, y el agente traducía cada instrucción al diff correspondiente.

Un año atrás, nada de esto habría sido posible. Enseñar a una product manager, a una diseñadora o a un growth lead a publicar desde un repo de git no era un onboarding de dos horas; era la razón por la que tantos equipos quedan atrapados en CMS visuales para siempre.

Ese fue el desbloqueo real. No reemplazamos el CMS alojado con un editor mejor. Lo reemplazamos con un codebase contra el que las personas no-ingenieras podían operar, porque un agente se sentaba en el medio y hacía la traducción. Sin agentes capaces de hacer esa traducción, no habríamos intentado esta migración. Con ellos, la superficie de trabajo de todo el equipo cambió — no solo la de ingeniería.

Una decisión que volveríamos a tomar: reconstruir, no portar. Traducir el sitio componente por componente habría preservado decisiones que ya queríamos revisar. Conservamos las URLs y el contenido; reconstruimos todo lo demás.

Y un detalle que vale la pena subrayar para cualquier equipo que considere este camino: el mes lento que suele acompañar a migraciones como esta no apareció. Desde el primer post, escribirlo como markdown fue más rápido que hacerlo en el editor visual anterior — pasamos el borrador al agente y devuelve el triplet EN / ES / PT listo para revisar. Para la quinta semana, un post nuevo iba de idea a publicado en inglés, español y portugués en menos tiempo del que antes nos tomaba conseguir la primera aprobación dentro del CMS.

El resultado

dailybot.com hoy marca 100 limpio en Lighthouse, tanto en desktop como en móvil, en las cuatro categorías: rendimiento, accesibilidad, mejores prácticas y SEO. Un build completo corre en alrededor de 100 segundos en nuestro CI.

El 100 en móvil es el que más trabajo cuesta sostener. Si alguien abre Lighthouse dentro de un mes y ve 95 en performance móvil, eso sigue siendo un sitio rápido — el número que importa no es el pico, es el piso.

La historia de despliegue es parte de cómo se sostienen esos puntajes. Cada commit dispara un build de Astro y, segundos después, Cloudflare Pages publica el sitio en su edge global. Producción y cada preview de PR viven en la misma infraestructura, así que cualquier persona del equipo — técnica o no — puede abrir el link de preview y revisar un cambio en vivo antes de mergear. Esa sola propiedad fue la que transformó el flujo no-técnico de “abrir un PR y esperar a un ingeniero” a “abrir un PR y pingear al reviewer”.

Debajo de ese flujo está la red de seguridad que nos permite confiar en él. Cada PR pasa por el pipeline completo antes de poder mergear: chequeos de TypeScript, lint y formato con Biome, la suite de tests con Vitest, una corrida de Lighthouse CI que sostiene el piso de puntaje en rendimiento, accesibilidad, mejores prácticas y SEO, y un build limpio de producción. Un tipo roto, una clave de traducción faltante, una regresión en un esquema de contenido o un script bloqueante que se haya colado en un layout se detecta en CI, no en el sitio en vivo. Eso es lo que nos deja entregar las llaves a no-ingenieros sin que se sienta imprudente — lo peor que puede hacer un PR malo es fallar un check y pedir una corrección.

El número que nos importa más está más abajo en el stack. El tiempo entre “deberíamos publicar X” y “X está en vivo en tres idiomas” solía medirse en días. Hoy se mide en minutos para cambios rutinarios, y en una sesión de trabajo para tipos de página nuevos.

Construido para la web de los agentes

El segundo puntaje que nos importa es más reciente. Lighthouse mide si las personas y los buscadores pueden cargar el sitio. Un scorecard distinto — isitagentready.com — mide si los agentes de IA pueden trabajar con él de verdad. Es una propuesta abierta de Cloudflare para esta nueva era, armada sobre estándares emergentes hacia los que toda la industria está convergiendo. Puedes leer más sobre esto en AEO: De Invisible a Citado.

dailybot.com hoy marca un 100 / 100 limpio ahí también, con cada categoría en su máximo — Discoverability, Content, Bot Access Control, y API, Auth, MCP & Skill Discovery. Nivel 5: Agent-Native.

Cuatro cosas concretas componen ese puntaje:

• Política de IA pública. Una línea en robots.txt declara tres síes explícitos: sí al entrenamiento, sí a la indexación por buscadores, sí a citas en respuestas de IA. Para un sitio de marketing que existe para ser encontrado, cualquier otra cosa sería trabajar en contra.

• Un mapa del sitio. Un pequeño conjunto de direcciones públicas apunta a nuestro catálogo de APIs, a nuestra historia de autenticación y a las capacidades que soportamos. Como un hotel que pone sus servicios en una tarjeta junto a la puerta en vez de esconderlos en un cajón.

• Cada página también está disponible como markdown limpio. Basta con solicitar cualquier URL con el encabezado Accept: text/markdown — o añadir .md al final de la ruta — para recibir markdown plano en lugar de HTML: el formato que los agentes de IA consumen con mayor facilidad. Dos vías equivalentes para acceder a este mismo post:

  curl -H 'Accept: text/markdown' https://www.dailybot.com/es/blog/how-we-migrated-dailybot-to-astro/
  curl https://www.dailybot.com/es/blog/how-we-migrated-dailybot-to-astro.md

• Herramientas que usan desde su propio navegador. Un pequeño puente registra acciones de solo lectura — buscar en el blog, encontrar un artículo del help center — a través de un estándar abierto emergente. Los navegadores con soporte de agentes las toman automáticamente.

Nada de esto es visible para una persona navegando el sitio. Todo es visible para un agente. Ese es el punto: el equipo que mueve nuestra superficie pública ahora incluye agentes, y el sitio habla su idioma.

Entre los dos scorecards, dailybot.com marca verde en todo lo que importa en la web moderna: rendimiento, accesibilidad, SEO, contenido y AEO, todo al mismo tiempo. La mayor parte vino de la mano de Astro, por diseño; el resto fueron un puñado de piezas deliberadas que encajaron con naturalidad porque el código estaba preparado para recibirlas. El sitio habla el idioma hacia el que se mueve la web sin renunciar al idioma que la web ya habla. Listo para la era de los agentes, sobre una base que ya era sólida para todo lo demás.

Lo que se volvió posible

Los números de rendimiento son la parte fácil de una historia de migración. La parte que vale la pena escribir es el trabajo que la estructura de costos anterior impedía.

Publicamos posts de blog el mismo día en que los escribimos. Levantamos una categoría entera — una nueva galería de assets interactivos, un nuevo pilar de academia — en una tarde e iteramos sobre ella en vivo. Reemplazamos capturas estáticas del producto con pequeños assets interactivos basados en Svelte que el lector puede usar de verdad. Los agentes que nos ayudan a redactar, traducir y revisar trabajan contra los mismos archivos que nuestros ingenieros. Ya no existe un “flujo del sitio de marketing” aparte que haya que enseñarles.

dailybot.com hoy se publica en inglés, español y portugués desde un único repositorio. Cada post, página y artículo del help center se escribe como un archivo por idioma, se valida contra un esquema de contenido tipado y se cruza en build — la paridad es un error de compilación, no una preocupación del ciclo de revisión. Agregar un cuarto idioma es un día de ingeniería y una cola de trabajo de traducción; no es un proyecto que tengamos que agendar alrededor del roadmap de un proveedor.

Para un equipo de nuestro tamaño — lo bastante pequeño para sentir cada ineficiencia, lo bastante grande para que el trabajo sobre superficies públicas sea constante — ese es el punto completo.

Lo que le diríamos a otro equipo

• El cuello de botella no es el editor. Es el ritmo. Decidan si su sitio de marketing es una propiedad de contenido o un producto, y elijan un sistema que encaje.
• Su equipo no-técnico ya puede publicar en la superficie pública. Planeen alrededor de eso. Hace un año, mover el sitio de marketing a un repo significaba empujar el trabajo de contenido de vuelta a ingeniería o construir un editor visual encima. Ninguna de las dos es necesaria hoy, si la herramienta de código y la superficie de diseño/preview son la misma cosa. No estamos enseñándole a nuestro equipo a programar; les estamos enseñando a darle instrucciones a un agente.
• Reconstruir, no portar. La traducción componente a componente conserva decisiones que no quieren conservar. Si la migración vale la pena, inviertan la semana extra en un rediseño real dentro de la misma ventana.
• Hagan del i18n una propiedad del sistema, no un proceso manual. Content Collections de Astro con un esquema tipado por idioma convirtieron “¿están los tres idiomas sincronizados?” de una hoja de cálculo a un error de build. Eso solo ya pagó el costo de la migración.
• El CMS de edición visual que teníamos sigue siendo excelente. Pero si quieren moverse a la velocidad de la nueva era de la IA, ya no es suficiente.

El verdadero entregable

Lo que cambió no es nuestro sitio: es quién puede moverlo. Antes de esta migración, cualquier cambio en dailybot.com pasaba por ingeniería. Hoy nuestro PM, nuestra diseñadora y nuestro lead de growth abren PRs todos los días. La métrica que más nos importa no es Lighthouse ni el tiempo de build — es cuántas personas del equipo pueden empujar la superficie pública hacia adelante un martes cualquiera.

Esa es la migración que importa, y la única razón por la que la pudimos hacer es que los agentes llegaron. Sin ellos, esta historia no existiría: el editor visual seguiría siendo el camino más corto. Con ellos, el camino más corto pasó a ser un repo donde todo el equipo puede operar — porque el agente traduce.

Si tu equipo está donde estábamos a finales de 2025, la decisión no es realmente sobre Astro, ni sobre Webflow, ni sobre ningún stack en particular. Es sobre quién quieres que mueva tu superficie pública dentro de un año. Nuestra respuesta fue: todo el equipo. Eso cambió la forma en que trabajamos más de lo que cualquier elección de plataforma podría haberlo hecho.