Principais destaques
→ Sites estáticos combinados com IA oferecem vantagens reais, principalmente quando o objetivo é reduzir dependências, melhorar o desempenho e manter controle absoluto sobre a estrutura do projeto, mas essas vantagens não significam necessariamente uma experiência melhor para quem precisa administrar conteúdo todos os dias.
→ O desafio aparece nas tarefas aparentemente banais, como alterar categorias, corrigir URLs, atualizar links internos, excluir conteúdos, controlar redirects ou reorganizar páginas, porque um CMS tradicional já possui mecanismos para resolver boa parte dessas situações sem exigir que o usuário pense na infraestrutura por trás delas.
→ Quando a inteligência artificial passa a ser responsável por reproduzir todas essas funções, o projeto pode começar a se transformar em algo muito maior do que um simples site estático, chegando ao ponto de exigir scripts, automações e regras que, na prática, começam a reconstruir um novo sistema de gerenciamento de conteúdo.
A proposta de substituir o WordPress por uma estrutura baseada em HTML estático, Git e ferramentas de inteligência artificial é atraente porque combina várias tendências importantes do desenvolvimento moderno.
Em vez de depender de um banco de dados, de dezenas de plugins e de uma camada administrativa relativamente pesada, o site pode ser transformado em um conjunto de arquivos que são gerados, versionados e publicados de maneira previsível.
Nesse cenário, ferramentas como o Claude Code acrescentam uma camada ainda mais interessante, porque permitem que uma pessoa descreva uma alteração em linguagem natural e deixe o agente investigar o projeto, localizar os arquivos relevantes, modificar o código e verificar o resultado.
A Anthropic posiciona o Claude Code justamente como uma ferramenta capaz de trabalhar diretamente sobre repositórios e executar tarefas de desenvolvimento, com recursos como instruções específicas do projeto, hooks, skills e subagentes para fluxos mais complexos.
Para quem acompanha a evolução dos agentes de programação, é difícil não imaginar as consequências disso para a criação de sites. Se uma IA consegue entender a estrutura de um projeto, alterar componentes, criar páginas, corrigir erros e automatizar processos, surge naturalmente uma pergunta que há alguns anos pareceria exagerada:
“Por que ainda precisamos de um CMS?”
A pergunta é legítima, mas ela mistura duas atividades que parecem semelhantes e, na prática, são bastante diferentes. Construir um site e administrar um site durante vários anos não representam o mesmo problema, especialmente quando o projeto deixa de ser uma página institucional simples e passa a funcionar como uma operação editorial com conteúdo publicado, atualizado, reorganizado e removido continuamente.
É justamente nessa diferença que a discussão sobre IA e WordPress fica mais interessante, porque a questão deixa de ser simplesmente tecnológica e passa a envolver produtividade, manutenção e o valor de não precisar pensar em determinadas tarefas.
O lado realmente bom do site estático
Antes de questionar a ideia, é importante reconhecer que uma arquitetura estática pode ser uma escolha excelente para muitos projetos. Em determinadas situações, ela consegue entregar uma combinação muito interessante de desempenho, simplicidade operacional e controle técnico, principalmente quando o conteúdo não precisa ser alterado com frequência ou quando existe uma equipe confortável trabalhando diretamente com código.
Em uma arquitetura tradicional baseada em um CMS, uma solicitação pode envolver diferentes componentes da aplicação, incluindo banco de dados, processamento no servidor, plugins e outras camadas responsáveis por montar a página que será entregue ao visitante. Em uma arquitetura estática, boa parte desse trabalho pode ser realizado antecipadamente, fazendo com que o servidor entregue arquivos já preparados.
Essa abordagem também pode reduzir o número de componentes que precisam ser mantidos, atualizados e monitorados. Um projeto sem banco de dados para o conteúdo, com poucas dependências e sem uma grande coleção de plugins, pode apresentar uma superfície operacional consideravelmente menor.
Isso não significa que um site estático seja automaticamente mais seguro ou mais rápido em qualquer circunstância, mas existe uma vantagem clara na redução da complexidade de determinadas arquiteturas.
E existe outra característica que costuma ser particularmente atraente para desenvolvedores: tudo pode estar representado no código e no sistema de versionamento.
Um artigo pode ser tratado como um arquivo, um template pode ser alterado como qualquer outro componente do projeto, uma mudança pode ser registrada em um commit e uma versão anterior pode ser recuperada com relativa facilidade. O histórico das alterações também pode ficar documentado no próprio repositório, criando uma relação muito clara entre conteúdo, código e publicação.
Para um blog pessoal, uma documentação técnica, um portfólio, uma landing page ou um site institucional que recebe poucas alterações, esse modelo pode funcionar extremamente bem.
O problema aparece quando o site deixa de ser apenas um conjunto de páginas e passa a funcionar como uma operação editorial contínua, na qual o volume de pequenas alterações começa a importar tanto quanto a arquitetura utilizada para entregar as páginas.
O teste que nenhum benchmark mostra
Existe uma maneira simples de perceber essa diferença: imaginar as tarefas que normalmente não aparecem em comparações de desempenho entre tecnologias.
Suponha que alguém precise corrigir duas frases em um artigo publicado há alguns anos. Em um CMS como o WordPress, o processo costuma ser extremamente direto, porque basta localizar o conteúdo no painel administrativo, fazer a alteração e atualizar a publicação, sem que o usuário precise saber onde o arquivo está armazenado ou quais outras partes do sistema serão afetadas.
Em uma estrutura estática administrada diretamente por código, a mesma tarefa pode continuar sendo simples, especialmente quando existe uma IA para auxiliar, mas ela passa a depender de uma cadeia de operações que antes ficava escondida. É necessário localizar o conteúdo correto, compreender como ele se relaciona com a estrutura do projeto, realizar a alteração, verificar o resultado, executar o processo de geração quando necessário e publicar novamente a versão modificada.
Nenhuma dessas etapas representa uma grande dificuldade técnica isoladamente. O problema é que elas se repetem.
Quando o site começa a crescer, surgem situações como a necessidade de transferir conteúdos entre categorias, alterar slugs, remover publicações antigas, criar redirecionamentos para URLs modificadas, revisar links internos, atualizar sitemaps, corrigir paginação, modificar imagens, acrescentar ou remover tags, revisar dados estruturados e manter a busca interna funcionando corretamente.
Também podem aparecer demandas mais específicas, como localizar páginas órfãs, encontrar conteúdos que deixaram de receber links internos, identificar URLs que não deveriam mais existir ou realizar uma alteração em dezenas de artigos simultaneamente.
É nesse ponto que a comparação começa a mudar de natureza.
O problema deixa de ser saber se a IA consegue editar um arquivo HTML e passa a ser descobrir quanto trabalho precisa ser feito para garantir que todas as consequências daquela alteração sejam tratadas corretamente.
Essa diferença pode parecer pequena quando observamos uma única publicação, mas se torna significativa quando estamos falando de uma operação editorial que realiza essas tarefas repetidamente.
Um CMS maduro não é valioso porque torna impossível fazer essas operações de outra maneira. Ele é valioso porque permite realizá-las sem transformar cada alteração em uma pequena tarefa de engenharia.
O CMS esconde uma quantidade absurda de trabalho
Esse talvez seja um dos aspectos mais subestimados quando se discute a possibilidade de substituir um CMS por ferramentas de inteligência artificial.
Um sistema de gerenciamento de conteúdo não é apenas um editor de textos com uma tela administrativa. Ao longo dos anos, plataformas como o WordPress acumularam uma enorme quantidade de mecanismos destinados a resolver situações que surgem naturalmente quando um site começa a publicar conteúdo em escala.
Quando um artigo é publicado, existe uma estrutura para armazenar aquele conteúdo, relacioná-lo a categorias e tags, disponibilizá-lo em determinadas listagens e permitir que outros sistemas encontrem a nova página. Dependendo da configuração e dos recursos instalados, também existem mecanismos relacionados a feeds, metadados, SEO, sitemaps, busca, redirecionamentos e outras partes da operação.
Grande parte desse trabalho desaparece da atenção do usuário justamente porque o sistema foi construído para cuidar dele.
Essa invisibilidade é uma das maiores forças de um CMS.
Quando uma pessoa publica um artigo, ela não precisa necessariamente saber qual tabela recebeu os dados, qual arquivo será gerado, como a listagem da categoria será atualizada ou de que maneira a nova página será descoberta por diferentes mecanismos. Ela simplesmente utiliza a interface que abstrai toda essa complexidade.
É semelhante ao que acontece em diversas outras áreas da tecnologia: uma ferramenta madura pode parecer menos impressionante justamente porque esconde uma enorme quantidade de trabalho.
Quando tudo funciona, ninguém pensa sobre o mecanismo que está por trás.
Apenas utiliza.
E isso tem um valor enorme quando o objetivo não é construir uma nova plataforma, mas simplesmente publicar conteúdo.
“É só mandar o Claude fazer”
É justamente aqui que a inteligência artificial torna a discussão muito mais interessante, porque seria incorreto afirmar que uma ferramenta como o Claude Code não consegue lidar com essas tarefas.
Ela consegue.
É perfeitamente possível pedir que um agente encontre determinados conteúdos, faça alterações em arquivos, identifique links quebrados, crie redirecionamentos, reorganize estruturas ou desenvolva scripts para automatizar operações que seriam repetitivas para uma pessoa.
Esse é justamente um dos aspectos mais promissores dos agentes de programação. Em vez de utilizar a IA apenas para completar uma linha de código, o usuário pode fornecer uma tarefa mais ampla e permitir que o agente investigue o projeto, descubra quais arquivos estão envolvidos e execute uma sequência de alterações.
A dificuldade aparece quando essas necessidades deixam de ser exceções e passam a representar a rotina diária do site.
Quanto mais sofisticado fica o projeto, maior é a quantidade de contexto que o agente precisa compreender. Além disso, as regras do sistema precisam ser cada vez mais explícitas para reduzir o risco de uma alteração produzir efeitos inesperados em outra parte do site.
Nesse momento, começam a surgir scripts para gerar sitemaps, ferramentas para administrar redirects, mecanismos para organizar categorias, sistemas de busca, rotinas para links internos, validações de SEO e processos para verificar se o build foi realizado corretamente.
Também podem aparecer testes automatizados, regras de publicação, validações de conteúdo e outras camadas destinadas a impedir que uma alteração aparentemente simples provoque um problema em outra parte da estrutura.
E então surge uma conclusão curiosa:
quanto mais você tenta transformar a IA em administradora completa do site, mais começa a construir as ferramentas que um CMS tradicional já oferece.
A diferença é que, nesse caso, você passa a ser responsável por projetar, manter e corrigir esse sistema.
O momento em que o site vira um projeto de software
Essa talvez seja a conclusão mais importante de toda essa discussão, porque ela mostra por que a comparação direta entre WordPress e Claude Code não é exatamente justa.
O WordPress é um sistema de gerenciamento de conteúdo, enquanto o Claude Code é uma ferramenta voltada para desenvolvimento assistido por inteligência artificial. Eles podem trabalhar juntos, e um pode inclusive ser utilizado para modificar ou ampliar o outro, mas eles não foram criados originalmente para resolver o mesmo problema.
A questão surge quando alguém decide utilizar a segunda ferramenta para substituir completamente a primeira.
Em um site pequeno, essa decisão pode funcionar muito bem. Quando existem poucas páginas e poucas alterações, a flexibilidade proporcionada pelo código pode compensar amplamente qualquer trabalho adicional de manutenção.
Conforme o número de conteúdos aumenta, entretanto, o problema deixa de ser simplesmente técnico. A quantidade de operações começa a ter um peso muito maior, especialmente quando diferentes pessoas precisam publicar, revisar e alterar conteúdos sem necessariamente possuir conhecimentos de programação.
Nesse cenário, um site que inicialmente parecia extremamente simples pode começar a acumular uma infraestrutura cada vez mais sofisticada para administrar seu próprio conteúdo.
O HTML continua sendo estático, mas o ecossistema ao redor dele deixa de ser simples.
Você passa a ter scripts, convenções, ferramentas internas, processos de publicação, validações, agentes, prompts específicos, arquivos de configuração e regras que precisam ser conhecidas para evitar problemas.
O site continua funcionando.
A questão é que você já não está apenas administrando um site.
Está administrando uma plataforma de publicação que você mesmo precisou construir.
O paradoxo da IA
Existe um paradoxo bastante interessante nessa discussão, porque a inteligência artificial pode tornar muito mais fácil abandonar um CMS e, ao mesmo tempo, tornar muito mais fácil construir um CMS próprio.
Com a ajuda de um agente de programação, uma pessoa pode criar rapidamente uma ferramenta para editar categorias, desenvolver uma interface para determinados conteúdos, implementar um sistema de redirects, gerar um sitemap ou criar mecanismos para encontrar relações entre diferentes páginas.
A IA reduz drasticamente o custo de construir essas ferramentas, mas ela não elimina a complexidade que existe por trás delas.
Ela apenas torna mais barato e mais rápido transformar essa complexidade em software.
Antes, alguém precisava passar semanas desenvolvendo uma solução própria para determinado fluxo editorial. Agora, um agente pode ajudar a produzir boa parte desse sistema em muito menos tempo.
Isso é uma mudança gigantesca.
Mas existe uma diferença importante entre conseguir construir uma ferramenta e querer ser responsável por sua manutenção durante anos.
Um CMS maduro já passou por inúmeras situações semelhantes, acumulou correções, recebeu contribuições de uma comunidade e criou interfaces que permitem que usuários sem conhecimento técnico realizem operações que, de outra maneira, exigiriam intervenção de um desenvolvedor.
Quando você substitui essa plataforma por um sistema próprio, também assume a responsabilidade por todas essas decisões.
Para algumas equipes, isso pode ser exatamente o que elas desejam.
Para outras, pode representar um nível de manutenção completamente desnecessário.
O WordPress continua sendo popular por um motivo
É interessante observar que, mesmo depois de anos de previsões sobre o desaparecimento dos CMS tradicionais, o WordPress continua ocupando uma posição extremamente relevante na web.
Dados da W3Techs indicam que o WordPress permanece presente em uma parcela muito significativa dos sites monitorados e representa a maior participação entre os sistemas de gerenciamento de conteúdo identificados pela plataforma.
Isso não significa que o WordPress seja a melhor escolha para todos os projetos, nem que sua arquitetura não tenha limitações. Significa apenas que existe uma razão concreta para uma plataforma tão antiga continuar sendo utilizada por uma quantidade tão grande de pessoas.
Essa razão está menos relacionada a uma suposta superioridade tecnológica e muito mais à capacidade de transformar operações complexas em ações relativamente simples.
Um editor não precisa saber onde determinado arquivo HTML está localizado para alterar um artigo. Um redator não precisa entender Git para publicar um conteúdo. Uma pessoa responsável pelo marketing não precisa necessariamente conhecer a estrutura técnica de um redirect para alterar uma URL e corrigir o endereço antigo.
O CMS absorve essa complexidade e apresenta uma interface que permite que cada profissional concentre sua atenção na tarefa que realmente precisa realizar.
Esse tipo de abstração pode parecer pouco sofisticado quando comparado à possibilidade de abrir um repositório e pedir para uma inteligência artificial modificar dezenas de arquivos.
Mas, do ponto de vista de produtividade, essa abstração pode ser extremamente poderosa.
A verdadeira vantagem pode ser a invisibilidade
Talvez essa seja a parte mais contraintuitiva de toda a discussão sobre IA e CMS.
As melhores ferramentas de produtividade são frequentemente aquelas que fazem você esquecer que existem, porque sua presença não interrompe o trabalho e suas decisões técnicas permanecem escondidas atrás de uma interface simples.
Quando um CMS está funcionando bem, ninguém precisa pensar na arquitetura que está permitindo a publicação de um artigo.
A pessoa abre o conteúdo, realiza a alteração, publica e continua trabalhando.
É justamente essa ausência de preocupação que pode ser difícil de reproduzir quando se substitui um sistema maduro por uma combinação de arquivos, scripts e agentes de inteligência artificial.
Uma IA pode ser tecnicamente muito mais poderosa e, ainda assim, oferecer uma experiência menos conveniente para determinadas tarefas.
Isso acontece porque capacidade e conveniência são coisas diferentes.
O Claude pode compreender um repositório inteiro, escrever código, alterar vários arquivos, investigar erros, criar automações e ajudar a projetar uma arquitetura completamente nova. Para determinadas tarefas, isso representa um salto enorme de produtividade.
Por outro lado, quando o objetivo é simplesmente alterar uma informação em um artigo, toda essa capacidade pode ser desnecessária.
Nesse caso, a melhor ferramenta talvez seja justamente aquela que não exige que o usuário pense em como a alteração será realizada.
O futuro talvez não seja “WordPress ou IA”
A conclusão mais interessante talvez seja abandonar a ideia de que precisamos escolher entre uma plataforma tradicional e uma inteligência artificial.
A IA não precisa necessariamente substituir o CMS para transformar completamente a maneira como administramos conteúdo.
Ela pode funcionar como uma nova camada sobre sistemas que já existem.
Imagine, por exemplo, um ambiente em que o responsável por um site possa solicitar que a inteligência artificial encontre conteúdos antigos sobre determinado assunto, identifique oportunidades de links internos e apresente uma lista para revisão antes de realizar qualquer alteração.
Também seria possível solicitar que o sistema encontre artigos relacionados a uma determinada categoria, proponha uma nova organização, identifique URLs que serão modificadas e prepare os redirects necessários antes da publicação.
Nesse modelo, a inteligência artificial não precisa reconstruir toda a infraestrutura do CMS.
Ela utiliza essa infraestrutura.
O CMS continua responsável pela organização, armazenamento e publicação, enquanto a IA passa a atuar como uma camada inteligente capaz de interpretar pedidos mais complexos e transformar instruções humanas em operações dentro do sistema.
Essa combinação pode acabar sendo mais poderosa do que simplesmente abandonar uma tecnologia madura para reconstruir tudo do zero.
E isso não significa que sites estáticos sejam uma má ideia
É importante deixar claro que essa discussão não representa uma defesa incondicional do WordPress.
Existem muitos projetos em que uma arquitetura estática pode ser a escolha mais racional, especialmente quando o conteúdo muda pouco, quando a equipe possui conhecimento técnico suficiente para trabalhar diretamente com código e quando desempenho, controle e simplicidade arquitetural são prioridades importantes.
Um blog pessoal com poucas atualizações, uma documentação técnica, uma landing page ou um site institucional relativamente pequeno podem funcionar muito bem dessa maneira.
Nesses casos, adicionar um CMS completo pode introduzir uma camada de complexidade que o projeto simplesmente não precisa.
O problema aparece quando a estrutura editorial cresce e começa a exigir uma quantidade cada vez maior de operações.
Nesse momento, o número absoluto de páginas é apenas uma das variáveis. A frequência das alterações, a quantidade de pessoas envolvidas, a necessidade de revisão, a estrutura de categorias, a estratégia de SEO, a quantidade de URLs e a necessidade de manter relacionamentos entre conteúdos também passam a influenciar a decisão.
Por isso, não existe um número mágico de páginas a partir do qual um site estático deixa de fazer sentido.
O que realmente muda é o momento em que administrar o conteúdo começa a consumir mais energia do que deveria.
A partir daí, as ferramentas utilizadas para organizar esse conteúdo passam a ter um valor muito maior.
A pergunta certa mudou
Durante muito tempo, a discussão sobre inteligência artificial e CMS poderia ser resumida em uma pergunta bastante direta:
“A IA consegue substituir o WordPress?”
Hoje, essa pergunta parece limitada porque considera apenas a capacidade técnica de construir e modificar páginas.
Uma questão muito mais relevante seria perguntar:
“A IA consegue substituir tudo aquilo que um CMS faz silenciosamente todos os dias?”
Isso inclui muito mais do que escrever HTML ou alterar um artigo. Envolve organizar conteúdos, manter relações entre páginas, administrar URLs, lidar com categorias e taxonomias, atualizar estruturas de navegação, cuidar de redirects, manter sitemaps, controlar permissões, preservar históricos e permitir que pessoas diferentes trabalhem no mesmo acervo sem precisar compreender toda a infraestrutura técnica.
Construir uma página é relativamente simples.
O desafio aparece quando é preciso administrar centenas ou milhares de páginas sem transformar cada alteração em um pequeno projeto de desenvolvimento.
Essa talvez seja uma das maiores forças de um CMS.
E também ajuda a explicar por que ferramentas como o WordPress continuam relevantes mesmo em um momento em que agentes de inteligência artificial conseguem escrever e modificar software em uma velocidade que seria difícil imaginar poucos anos atrás.
A IA pode reduzir a necessidade de um CMS em determinados projetos e pode permitir que equipes criem soluções muito mais específicas para necessidades particulares, mas isso não significa que todos os sites se beneficiarão de abandonar uma plataforma que já resolve uma grande quantidade de problemas.
Em muitos casos, o maior ganho de produtividade não está em ter uma tecnologia capaz de fazer mais coisas.
Está em ter uma tecnologia que evita que você precise pensar nessas coisas.
A conclusão depois de olhar para o problema de perto
A discussão sobre substituir o WordPress por uma combinação de site estático e inteligência artificial revela uma distinção importante entre capacidade técnica e eficiência operacional.
A IA é capaz de realizar tarefas que antes exigiriam um desenvolvedor, pode compreender estruturas de código cada vez maiores e consegue automatizar processos que seriam repetitivos para uma equipe humana. Isso abre possibilidades enormes para a criação e manutenção de sites.
O problema aparece quando começamos a exigir que ela assuma todas as responsabilidades que um CMS tradicional já incorporou ao longo de muitos anos.
Nesse momento, a solução deixa de ser apenas um site estático administrado por IA e passa a incluir scripts, automações, regras, validações, ferramentas internas e processos destinados a reproduzir aquilo que um CMS já fazia.
Não há nada de errado com isso.
Para algumas empresas e desenvolvedores, construir uma plataforma própria pode ser exatamente a decisão correta, principalmente quando existe uma necessidade específica que as soluções tradicionais não conseguem atender.
Mas, para muitos projetos, essa liberdade vem acompanhada de uma responsabilidade que só se torna evidente depois que o sistema começa a ser usado diariamente.
Às vezes, ninguém quer uma inteligência artificial para resolver todas as tarefas do site.
Às vezes, a pessoa simplesmente quer abrir o editor, alterar o conteúdo, clicar em publicar e voltar para o trabalho, sem precisar pensar em arquivos, builds, commits, scripts ou deploys.
Essa simplicidade pode parecer pouco impressionante diante do que os agentes de IA conseguem fazer atualmente, mas é justamente o resultado de décadas de evolução dos sistemas de gerenciamento de conteúdo.
Por isso, talvez o futuro não seja um mundo sem WordPress, nem um mundo em que todos os sites sejam gerenciados por agentes de IA.
O cenário mais provável e, talvez, mais interessante seja aquele em que CMS, sites estáticos e inteligência artificial coexistam, com cada tecnologia assumindo a parte do trabalho em que realmente consegue oferecer mais valor.
No fim, a pergunta mais importante não é qual tecnologia parece mais moderna, poderosa ou sofisticada.
É qual delas consegue tirar mais trabalho da frente de quem precisa manter um site funcionando todos os dias.
A ideia de abandonar um CMS tradicional e deixar uma inteligência artificial cuidar de um site parece cada vez mais plausível, especialmente agora que ferramentas como o Claude Code conseguem entender projetos, modificar arquivos e executar tarefas complexas.
O problema é que administrar um site editorial envolve muito mais do que escrever código, e é justamente nas pequenas operações do cotidiano que a diferença entre uma solução feita sob medida e um CMS maduro começa a aparecer.
