Reconstruímos o dailybot.com para a era dos agentes: de um CMS de edição visual para Astro

Durante quase todos os últimos cinco anos, o dailybot.com viveu em um CMS de edição visual. No início de 2026, a velocidade da era dos agentes e as mudanças constantes que fazíamos no resto do stack estavam começando a transformá-lo em um gargalo. O projeto que forçou a decisão já estava no roadmap: um rebranding completo do Dailybot — nova identidade visual, nova escala tipográfica, novo espaçamento, biblioteca de componentes redesenhada — que iria tocar cada página do site.

O gargalo não era desempenho. Era velocidade. Todas as outras superfícies da empresa haviam começado a se mover no ritmo dos agentes — uma proposta de mudança de produto escrita na tarde de segunda chegava a staging na manhã de terça. O site de marketing se movia no ritmo do CMS: abrir o editor, encontrar a página, lembrar dos detalhes do bloco que estava sendo editado, publicar, ver o typo, corrigir, publicar de novo. Uma atualização do design system que deveria levar um dia levava um trimestre. Uma landing page nova para uma funcionalidade que lançávamos na mesma semana era, muitas vezes, impossível.

Este post é a história de como movemos mais de 700 páginas por idioma — inglês, espanhol e português — para o Astro, e por que a combinação de um framework estático com um ciclo de agentes gerou uma velocidade que nenhuma das partes teria alcançado sozinha.

O que tínhamos antes

Nosso site anterior foi construído no Webflow. Nos atendeu bem por quatro anos. Integramos várias contratações de marketing nele sem abrir um único ticket de engenharia; o editor visual era a forma mais rápida de um time pequeno manter sua superfície pública, e a história de publicação era limpa o bastante para que ninguém perdesse uma tarde por causa de um deploy quebrado.

Deixou de caber quando a forma do nosso trabalho mudou, não porque a ferramenta tenha piorado.

Por que não dava para ficar

Duas pressões se alinharam até o final de 2025.

O site cresceu para além da ferramenta. O dailybot.com havia se tornado uma propriedade de conteúdo: posts longos de blog, uma seção de academia, um centro de ajuda, uma galeria de templates, páginas de integrações, docs para desenvolvedores — 16 tipos de página, centenas de páginas por idioma. Cada mudança estrutural se multiplicava por todas elas. Um ajuste de layout que era uma alteração de CSS de cinco minutos no nosso app de produto virava um exercício de vários dias no CMS.

E os agentes chegaram — mas não conseguiam editar um CMS no-code rápido o suficiente para valer a pena. A mudança mais consequente foi cultural. Dentro da empresa, o ritmo passou a ser: pensar em voz alta com um agente, rascunhar, refinar, entregar. Nossa plataforma de coordenação existe justamente para fazer esse ritmo funcionar em escala de time — veja nosso post de lançamento do Dailybot 3. Mas o nosso site de marketing morava em uma superfície onde esse ritmo não pousava. O editor foi desenhado para uma pessoa clicando. Daria para treinar um agente para clicar por um editor, mas não é aí que agentes são produtivos. Ensinar um deles a editar páginas controlando um navegador não é um fluxo de trabalho; é pura fricção.

Tentamos ficar. Por umas duas semanas reconstruímos o novo design system dentro do CMS existente, página por página, para ver se conseguíamos entregar o rebranding sem trocar de plataforma. O ritmo era incompatível com o que precisávamos. Nesse passo, só o rebranding consumiria o trimestre, e o resto do site ainda precisava continuar avançando.

Por que Astro, e por que agora

Uma vez descartado ficar, avaliamos dois caminhos: migrar para um CMS headless — um CMS que só gerencia o conteúdo e o expõe via API — com frontend customizado, ou migrar para um framework de site estático com o conteúdo morando como arquivos no repositório.

Eu já tinha escrito o caso longo de por que Astro — e por que combiná-lo com Svelte — no meu blog pessoal: Astro and Svelte: the future of web development. Esse post é o argumento completo de por que Astro. Esta seção é a versão curta: as quatro propriedades que pesaram para esta migração.

• Saída estática por padrão. Páginas de marketing são quase puramente estáticas. O default do Astro é renderizar HTML em build e entregar zero JavaScript, a menos que um componente peça. Para um site de conteúdo, esse é o default certo.
• Ilhas para o que precisa se mover. Quando uma página realmente precisa de interatividade — uma calculadora de preços ao vivo, uma comparação interativa, uma pequena demo animada — o Astro nos deixa inserir uma ilha dinâmica de qualquer framework moderno: React, Vue, Svelte. Escolhemos Svelte. Não pagamos por interatividade que não usamos.
• Content Collections. Um post de blog no Astro é um arquivo: frontmatter, MDX, pronto. Um schema Zod valida cada entrada em build. “Esse post tem uma hero image válida e uma data de publicação?” vira um erro de tipo, não uma surpresa em runtime.
• MDX quando precisamos compor. Para peças longas — artigos de academia, deep-dives, histórias de changelog — queríamos componentes reutilizáveis como callouts, pull-quotes e blocos de antes e depois. MDX permite compor sem sair do artigo.

A propriedade decisiva foi que Astro é uma base de código. Um agente consegue ler, rodar, estender e abrir um pull request contra ela do mesmo jeito que um engenheiro humano. Essa propriedade não é exclusiva do Astro, mas era a condição que nosso fluxo precisava. O CMS hospedado não tinha.

Em outras palavras: o Astro continua sendo um CMS para nós — um em que o conteúdo mora como arquivos, o schema é tipado, e cada edição é um diff. Não saímos da categoria. Trocamos que tipo de CMS a equipe usa no dia a dia.

Como foi a migração

Com isso descartado, rodamos o teste de migração. Passamos um dia com os agentes portando a base do sistema de design, várias páginas principais, o blog e boa parte do conteúdo. Esse era o critério de decisão: se migrar uma única página fosse levar uma semana, não íamos entregar o projeto no trimestre.

Tudo isso entrou em um único dia.

Mais um dia fechou a primeira versão completa. Um engenheiro, Cursor e Claude Code, dois dias. Ainda assim, havia muito trabalho pela frente, mas o esqueleto já vivia no codebase e o site renderizava de lá.

A migração completa rodou durante seis semanas. Escopo em números:

• 16 tipos de página × 3 idiomas — cerca de 700 páginas por idioma, mais uma versão markdown gêmea de cada uma para que os agentes possam ler o site.
• O rebranding saiu na mesma janela — nova identidade, nova escala tipográfica, novo espaçamento, nova biblioteca de componentes. Executá-lo separadamente teria significado tocar cada página duas vezes.
• O conteúdo não parou. O blog e a academia continuaram publicando no site antigo até o dia em que lançamos o novo.

Com a base pronta, ainda tínhamos uma montanha de trabalho pela frente — e a maior parte não era trabalho de engenharia. Era copy para revisar em centenas de páginas, polimento de design contra o Figma, os triplets EN / ES / PT para completar, decisões de visão sobre cada seção, um calendário de conteúdo que precisava continuar publicando.

Esse tipo de trabalho tradicionalmente precisa de feedback e edições do lado não-técnico do time: produto, design, growth. E esse handoff — o momento em que o time não-técnico precisa voltar para engenharia pedindo mudanças — é onde projetos como este geralmente travam. Nós resolvemos pelo lado oposto: colocamos os agentes no meio.

Entre as pessoas que são donas do conteúdo — nossa product manager, nossa designer e nosso growth lead — e o codebase. Duas horas de onboarding: uma sessão curta sobre fundamentos de git, sobre como o Cursor funciona, e sobre como dar a um agente uma instrução que realmente aterrisse; depois ajudamos cada pessoa a configurar o ambiente local.

Esse ambiente era o Cursor — e é aí que o navegador integrado dele deixou de ser uma feature de engenharia e virou, literalmente, o editor visual do site. Você abre a visualização ao vivo ao lado do editor, usa o inspetor para apontar um elemento específico, e diz ao agente o que mudar. Aquela ideia de antes — “Astro continua sendo um CMS” — deixou de ser um reenquadramento abstrato: Cursor era o editor visual, debaixo de cada clique estava o codebase real, e cada edição era um diff.

No dia seguinte os três estavam abrindo pull requests: telas novas, edições de copy, ajustes de layout, páginas inteiras novas. Em uma semana estavam se movendo mais rápido do que qualquer um de nós esperava. E a surpresa real não foi a velocidade — foi vê-los desbloquear habilidades que nem sabiam que tinham. Eles não aprenderam a programar. Aprenderam a trabalhar com agentes, e o agente traduzia cada instrução no diff correspondente.

Um ano atrás, nada disso teria sido possível. Ensinar uma product manager, uma designer ou um growth lead a publicar através de um repositório git não era um onboarding de duas horas; era a razão pela qual tantos times ficam presos em CMS visuais para sempre.

Esse foi o desbloqueio real. Não substituímos o CMS hospedado por um editor melhor. Substituímos por um codebase contra o qual pessoas não-engenheiras podiam operar, porque um agente se sentava no meio e fazia a tradução. Sem agentes capazes de fazer essa tradução, não teríamos tentado essa migração. Com eles, a superfície de trabalho de todo o time mudou — não só a de engenharia.

Uma decisão que tomaríamos de novo: reconstruir, não portar. Uma tradução componente por componente teria preservado escolhas que já queríamos revisitar. Mantivemos as URLs e o conteúdo; reconstruímos o resto.

E um detalhe que vale a pena deixar explícito para qualquer time que considere este caminho: o mês lento que costuma acompanhar uma migração como essa não apareceu. Desde o primeiro post, escrevê-lo como markdown foi mais rápido do que fazê-lo no editor visual anterior — você passa o rascunho para o agente e ele devolve o triplet EN / ES / PT pronto para revisão. Na quinta semana, um post novo saía da ideia até publicado em inglês, espanhol e português em menos tempo do que antes levávamos só para fechar a primeira aprovação no CMS antigo.

O resultado

O dailybot.com hoje marca 100 cravados no Lighthouse — tanto em desktop quanto em mobile — em todas as categorias: performance, acessibilidade, boas práticas e SEO. Um build completo roda em cerca de 100 segundos na nossa CI.

O 100 em mobile é o que dá mais trabalho para sustentar. Se alguém abrir o Lighthouse daqui a um mês e vir 95 em performance mobile, ainda é um site rápido — o número que importa não é o teto, é o piso.

A história do deploy é parte de como esses scores se sustentam. Cada commit dispara um build do Astro e, segundos depois, o Cloudflare Pages publica o site no seu edge global. Produção e cada preview de PR vivem na mesma infraestrutura, então qualquer pessoa do time — técnica ou não — pode abrir o link de preview e revisar uma mudança ao vivo antes de mergear. Essa única propriedade foi o que transformou o fluxo não-técnico de “abrir um PR e esperar um engenheiro” para “abrir um PR e pingar o reviewer”.

Por baixo desse fluxo está a rede de segurança que nos permite confiar nele. Cada PR passa pelo pipeline completo antes de poder mergear: checks de TypeScript, lint e formatação com Biome, a suíte de testes do Vitest, uma rodada de Lighthouse CI que sustenta o piso de pontuação em performance, acessibilidade, boas práticas e SEO, e um build limpo de produção. Um tipo quebrado, uma chave de tradução faltando, uma regressão num schema de conteúdo ou um script bloqueante que tenha entrado num layout é pego no CI, não no site no ar. Isso é o que nos deixa entregar as chaves para não-engenheiros sem que pareça imprudente — o pior que um PR ruim pode fazer é falhar um check e pedir um ajuste.

O número que mais nos importa está mais embaixo na pilha. O tempo entre “deveríamos publicar X” e “X está no ar em três idiomas” era medido em dias. Hoje é medido em minutos para mudanças de rotina, e em uma única sessão de trabalho para novos tipos de página.

Construído para a web dos agentes

A segunda pontuação que nos importa é mais recente. O Lighthouse mede se as pessoas e os buscadores conseguem carregar o site. Um scorecard diferente — isitagentready.com — mede se os agentes de IA conseguem de fato trabalhar com ele. É uma proposta aberta da Cloudflare para esta nova era, montada sobre padrões emergentes para os quais toda a indústria está convergindo. Você pode ler mais sobre isso em AEO: De Invisível a Citado.

O dailybot.com hoje marca um 100 / 100 cravado lá também, com cada categoria no máximo — Discoverability, Content, Bot Access Control e API, Auth, MCP & Skill Discovery. Nível 5: Agent-Native.

Quatro coisas concretas compõem essa pontuação:

• Política de IA pública. Uma linha no robots.txt declara três sins explícitos: sim ao treino, sim à indexação por buscadores, sim a citações em respostas de IA. Para um site de marketing que existe para ser encontrado, qualquer outra coisa seria trabalhar contra a gente.

• Um mapa do site. Um pequeno conjunto de endereços públicos aponta para nosso catálogo de APIs, nossa história de autenticação e as capacidades que suportamos. Como um hotel que deixa seus serviços num cartão junto da porta em vez de esconder numa gaveta.

• Toda página também está disponível como markdown limpo. Basta solicitar qualquer URL com o cabeçalho Accept: text/markdown — ou adicionar .md ao final da rota — para receber markdown puro em vez de HTML: o formato que os agentes de IA consomem com maior facilidade. Duas formas equivalentes de acessar este mesmo post:

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

• Ferramentas usáveis direto do navegador deles. Uma ponte pequena registra ações somente-leitura — buscar no blog, encontrar um artigo da central de ajuda — através de um padrão aberto emergente. Navegadores com suporte a agentes as pegam automaticamente.

Nada disso é visível para uma pessoa navegando o site. Tudo é visível para um agente. É esse o ponto: o time que move nossa superfície pública agora inclui agentes, e o site fala a língua deles.

Entre os dois scorecards, o dailybot.com marca verde em tudo o que importa na web moderna: performance, acessibilidade, SEO, conteúdo e AEO, tudo ao mesmo tempo. A maior parte veio pronta com o Astro, por design; o resto foram algumas peças deliberadas que se encaixaram com naturalidade porque a base de código estava pronta para recebê-las. O site fala a língua para a qual a web está indo sem abrir mão da língua que a web já fala. Pronto para a era dos agentes, sobre uma fundação que já era sólida para todo o resto.

O que se tornou possível

Números de performance são a parte fácil de uma história de migração. A parte que vale escrever é sobre o trabalho que a estrutura de custo antiga impedia.

Publicamos posts de blog no mesmo dia em que rascunhamos. Levantamos uma seção inteira de categoria — uma nova galeria de ativos interativos, um novo pilar de academia — em uma tarde e iteramos ao vivo. Trocamos screenshots estáticos de produto por pequenos ativos interativos em Svelte que o leitor pode realmente usar. Os agentes que nos ajudam a rascunhar, traduzir e revisar operam sobre os mesmos arquivos em que nossos engenheiros operam. Não há mais um “fluxo de site de marketing” separado para ensinar a eles.

O dailybot.com hoje é publicado em inglês, espanhol e português a partir de um único repositório. Cada post, página e artigo do centro de ajuda é escrito como um arquivo por idioma, validado contra um schema de conteúdo tipado e conferido em build — a paridade é um erro de compilação, não uma preocupação de ciclo de revisão. Adicionar um quarto idioma é um dia de engenharia e uma fila de trabalho de tradução; não é um projeto que precisemos agendar em cima do roadmap de um fornecedor.

Para um time do nosso tamanho — pequeno o bastante para sentir cada ineficiência, grande o bastante para que o trabalho de superfície pública seja constante — é esse o ponto.

O que diríamos para outro time

• A experiência de edição não é o gargalo. O ritmo é. Decidam se o site de marketing é uma propriedade de conteúdo ou um produto, e escolham um sistema que combine.
• Seu time não-técnico já consegue publicar na superfície pública. Planejem em torno disso. Um ano atrás, mover o site de marketing para um repositório significava empurrar o trabalho de conteúdo de volta para engenharia ou construir um editor visual por cima. Nenhum dos dois é necessário hoje, se a ferramenta de código e a superfície de design/preview forem a mesma coisa. Não estamos ensinando nosso time a programar; estamos ensinando eles a instruir um agente.
• Reconstruam, não portem. Uma tradução componente por componente preserva escolhas que vocês não querem manter. Se a migração vale a pena, gastem a semana extra em um redesign de verdade na mesma janela.
• Façam i18n ser uma propriedade do sistema, não manual. As Content Collections do Astro com um schema tipado por idioma transformaram “os três idiomas estão em sincronia?” de uma planilha em um erro de build. Só isso pagou o custo da migração.
• O CMS de edição visual que tínhamos continua excelente. Mas se vocês quiserem se mover na velocidade da nova era da IA, já não basta.

A entrega que importa

O que mudou não é o nosso site: é quem pode mexer nele. Antes desta migração, qualquer mudança no dailybot.com passava pela engenharia. Hoje nosso PM, nossa designer e nosso lead de growth abrem PRs todos os dias. A métrica com a qual mais nos importamos não é o Lighthouse nem o tempo de build — é quantas pessoas do time podem empurrar a superfície pública para frente em uma terça qualquer.

Essa é a migração que importa, e a única razão pela qual conseguimos fazê-la é que os agentes chegaram. Sem eles, essa história não existe: o editor visual continuaria sendo o caminho mais curto. Com eles, o caminho mais curto virou um repositório que o time inteiro pode operar — porque o agente traduz.

Se o seu time está onde estávamos no fim de 2025, a decisão não é realmente sobre Astro, nem sobre Webflow, nem sobre nenhum stack específico. É sobre quem você quer movendo a sua superfície pública daqui a um ano. A nossa resposta foi: o time inteiro. Isso mudou a forma como trabalhamos mais do que qualquer escolha de plataforma poderia ter mudado.