Como migrei do WordPress para um site estático com agentes

O WordPress ficou no ar por muito mais tempo do que a minha vontade de sair dele. Isso é mérito do projeto. Ele sobreviveu a mudanças de hospedagem, temas, hábitos de leitura e da própria web.

Por isso, esta não é uma história sobre um CMS ruim. Meu problema era mais específico: plugins de terceiros rodam dentro da mesma aplicação. No meu caso, um plugin mal escrito podia quebrar o site inteiro. A própria documentação do WordPress diz que plugins variam em qualidade, precisam de atualização e podem causar problemas. Ela recomenda até fazer backup antes de atualizá-los.

Isso não torna o WordPress inseguro por natureza, nem transforma todo plugin em ameaça. Mas eu já não queria que publicar um texto dependesse de todo o código instalado no site. A documentação oficial de segurança também deixa claro que manter o WordPress seguro é um trabalho contínuo.

Minha saída foi simples de explicar: os artigos viraram arquivos no Git, o Astro passou a gerar as páginas e serviços pequenos ficaram responsáveis pelo que realmente precisa de código ou banco de dados. Também criei um agente editorial com agentes especializados para me ajudar a pesquisar, escrever e revisar. Eu continuo fornecendo os fatos, o recorte e as correções. E continuo aprovando o que será publicado.

Eu não fiz o CMS desaparecer. Montei outra forma de fazer o trabalho dele.

Primeiro, listei tudo o que o WordPress fazia

Mover os textos era a parte fácil. O WordPress também cuidava de URLs, metadados, idiomas, comentários, banco de dados e publicação.

Em vez de tratar a migração como uma simples cópia de páginas, eu listei esses trabalhos um por um. Depois decidi quem ou o que faria cada um no novo site:

O que o WordPress fazia	Quem faz agora	Onde conferir
Guardava textos e metadados	Arquivos Markdown no Git	Schema dos artigos
Ligava traduções e URLs	Uma identidade comum e um endereço próprio para cada idioma	Arquitetura de conteúdo e lista de idiomas
Ajudava a escrever e revisar	Meus insumos, agentes especializados e testes automáticos	Aprovação humana antes de publicar
Servia os artigos	Astro e arquivos estáticos	Deploy do Astro na Cloudflare
Guardava comentários e outros dados	Worker e D1	Arquitetura do site e migrações do D1
Mantinha URLs antigas funcionando	Redirects permanentes apenas para URLs que já existiam	Regras revisadas e testadas no build
Configurava os serviços do site	Arquivo de configuração do Worker	Configuração da Cloudflare

Essa lista tornou a migração muito mais clara. Para cada trabalho, há uma solução e uma forma de conferir se ela está correta.

O resultado também muda o caminho de leitura. Um artigo não precisa mais consultar uma aplicação e um banco de dados para abrir. A integração do Astro com a Cloudflare permite entregar o arquivo pronto e chamar o Worker apenas quando alguma ação precisa dele.

Agentes ajudam no trabalho editorial, não dão a palavra final

Meu agente editorial começa com os meus insumos: o que aconteceu, o que quero contar, quais pontos precisam de cuidado e quais correções devem entrar. A partir daí, agentes especializados conferem as fontes, escrevem em cada idioma e revisam os textos. Scripts verificam se faltou algum campo, idioma ou aprovação.

A publicação continua sendo uma decisão humana. O agente pode fazer o trabalho; ele não recebe autoridade para publicar por conta própria.

Esse tipo de fluxo já é possível em ferramentas diferentes. O Codex permite criar subagentes especializados. O Claude Code também oferece subagentes com instruções, ferramentas e permissões próprias. O Google descreve o Antigravity como um lugar para iniciar e acompanhar agentes e documenta subagentes assíncronos e personalizados.

As três ferramentas não são iguais em qualidade, preço ou funcionamento. A ideia em comum é mais simples: posso dar uma função clara a cada agente. Um verifica a pauta, outro escreve, outro revisa. Regras automáticas rejeitam um pacote incompleto.

É assim que agentes tornam um CMS pessoal viável para mim. Não basta pedir “publique algo sobre WordPress”. O resultado melhora quando há bons insumos, fontes definidas, tarefas separadas, testes e aprovação.

Começou em dois idiomas e chegou a cinco

A primeira versão do site foi pensada em português e inglês. Depois, a estrutura passou a aceitar cinco idiomas: pt-BR, en, es, fr e zh-Hans. Francês e chinês simplificado vieram depois; eles não faziam parte da primeira migração.

Eu sempre quis escrever também em francês e chinês. Antes, manter esse hábito exigiria tempo demais. Agora preparo os mesmos fatos para todos os idiomas e cada agente escreve uma versão própria. Um texto não serve como molde de frases para o outro.

Isso facilita muito o trabalho, mas não garante qualidade nativa por mágica. Francês e chinês ainda precisam de uma pauta precisa, um agente adequado e revisão humana. O ganho é ter um processo que se repete e leva cada texto até essa revisão.

Cada idioma também tem sua própria URL, mas todos compartilham a mesma identidade interna. Assim, os comentários podem acompanhar o artigo mesmo quando o endereço muda de um idioma para outro. A arquitetura de conteúdo explica essa escolha.

A maior parte do site é arquivo; o resto tem função definida

O desenho ficou assim:

meus insumos
    ↓
fontes → agentes especializados → revisão e testes → Git
                                                    ↓
                                                  Astro
                                                    ↓
leitura dos artigos ───────────────────────→ Static Assets

ações que salvam dados ───────→ Worker ────→ D1
e-mails recebidos ────────────→ Email Routing ───→ endereço verificado ou Worker

Na leitura de um artigo, quero que o caminho seja curto. A documentação de Workers Static Assets diz que o acesso direto aos arquivos estáticos é gratuito e ilimitado, sem cobrança extra para guardar esses arquivos. Mas há uma diferença importante: se a requisição executar o Worker, ela passa a seguir as regras de cobrança de Workers. Uma configuração como run_worker_first também muda esse caminho.

O D1 guarda apenas os dados das funções dinâmicas. Os artigos continuam em arquivos. O plano gratuito tem limites diários para linhas lidas e escritas, além de limite de armazenamento. Quando um limite diário é atingido, as operações falham até ele ser renovado. Por isso, “tem plano grátis” não significa “não preciso pensar em falhas”.

O Email Routing também é muito útil. Ele recebe uma mensagem enviada para um endereço do meu domínio e a encaminha para um destino verificado ou para um Worker. Mas isso não é o mesmo que enviar uma newsletter ou um e-mail transacional para qualquer pessoa. A página de preços do Email Service explica a diferença: receber por Email Routing está disponível nos planos gratuito e pago; enviar para destinatários arbitrários exige Workers Paid. O envio para endereços verificados tem sua própria condição gratuita.

Essa combinação mostra por que a Cloudflare está tão forte para sites pequenos. Ela reúne arquivos estáticos, código sob demanda, banco de dados e roteamento de e-mail. Posso escolher só as peças necessárias, sem colocar uma aplicação inteira no caminho de cada visita.

A melhor Queue foi a que eu removi

Eu cheguei a avaliar Cloudflare Queues para processar a newsletter. A ideia fazia sentido no papel, e o plano gratuito é suficiente para experimentar. Mas ter um serviço disponível não significa precisar dele.

Segundo a documentação de Queues, o Workers Free oferece 10 mil operações por dia e guarda mensagens por 24 horas. Escrita, leitura, exclusão e novas tentativas contam separadamente.

Uma fila também exige código para consumir mensagens, evitar duplicidade, repetir falhas, acompanhar o processamento e recuperar problemas. Para o volume atual, era trabalho demais para pouco benefício. Então retirei a Queue.

Essa decisão é tão importante quanto os serviços que ficaram. Infraestrutura gratuita ainda custa tempo e atenção. Antes de adicionar uma peça, preciso saber qual problema ela resolve e quais problemas novos ela traz.

Grátis tem limite

Essa infraestrutura pode atender muitos sites pequenos dentro dos planos gratuitos. Não posso prometer custo zero para sempre, nem dizer que tudo continuará grátis sem acompanhar uso e cobrança.

Cada serviço mede uma coisa diferente. Static Assets separa a entrega direta de arquivos da execução do Worker. D1 mede linhas processadas e armazenamento. Queues cobra várias operações para tratar uma mensagem. Email Routing recebe e encaminha mensagens, mas não substitui qualquer tipo de envio.

O benefício real não é “hospedagem infinita de graça”. É começar com serviços baratos ou gratuitos e saber onde cada limite está. Quando o site crescer, fica mais fácil ver qual parte passou a custar mais.

A complexidade mudou de lugar

O melhor argumento a favor do WordPress continua válido. Ele oferece uma interface madura para escrever, gerenciar mídia e usuários, atualizar o sistema e instalar plugins. Uma pessoa sem experiência técnica pode delegar boa parte da operação sem aprender Git, CI ou migrações de banco.

Meu sistema coloca essas tarefas nas minhas mãos. Eu cuido de código, dependências, automação, agentes, APIs, segredos, migrações, proteção contra abuso e deploy. Servir artigos estáticos reduz o código executado durante a leitura, mas as funções dinâmicas ainda precisam de segurança, testes e monitoramento.

Se a prioridade é editar por um painel e delegar a infraestrutura, criar um CMS pessoal provavelmente é uma ideia ruim. Para quem já trabalha com engenharia e quer controle, a troca pode valer. Codex, Claude Code e Antigravity ajudam a manter um fluxo feito sob medida. Ainda assim, alguém precisa cuidar dele como software de produção.

O código está público. Traga uma lupa, não confete

O repositório do digows.com está público para consulta e revisão. Ele não tem uma licença geral que autorize reutilização, redistribuição ou criação de trabalhos derivados. Por isso, não o apresento como open source nem faço um convite genérico para copiar tudo.

O convite é este: escolha uma parte do sistema, leia o código e procure algo concreto que pode melhorar. Achou uma validação ausente, um comportamento confuso ou uma documentação ruim? Leia o guia de contribuição, abra uma issue focada e proponha a menor correção possível.

Se encontrar uma vulnerabilidade, não abra uma issue pública. Siga a política de segurança.

Menos confete, mais lupa. Uma boa contribuição começa com um problema específico.