WordPress está morto como a resposta automática, não como software.
Essa distinção importa. Se você disser "WordPress está morto" como uma afirmação literal de mercado, os dados rejeitam isso. A W3Techs relata que o WordPress alimenta 59,2% dos sites com um CMS conhecido e 41,5% de todos os sites em junho de 2026. Você não chama isso de morto.
Mas se você constrói sites em 2026, o velho reflexo começou a parecer errado. Um cliente quer um site rápido, layout personalizado, SEO limpo, algumas integrações e um fluxo de edição que não precise de dez plugins. A resposta costumava ser WordPress porque o código personalizado era lento e caro. A IA mudou esse cálculo.
O EmDash da Cloudflare torna a mudança mais difícil de ignorar. A Cloudflare não está dizendo que o WordPress não tem valor. Está dizendo que o próximo CMS pode ser TypeScript, serverless, alimentado por Astro, com plugins em sandbox e construído para agentes de IA desde o primeiro dia.
Ainda respeito o WordPress. Ainda o usaria no projeto certo. Não acho mais que ele mereça ser o padrão.
Por que o WordPress está morto como o padrão
O WordPress venceu porque deu poder de publicação a pessoas não técnicas. Isso foi um avanço real. Você podia instalar um tema, adicionar um page builder, publicar posts de blog, adicionar formulários, adicionar metadados de SEO e entregar o site a um cliente.
Esse argumento envelheceu mal para muitos sites de negócios.
Um site simples muitas vezes se torna uma pilha de plugins: page builder, plugin de cache, plugin de SEO, plugin de formulário, plugin de segurança, plugin de imagem, plugin de cookies, plugin de redirecionamentos, plugin de schema e, às vezes, um plugin de campos personalizados para tornar o page builder menos doloroso. Cada peça adiciona atualizações, configurações, tabelas de banco de dados, ativos e outro ponto de falha.
O problema não é o core do WordPress. O problema é a forma operacional que muitos projetos WordPress assumem após um ano. O site se torna um pequeno sistema de backend para páginas que poderiam ter sido entregues como HTML limpo, um pequeno CMS e algumas chamadas de API.
O relatório de segurança do WordPress de 2026 da Patchstack torna o custo de manutenção mais difícil de ignorar. O relatório diz que 11.334 novas vulnerabilidades foram encontradas no ecossistema WordPress em 2025, um aumento de 42% em relação a 2024. Também diz que 91% das novas vulnerabilidades foram encontradas em plugins, 9% em temas e apenas 6 vulnerabilidades foram relatadas no core do WordPress, todas de baixa prioridade.
Esse é o ponto. O WordPress em si não é o vilão. A superfície de plugins é onde o risco vive.
EmDash é o sinal mais limpo
Esta era a parte que eu deveria ter incluído desde o início. A Cloudflare introduziu o EmDash em 1º de abril de 2026 como uma prévia v0.1.0 e o descreveu como um sucessor espiritual do WordPress.
Os detalhes se alinham com o argumento deste artigo. O EmDash é escrito em TypeScript, alimentado por Astro, open source sob licença MIT e projetado para hospedagem serverless. Ele também visa o ponto doloroso específico do WordPress que continua voltando: plugins.
No WordPress, um plugin roda dentro do mesmo mundo do site. Ele pode tocar no banco de dados, sistema de arquivos e runtime de maneiras que exigem muita confiança. O modelo do EmDash da Cloudflare empurra os plugins para Dynamic Workers isolados e dá a eles capacidades declaradas através de bindings. Um plugin deve solicitar as permissões exatas de que precisa, como ler conteúdo ou enviar e-mail, antes de poder fazer esse trabalho.
Essa é a ideia moderna de CMS: menos confiança ambiente, mais permissões explícitas.
O EmDash também importa porque trata agentes de IA como parte do fluxo de trabalho. A Cloudflare diz que cada instância do EmDash pode expor um servidor MCP remoto, além de ferramentas de CLI e habilidades de agente. Isso significa que um agente de codificação pode gerenciar conteúdo, schemas, mídia e trabalho de migração através de ferramentas estruturadas em vez de raspar um painel administrativo ou adivinhar onde os dados vivem.
Eu não diria a um cliente para migrar para o EmDash cegamente hoje. É uma prévia. A parte importante é a direção: a Cloudflare está construindo a substituição do WordPress em torno das mesmas coisas que agora quero dos sites: extensões em sandbox, arquitetura de frontend limpa, controle programático e operações legíveis por agentes.
A IA mudou a matemática dos sites personalizados
Há alguns anos, personalizado significava caro. Você要么 pagava um desenvolvedor para construir cada página e componente,要么 usava um page builder e aceitava o peso.
A IA torna o caminho do meio prático. Você pode descrever um layout, gerar componentes, refinar o espaçamento, escrever copy, criar conteúdo estruturado, construir um pequeno fluxo administrativo e conectar os serviços exatos de que precisa. Ferramentas como v0, Framer AI, Webflow AI, construtores de aplicativos no estilo Lovable e agentes de codificação modernos tornaram as interfaces personalizadas mais rápidas de produzir.
Isso não significa que a IA substitua o gosto, o QA ou o julgamento de engenharia. Significa que o primeiro rascunho não consome mais todo o orçamento.
É aqui que o WordPress perde sua posição padrão. Se eu posso obter uma construção personalizada em Next.js, Astro, EmDash ou Webflow que corresponda exatamente à marca, carregue rápido, envie schema limpo e evite um backend pesado, o compromisso do WordPress se torna mais difícil de justificar.
Um page builder lhe dá botões. Um fluxo de código assistido por IA lhe dá o sistema real: componentes, modelo de conteúdo, rotas, metadados, tratamento de imagens, formulários, analytics e regras de implantação. Você pode inspecioná-lo. Você pode versioná-lo. Você pode testá-lo.
Isso importa mais que um marketplace de temas.
O backend deve corresponder ao trabalho
Um site institucional não precisa de um painel administrativo baseado em banco de dados por padrão. Uma landing page não precisa de PHP, MySQL, vinte telas de opções e uma camada de cache para parecer rápida.
Use um backend quando o projeto precisar de um:
Não adicione um backend porque um tema precisa de algum lugar para armazenar blocos.
Uma stack moderna e leve pode ser menor. Páginas estáticas, rotas renderizadas no servidor, um headless CMS, Supabase, um fluxo de conteúdo baseado em Git, formulários hospedados, Stripe, um provedor de busca e uma pequena API cobrem uma grande porcentagem dos sites. Você obtém menos peças móveis e melhor controle sobre o desempenho.
Esta é a mesma razão pela qual me importo com HTML limpo e trabalho de SEO medido. No meu estudo de caso de pontuação SEO no Lighthouse→, a vitória veio de marcação disciplinada, schema, velocidade, acessibilidade e cache. Um construtor de sites pode ajudar, mas a saída final ainda tem que ser legível por navegadores, mecanismos de busca e agentes de IA.
A IA torna o design exato menos caro
O caso mais forte contra o WordPress não é mais apenas a velocidade. É o controle de design.
A maioria dos projetos WordPress começa com um tema e depois dobra a marca para se encaixar nele. Você muda fontes, cores, seções e espaçamento, mas o tema ainda deixa impressões digitais. O site parece com a ferramenta que o construiu.
A IA inverte esse fluxo de trabalho. Você pode começar com a marca, a oferta, o público e o modelo de interação real. Então você gera a interface em torno dessas restrições.
Essa é uma ordem melhor.
Um site de consultor pode ter a estrutura de prova exata de que precisa. Uma página de SaaS pode mostrar uma superfície de produto densa em vez de um hero genérico. Uma página de produto musical pode parecer uma ferramenta de estúdio real em vez de um template. Uma página de negócio local pode tornar visíveis informações de reserva, confiança, localização e serviço sem lutar contra as suposições de layout de um tema.
A saída ainda precisa de revisão. A IA pode gerar CSS ruim, acessibilidade fraca, JavaScript inchado e copy vaga. Um humano ainda tem que inspecionar a página, testar no mobile, verificar links, verificar metadados, rodar o Lighthouse e manter a escrita honesta.
Mas a IA remove a desculpa de que personalizado significa lento.
Quando o WordPress ainda vence
Eu ainda escolheria o WordPress quando o fluxo de edição é o produto.
Se uma equipe publica muitos posts, usa hábitos editoriais existentes do WordPress, depende do WooCommerce, precisa de plugins maduros específicos ou já tem anos de histórico de SEO em uma configuração estável do WordPress, reconstruir por moda é um mau movimento.
O WordPress também funciona bem para equipes que precisam de uma superfície administrativa familiar mais do que precisam de um frontend personalizado. Há valor em uma ferramenta que as pessoas já conhecem.
O erro é escolher o WordPress antes de perguntar o que o site precisa fazer.
Para muitas novas construções, o site precisa de velocidade, estrutura, design personalizado, integrações controladas e baixa manutenção. O WordPress pode fazer essas coisas, mas muitas vezes as alcança através de camadas extras. Construções personalizadas assistidas por IA as alcançam mais diretamente.
Minha regra prática
Eu faria três perguntas antes de escolher o WordPress hoje.
Primeiro, o cliente precisa especificamente da experiência administrativa do WordPress?
Segundo, um plugin resolve um problema de negócios difícil melhor do que uma pequena integração personalizada?
Terceiro, o site ainda será fácil de manter após doze meses de atualizações, solicitações de marketing, scripts de rastreamento e alterações de conteúdo?
Se a resposta for sim, o WordPress pode ser a escolha certa.
Se a resposta for não, eu começaria com uma arquitetura mais leve e usaria IA para construir a interface exata. Isso pode significar um site estático, um headless CMS, um frontend React ou Astro, EmDash, Webflow, Framer ou um pequeno app full-stack. A stack deve se adequar ao trabalho, não ao hábito.
É também aqui que os agentes de IA se tornam úteis. Um bom agente pode inspecionar o site, verificar links, checar metadados, testar uma build, atualizar conteúdo e deixar um rastro. Escrevi sobre essa camada de controle no meu artigo sobre fluxos de trabalho de desenvolvedores MCP→. A mesma ideia se aplica a sites: as ferramentas devem expor ações claras, não esconder tudo atrás de uma tela de plugin.
Veredito
WordPress está morto como a resposta automática. WordPress não está morto como software.
O EmDash é inicial, mas mostra para onde a conversa sobre CMS está indo: serverless por padrão, amigável ao TypeScript, nativo de frontend, limites de plugins mais seguros e fluxos de trabalho de agentes de IA em vez de tarefas administrativas manuais.
A web moveu-se para frontends mais rápidos, backends menores, design assistido por IA e controle mais explícito sobre a saída final. O WordPress ainda tem um lugar, mas tem que ganhar esse lugar projeto por projeto.
Se você precisa de uma máquina de publicação, use uma. Se você precisa de um site personalizado que pareça exato, carregue rápido e evite um backend pesado, a IA tornou o caminho melhor mais fácil de seguir.