O lento afastamento do WordPress

O WordPress é um dos grandes sucessos do código aberto. Começou como ferramenta para blogs e cresceu até virar o software por trás de uma grande parte da web, livre para usar, livre para modificar, com um ecossistema de temas, plugins e hospedagens que permite a quase qualquer pessoa publicar.

Como agência, construímos e mantivemos sites em WordPress durante anos, e muitos bons sites ainda rodam nele. Isto não é um obituário. Mas três coisas mudaram ao mesmo tempo, e uma empresa que roda seu site em WordPress deveria conhecer as três: a participação virou, o risco está nos plugins, e a liderança do projeto passou dois anos em uma disputa que agora vai para um júri.

A participação virou

A W3Techs, que acompanha a tecnologia por trás dos sites, mostra o WordPress subindo durante a maior parte de uma década: de 23,3 por cento de todos os sites no início de 2015 para 43,2 por cento no início de 2022. Depois a curva se achatou. Estava em 43,6 por cento em janeiro de 2025 e em 43,0 por cento em janeiro de 2026. Em 12 de outubro de 2026, o número era 40,1 por cento.

Isso ainda é mais do que todos os outros sistemas de gestão de conteúdo juntos, e 58,6 por cento dos sites cujo sistema a W3Techs consegue identificar. Mas a direção é nova. No mesmo período, o Shopify cresceu de 4,7 para 5,4 por cento de todos os sites e o Wix de 3,3 para 4,2 por cento, enquanto o Joomla e o Drupal continuaram encolhendo. Contagens como essas dependem do método, então a direção importa mais do que a casa decimal.

O risco está nos plugins

O núcleo do WordPress está em boa forma. A Patchstack, empresa de segurança que acompanha o ecossistema, contou apenas seis vulnerabilidades no núcleo do WordPress em 2025, todas de baixa prioridade.

O ecossistema em volta é outra história. A Patchstack contou 11'334 novas vulnerabilidades em todo o WordPress em 2025, 42 por cento a mais do que em 2024. Do total, 91 por cento estavam em plugins e 9 por cento em temas. Em 46 por cento dos casos, o desenvolvedor não tinha correção pronta quando a falha foi divulgada. E, nas falhas que os atacantes mais visaram, o tempo mediano entre a divulgação e a exploração em massa foi de cinco horas.

A Patchstack vende proteção justamente contra isso, então o enquadramento dela merece o cuidado de sempre. O padrão, porém, é estrutural. O site de uma empresa muitas vezes roda muitos plugins de muitos autores, cada um com seu próprio ritmo de atualização, sua própria qualidade e seu próprio modelo de negócio. Cada um deles é código no servidor público. Mantê-los atualizados é um trabalho semanal, e as semanas em que ele fica de lado são as que importam.

Dois anos de turbulência

Em setembro de 2024, na conferência WordCamp US, Matt Mullenweg, CEO da Automattic e figura principal do projeto WordPress, pediu à comunidade que parasse de pagar a WP Engine, uma das maiores empresas de hospedagem de WordPress. Em um post publicado em seguida, chamou a empresa de “câncer” do WordPress. Mullenweg tinha exigido royalties pelo uso da marca WordPress: 8 por cento da receita bruta mensal da WP Engine.

Em 25 de setembro, o WordPress.org bloqueou o acesso da WP Engine aos seus recursos, o que quebrou as atualizações de plugins e temas de alguns dos sites que ela hospedava. Em outubro, a WP Engine processou a Automattic e Mullenweg, e o WordPress.org assumiu o controle do Advanced Custom Fields, um plugin popular mantido pela WP Engine. Em dezembro, uma juíza federal concedeu uma liminar que restabeleceu o acesso da WP Engine e devolveu o plugin.

O que veio depois prejudicou mais o projeto do que a empresa de hospedagem. Em janeiro de 2025, a Automattic reduziu sua contribuição prometida ao WordPress para cerca de 45 horas por semana, contra cerca de 2'560, para direcionar recursos à briga judicial. Em abril, demitiu 16 por cento dos funcionários, e o WordPress disse que a 6.8 seria a última grande versão de 2025. No fim de maio, a Automattic voltou atrás e retornou ao núcleo. Em junho, a Linux Foundation lançou o FAIR, um repositório federado de plugins e temas, projetado para que nenhuma fonte única controle as atualizações.

O caso está longe de terminar. Em 24 de setembro de 2026, a juíza reabriu as alegações antitruste da WP Engine, que ela tinha rejeitado um ano antes, e concluiu que a Automattic e Mullenweg não são donos nem titulares registrados das marcas WordPress que alegaram. A maior parte das reconvenções da Automattic também segue de pé. Um julgamento com júri de dez dias está marcado para outubro de 2027.

O que isso significa para uma empresa no WordPress

Nada disso torna um site em WordPress inseguro da noite para o dia. Uma instalação bem cuidada, com poucos plugins, uma boa hospedagem e um responsável nomeado pelas atualizações, pode servir a uma empresa por anos. Para um blog, um pequeno site institucional ou uma equipe que conhece bem a plataforma, ficar costuma ser a escolha sensata.

O que os últimos dois anos mostraram é a dependência. As atualizações de um site, seus plugins e a confiança na sua cadeia de suprimentos passam por um único repositório, e por um tempo as decisões sobre esse repositório foram tomadas dentro de uma disputa comercial. Some a isso um ecossistema em que quase metade das novas falhas se torna pública antes de ser corrigida, e a pergunta já não é se o WordPress funciona. É quanto do site uma empresa quer apoiar em peças que ela não controla.

Sites compilados com um CMS por cima

É por isso que mais empresas migram para sites compilados: um site gerado a partir de código em páginas rápidas, com um sistema de gestão de conteúdo por cima para as pessoas que o editam. O site público, então, não tem plugins nem login de administração para atacar. Cada mudança passa por uma build que é testada antes de ir ao ar. O conteúdo fica em arquivos que são da empresa, não em um banco de dados moldado por um fornecedor.

A contrapartida é real. Um site compilado precisa de desenvolvedores para novas funcionalidades, enquanto o WordPress tem um plugin para quase tudo. E a edição precisa ser bem construída, ou a equipe de marketing vai sentir falta do antigo painel de administração em uma semana.

É para esse problema que o Studio foi feito. Seu núcleo é um CMS sobre sites construídos em Next.js, Vite ou TanStack, sem plugins e sem PHP no site público. Cada publicação é verificada, construída uma vez, testada, colocada no ar, conferida e revertida automaticamente se algo falhar, e cada publicação registra o conteúdo em commit no repositório da própria empresa. Os editores clicam em uma palavra para alterá-la e veem a página ao vivo. O Studio está em acesso antecipado.

As máquinas podem assumir as builds, os testes e as reversões. O que uma página diz, e se ela está boa o bastante para ir ao ar, fica com as pessoas que respondem por ela.

Por onde começar

Conte seus plugins e anote quem mantém cada um, quando foi atualizado pela última vez e o que faz. Remova o que ninguém precisa. Garanta que todo plugin, inclusive os pagos, receba suas atualizações, e que uma pessoa nomeada os verifique toda semana. Exporte seu conteúdo uma vez e veja se você conseguiria migrá-lo se precisasse.

Depois, decida de propósito. Mantenha o WordPress onde ele serve a você, com menos peças e um responsável claro. Onde o site é central para o negócio, um site compilado com um CMS por cima merece uma conversa.