Migrei o site da Promovaweb do WordPress para o Astro porque Codex e Claude já trabalhavam comigo nos arquivos do repositório. Trinta dias depois, a diferença mais importante não estava numa lista de recursos. Ela aparecia toda vez que eu corrigia um artigo.

No WordPress, eu abriria o painel e alteraria os blocos. No fluxo que adotei, abro o Markdown, comparo os arquivos modificados e publico pelo Git. Essa forma combina com meu trabalho atual. Para você, a melhor plataforma depende do lugar onde a edição realmente acontece.

Direto ao ponto

Eu prefiro Astro quando conteúdo e implementação já são mantidos em arquivos e os agentes participam desse trabalho. Continuo indicando WordPress para você que precisa editar pelo painel visual. O editor usado toda semana pesa mais que uma comparação abstrata entre tecnologias.

A migração também transfere responsabilidades. No Astro, eu preciso conferir o Markdown, o build e a página publicada. WordPress concentra a edição no painel e possui outro conjunto de atualizações, plugins e hospedagem. Nenhuma escolha retira a manutenção do site.

Uma correção de artigo mostra a diferença

Imagine que o preço citado num artigo mudou. No WordPress, você localiza a publicação no painel, edita o bloco e visualiza o resultado. Permissões e histórico dependem da configuração adotada no site.

No blog da Promovaweb, eu altero o arquivo Markdown correspondente. O texto e os metadados ficam próximos, e o Git mostra as linhas removidas e adicionadas. Antes de aceitar a mudança proposta por um agente, comparo esse conteúdo com a fonte usada no artigo.

O arquivo não mostra toda a página. Depois do deploy, abro o endereço publicado e confiro heading, links, imagem e formatação. Uma correção pode estar certa no Markdown e aparecer quebrada na interface por causa de um componente ou estilo.

Essa passagem entre arquivo bruto e página renderizada define o meu trabalho. Ela não prova que editar código seja melhor para toda empresa. Um redator que trabalha diariamente no painel pode perder autonomia se cada ajuste exigir acesso ao repositório.

Componentes ampliam o alcance de uma alteração

O site usa componentes React e estilos em Tailwind CSS. Um botão compartilhado pode ser alterado uma vez e reaparecer em várias páginas. O Git revela a definição modificada, enquanto a revisão visual precisa alcançar os lugares que reutilizam o componente.

Trocar a cor do botão numa página clara parece simples. Em outra seção, o mesmo componente pode ficar sobre um fundo escuro e perder contraste. Eu preciso abrir as duas páginas, testar o foco pelo teclado e confirmar que a ação continua funcionando.

WordPress também reutiliza conteúdo. Os padrões sincronizados atualizam conjuntos de blocos em vários lugares. A diferença está no ambiente usado para criar, revisar e publicar essa alteração.

React foi uma escolha da Promovaweb, não uma exigência do Astro. O framework aceita diferentes integrações de frontend, e cada componente recebe JavaScript no navegador somente quando sua função exige interatividade.

O Git não publica sozinho

No meu fluxo, enviar uma alteração aciona o build e o deploy. O registro no Git confirma que o arquivo chegou ao repositório. Ele não confirma que a compilação terminou nem que o endereço público mostra a versão nova.

Quando o build falha, eu abro o relatório da execução e localizo o arquivo indicado. Repetir a edição do artigo sem ler essa saída mistura um problema de conteúdo com uma falha de dependência, schema ou componente.

Na configuração estática da Promovaweb, o HTML é preparado durante a compilação. Astro também permite renderização sob demanda. Uma área autenticada ou uma página que consulta informação a cada acesso exige outra arquitetura e outro plano de hospedagem.

A comparação sobre hospedagem para iniciantes parte justamente da manutenção que você consegue executar. Um blog estático e uma aplicação que grava cadastros não devem receber a mesma infraestrutura por conveniência.

WordPress pode continuar como editor

Migrar a construção das páginas não obriga você a abandonar o painel. A documentação do Astro explica a integração com WordPress como CMS. O Astro consulta o conteúdo e produz a interface, enquanto redatores e editores mantêm o painel conhecido.

Essa combinação preserva o painel e acrescenta uma integração. Você precisa conferir autenticação, disponibilidade da API e atualização do conteúdo no build ou na renderização escolhida. O WordPress continua ativo e precisa ser mantido.

Minha escolha foi levar os artigos para Markdown porque eu já editava o site por arquivos com agentes. Se redatores publicam e corrigem pelo painel, manter o WordPress como origem pode ser uma transição mais adequada do que trocar tudo ao mesmo tempo.

Trinta dias depois, eu escolheria pelo fluxo

Astro combinou com a forma como eu escrevo e altero a Promovaweb. Os artigos ficam ao lado da implementação, os agentes consultam os arquivos necessários e eu comparo cada mudança antes de publicar. Esse conjunto explica minha preferência.

WordPress continua indicado quando a edição visual é central. A API REST também permite integrações externas, então a escolha não se resume a painel manual contra automação. Observe onde os redatores escrevem, como os editores revisam e se eles conseguem corrigir uma página sem interromper a publicação.

O artigo sobre Markdown e agentes de IA no blog mostra como os arquivos participam da produção editorial. Para aplicações que misturam site e funções dinâmicas, infraestrutura para Vibe Coding separa frontend, banco e armazenamento.

No Plano IA Makers, você aprende a construir e revisar sistemas com agentes. Quando a migração envolve componentes, build e deploy já existentes, o Diagnóstico de Produto e Arquitetura da Dev Side Studio documenta a jornada atual e o alcance técnico da mudança.

Antes de migrar, faça uma correção comum nas duas formas de trabalho. Meça quantos redatores conseguem executá-la, onde o histórico aparece e como você confere a página final. Foi nessa rotina, e não numa tabela de funcionalidades, que Astro venceu para mim.