Toda vez que surge uma novidade no mundo do desenvolvimento web, alguém declara o fim do WordPress. Aconteceu com o React, com o Vue, com os headless CMSs, com o Jamstack, com o No-Code, com a IA. E vai acontecer de novo.
O WordPress continua em pé. Mais de 43% de todos os sites da internet rodam nele hoje. Não por inércia, não por falta de opção. Por resultado.
Mas isso não significa que ele é a resposta certa para todo projeto. A pergunta que realmente importa não é “WordPress está morto?”. É: “WordPress é a escolha certa para o que eu preciso?”
O que é um CMS e por que isso importa?
Antes de entrar no mérito, vale esclarecer o básico. Um sistema de gerenciamento de conteúdo é uma plataforma que permite criar, editar e publicar conteúdo na web sem precisar escrever código do zero. O WordPress é o mais popular do mundo, mas está longe de ser o único.
Existem CMSs headless como Contentful, Sanity e Strapi que separam o backend do frontend. Existem plataformas all-in-one como Wix, Squarespace e Webflow que entregam tudo num pacote fechado. Existem geradores de sites estáticos como Hugo e Jekyll. E existem frameworks modernos como Next.js e Astro que não são CMSs, mas assumem funções parecidas em projetos mais complexos.
A escolha do CMS certo define quanto você vai gastar para manter o site no ar, quanto tempo leva para fazer uma atualização, quão vulnerável o site fica a ataques e o quanto ele vai crescer com o seu negócio. Não é uma decisão técnica. É uma decisão de negócio.
A história dos obituários do WordPress
2012: Os aplicativos mobile vão matar os sites. O WordPress continuou crescendo.
2015: O Médium vai matar os blogs independentes. O WordPress continuou crescendo.
2018: O No-Code vai eliminar a necessidade de desenvolvedores e CMS. O WordPress continuou crescendo.
2020: O Jamstack e os sites estáticos vão tornar o WordPress obsoleto. O WordPress continuou crescendo.
2022: O headless CMS vai substituir tudo. O WordPress continuou crescendo.
2023: A IA vai gerar todo o conteúdo e os sites vão deixar de importar. O WordPress continuou crescendo.
O padrão é claro. Cada onda tecnológica chega com a promessa de ser o substituto definitivo. Algumas dessas tecnologias são genuinamente melhores em casos específicos.
Mas nenhuma delas eliminou o problema que o WordPress resolve para a maioria das pessoas: publicar conteúdo na internet de forma acessível, extensível e com um ecossistema maduro.
Isso não é nostalgia. É pragmatismo.
O problema real não é a plataforma
Quando alguém reclama que o WordPress é lento, pesado ou inseguro, na maioria das vezes o problema não é o WordPress em si. É a instalação.
Um site WordPress mal configurado acumula plugins desnecessários, temas com código inflado, hospedagem subdimensionada e nenhuma rotina de manutenção. O resultado é um site que demora quatro segundos para carregar, reprova nos Core Web Vitals, tem vulnerabilidades conhecidas não corrigidas e vira alvo fácil para ataques automatizados.
Um site WordPress bem configurado com hospedagem adequada, tema leve, plugins selecionados, cachê funcionando e atualizações em dia carrega em menos de dois segundos, passa em todas as métricas de performance do Google e opera sem interrupções por anos.
A diferença entre os dois não é a plataforma. É quem configura e quem mantém.
O payload é o problema que ninguém discute
Payload é o peso total que o navegador precisa baixar para renderizar a página: HTML, CSS, JavaScript, imagens, fontes, scripts de terceiros.
É a métrica mais honesta de performance porque não depende do servidor, depende do que você entregou.
É aqui que o WordPress frequentemente perde pontos, mas não por culpa do core da plataforma.
Um pagebuilder visual como o Elementor carrega centenas de kilobytes de CSS e JavaScript mesmo em páginas simples, porque gera estilos inline para cada elemento e registra scripts globalmente mesmo quando não são usados na página atual.
Plugins de slider, pop-up, formulário, SEO, segurança, cache e analytics empilham requisições HTTP. Fontes do Google Fonts bloqueiam renderização. Scripts de pixel do Meta e do Google Tag Manager executam antes do conteúdo aparecer.
O resultado é um payload de 3 MB e 80 requisições para uma página que deveria ter 300 KB e 15 requisições.
Tecnologias modernas como Astro, Next.js ou sites estáticos entregam payloads menores por design, porque só carregam o que a página realmente usa, compilam CSS morto fora do bundle e diferem scripts não críticos automaticamente. Isso não é magia. É arquitetura deliberada.
Mas aqui está o ponto que a maioria das comparações ignora: um WordPress bem mantido, com tema otimizado e disciplina na escolha de plugins, consegue payloads comparáveis. A diferença é que exige atenção técnica contínua e consciência nas escolhas. Não acontece sozinho.
Core Web Vitals e o impacto no Google
O Google usa Core Web Vitals como fator de ranqueamento desde 2021. As três métricas principais são LCP (Largest Contentful Paint, o tempo até o maior elemento da página aparecer), CLS (Cumulative Layout Shift, a estabilidade visual durante o carregamento) e INP (Interaction to Next Paint, a velocidade de resposta a interações do usuário).
Sites WordPress mal otimizados reprovam consistentemente no LCP por causa de imagens sem lazy loading, fontes bloqueantes e TTFB alto em hospedagens compartilhadas baratas.
Reprovam no CLS porque plugins de anúncio e pop-up inserem elementos após o carregamento inicial, deslocando o conteúdo. Reprovam no INP porque o JavaScript pesado do pagebuilder ocupa a thread principal por tempo demais.
Isso tem impacto real no tráfego orgânico. Um site que reprova nos Core Web Vitals perde posições para concorrentes que passam, mesmo com conteúdo equivalente.
A solução não é necessariamente migrar de plataforma. É resolver os problemas técnicos que causam as reprovações.
Em muitos casos isso significa trocar o pagebuilder, otimizar imagens, mudar de hospedagem e remover plugins desnecessários. Em outros casos, quando a arquitetura está muito comprometida, pode fazer mais sentido reconstruir.
Segurança: o elefante na sala
WordPress é o CMS mais atacado do mundo. Não porque é o mais vulnerável, mas porque é o mais popular. Atacar WordPress em escala faz sentido estatístico para quem opera botnets.
A maioria dos ataques bem-sucedidos em WordPress exploram três vetores: plugins desatualizados com vulnerabilidades conhecidas, temas nulled (pirata) com backdoors embutidos e senhas fracas sem autenticação em dois fatores.
Um WordPress com plugins atualizados, temas de fontes confiáveis, autenticação em dois fatores ativada e um firewall de aplicação como o Cloudflare na frente é razoavelmente seguro para a maioria dos usos. O problema é que essa configuração requer atenção constante. Plugins lançam atualizações de segurança regularmente. Uma instalação negligenciada por seis meses já está vulnerável.
Plataformas como Next.js hospedadas na Vercel ou sites estáticos no Cloudflare Pages têm uma superfície de ataque muito menor simplesmente porque não têm banco de dados exposto, não têm painel administrativo acessível publicamente e não dependem de plugins de terceiros com histórico variável de segurança.
Isso não é argumento para migrar todo mundo, mas é um fator real que precisa entrar na equação.
Quando o WordPress ainda é a melhor escolha
Para a maioria dos negócios brasileiros de pequeno e médio porte, o WordPress continua sendo a opção mais prática por razões concretas.
O ecossistema de plugins resolve problemas reais sem desenvolvimento customizado. Precisa de formulário de contato, loja virtual, área de membros, integração com sistema de pagamento, galeria de fotos ou agendamento online? Existe plugin para isso, testado por milhões de usuários, com suporte ativo.
A curva de aprendizado para o cliente é menor. O painel do WordPress é familiar para quem nunca viu código.
Atualizar um post, trocar uma imagem ou adicionar uma página nova é acessível para qualquer pessoa com treinamento básico. Isso reduz a dependência do desenvolvedor para tarefas do dia a dia.
A comunidade é a maior do mundo para qualquer CMS. Mais documentação, mais tutoriais, mais desenvolvedores disponíveis, mais soluções para problemas específicos.
E-commerces com WooCommerce, blogs, sites institucionais, portfólios, landing pages e sites de serviços locais funcionam bem no WordPress quando há manutenção de sites WordPress feita de forma consistente.
Atualizar plugins, monitorar segurança, ajustar performance, fazer backups regulares e revisar o payload periodicamente não são opcionais. São a diferença entre um site que trabalha pelo negócio e um site que vira problema.
Quando faz sentido migrar?
Migrar tem custo. Custo financeiro, custo de tempo, custo de risco de perda de tráfego durante a transição e custo de reaprendizado para a equipe.
Não faz sentido migrar só porque a tecnologia é mais nova ou porque alguém disse que WordPress é ruim.
Mas existem cenários onde a migração é a decisão tecnicamente correta.
Quando a performance chegou num ponto em que não tem mais como melhorar sem refazer a arquitetura.
Quando o site cresceu a um ponto de complexidade que o WordPress não gerencia com eficiência. Quando o projeto exige renderização no servidor com lógica complexa que Next.js ou Nuxt.js entregam melhor.
Quando a segurança é crítica e a superfície de ataque menor de um site estático ou headless faz diferença concreta.
Quando o cliente quer controle total do código sem dependência de plugins de terceiros com atualizações que podem quebrar funcionalidades existentes.
Em projetos que exigem alta performance de SEO com conteúdo dinâmico, Astro.js entrega resultados excepcionais porque gera HTML estático por padrão e só hidrata JavaScript onde for necessário.
Em aplicações web com muita interatividade, Next.js com React é mais adequado do que WordPress forçado a ser aplicação via plugins.
Nesses casos, migrar pode ser a decisão mais econômica no médio prazo. Um desenvolvedor freelancer especializado em desenvolvimento web consegue avaliar a situação atual, mapear os custos reais de cada caminho e indicar se a migração vale o investimento ou se a otimização do que existe resolve com menor custo e menor risco.
O custo real de cada decisão
Uma migração mal planejada pode custar mais caro do que anos de manutenção do WordPress. URLs que mudam sem redirecionamento correto destroem ranqueamento construído ao longo de anos.
Funcionalidades que existiam em plugins precisam ser reconstruídas do zero. O cliente precisa reaprender a operar o sistema. A equipe precisa dominar a nova tecnologia.
Por outro lado, manter um WordPress tecnicamente comprometido também tem custo. Custo de hospedagem mais cara para compensar a ineficiência.
Custo de desenvolvedor para apagar incêndios recorrentes. Custo de oportunidade de um site lento que converte menos.
A decisão certa depende do contexto específico de cada projeto, não da tendência de mercado.
O que o WordPress vai ser nos próximos anos
O WordPress não vai desaparecer. A base instalada é grande demais, o ecossistema é maduro demais e o problema que ele resolve é real demais.
O que vai acontecer é o que já está acontecendo: WordPress vai continuar dominando sites de conteúdo, blogs, portfólios e e-commerces de pequeno e médio porte.
Tecnologias modernas vão continuar ganhando espaço em aplicações mais complexas, projetos de alta performance e sistemas que precisam de menor dependência de plugins.
Os dois mundos vão coexistir. Não porque um não derrotou o outro, mas porque atendem necessidades diferentes.
Alguém vai continuar declarando o WordPress morto. Provavelmente já está escrevendo o artigo enquanto você lê esse texto.
