No inicio de 2025 o WordPress sustentava 43,6 por cento da web. Hoje esta em 41,5 por cento, e a queda esta a acelerar. A pergunta interessante nao e o numero, e para onde vai a quota. Nao vai para o Wix nem para o Shopify, que estao estagnados. Vai para sites onde a W3Techs nao deteta CMS nenhum. Josh Koenig, cofundador da Pantheon, resumiu-o em duas palavras: “e vibecoding”.
Antes de decidir se isto e um problema para o WordPress, convem sermos precisos quanto ao termo, porque esta a espalhar-se depressa e significa coisas diferentes para pessoas diferentes.
O que e o vibecoding
O vibecoding consiste em construir uma aplicacao descrevendo-a a um modelo de linguagem e aceitando o que quer que ele produza, sem ler o codigo linha a linha. As ferramentas sao o Lovable, o Bolt.new, o v0 da Vercel, o Replit Agent e o Base44. Escreve “faz uma loja com login e pagamentos” e recebe um frontend a funcionar, uma base de dados (normalmente Supabase) e o deploy em poucos minutos.
Para um prototipo, uma ferramenta interna ou uma pagina de campanha que so precisa de viver uma semana, isto e genuinamente bom. Usamos exatamente assim as nossas maquetes, para mostrar uma direcao ao cliente antes de alguem escrever codigo de producao. O problema so comeca quando esse resultado vai para producao como alicerce de um negocio.
Onde os sites feitos por vibecoding falham
Isto nao e uma defesa automatica do WordPress. E a lista do que aparece de facto quando alguem chega com o classico “funcionava, e agora deixou de funcionar”:
- Chaves no bundle. O modelo mete uma chave
service_roledo Supabase em codigo que vai para o browser. Qualquer pessoa com as ferramentas de programador do navegador consegue le-la. Ao longo de 2025, chaves expostas em aplicacoes feitas no Lovable e bases Supabase sem o Row Level Security ativo deixaram tabelas inteiras de utilizadores a descoberto. - Endpoints sem autenticacao. A instrucao “faz um painel de administracao” gera o painel, mas a rota
/api/adminnunca verifica quem esta a bater a porta. Parece que funciona porque o autor testa a coisa com a propria sessao iniciada. - Sem validacao nem limites. Um formulario de contacto sem rate limiting e sem sanitizacao torna-se uma porta aberta ao envio de spam e a tentativas de injecao.
- Invisivel na pesquisa. Conteudo renderizado apenas no cliente, sem renderizacao no servidor, e uma pagina vazia para o Googlebot. Um catalogo de produtos que nao existe no HTML nao entra no indice.
- Zero caminho de manutencao. Sem migracoes de base de dados, sem backups, sem versionamento, sem pipeline. A primeira alteracao a serio implica reescrever de raiz, porque ninguem, incluindo quem escreveu a instrucao, sabe por que razao aquilo foi construido daquela maneira.
Dois casos concretos dos ultimos meses. Uma startup de Lisboa montou o painel de cliente no Bolt.new e lancou numa semana. Duas semanas depois, os utilizadores viam e editavam dados de contas alheias, porque a chave anon do Supabase estava no codigo e o Row Level Security nunca tinha sido ativado. Noutro caso, uma loja online do Porto foi levantada em v0. Bonita, rapida, e ao fim de tres meses com trafego zero vindo do Google, porque o catalogo inteiro so renderizava no browser. Os dois sites pareciam impecaveis no dia de lancamento. E essa a armadilha do vibecoding: a demonstracao e perfeita, e a fatura chega mais tarde.
Como reconhecer um site feito por vibecoding
Nao e preciso ter acesso ao codigo. Bastam alguns sinais:
- Ver o codigo-fonte (Ctrl+U) mostra um
<body>quase vazio e um unico ficheiro grande de JavaScript. O conteudo so aparece depois de o script carregar. - Desligar o JavaScript deixa uma pagina em branco em vez de texto.
- No Google, o site nao tem paginas para alem da inicial, mesmo que no browser se vejam varias.
- Sem pagina de login no dominio proprio, ou um painel apoiado por inteiro num servico externo sem permissoes configuradas.
- Os cabecalhos de resposta apontam para alojamento de preview (Vercel, Netlify) sem uma camada de aplicacao propria.
Nenhum destes pontos isolado e uma sentenca. Juntos, desenham um site que saiu de uma instrucao e nunca teve alicerces.
Vibecoding vs WordPress em producao
| Criterio | Site feito por vibecoding | WordPress conduzido por um senior |
|---|---|---|
| Tempo ate a primeira demonstracao | Minutos | Dias |
| Renderizacao para SEO | Normalmente no cliente | HTML no servidor |
| Controlo de acessos | Inexistente por omissao, tem de ser acrescentado | Papeis e permissoes no nucleo |
| Caminho de manutencao | Sem migracoes nem backups | Atualizacoes, copias, pipeline |
| Evolucao ao fim de um ano | Muitas vezes reescrever de raiz | Iteracao sobre o codigo existente |
| Responsabilidade pelas falhas | Difusa | Um engenheiro que conhece o codigo |
A tabela nao diz que o vibecoding e mau. Diz para que serve cada ferramenta. Para testar uma ideia num fim de semana, o vibecoding ganha sem discussao. Para um site que tem de faturar daqui a um ano, ganham os alicerces.
Porque este nao e o fim do WordPress
A quota esta a cair porque a base do mercado, os sites simples que antigamente se faziam em WordPress “por defeito”, esta mesmo a migrar para a IA. E ainda bem. Era a parte menos rentavel e mais descartavel do mercado. O WordPress esta a perder o trabalho com que, de qualquer forma, ninguem ganhava dinheiro.
O que fica e o resto: lojas WooCommerce com faturacao real, sites multilingues com hreflang correto, projetos sujeitos ao RGPD, trabalho pensado para durar cinco anos e sobreviver a uma duzia de atualizacoes. O vibecoding nao chega la, porque la a tarefa nao e gerar um ecra. E um alicerce: seguranca, desempenho que se mede em Core Web Vitals, manutencao e responsabilidade pelo que acontece as duas da manha no pico da Black Friday.
O WordPress nao ganha por estar na moda. Ganha por ter duas decadas de ecossistema, um caminho de manutencao previsivel e uma pessoa que sabe por que razao algo foi construido daquela maneira.
Quando o vibecoding faz sentido, e quando ligar a um senior
Sem rodeios: para um prototipo, um MVP, uma ferramenta interna ou uma pagina de campanha, faca vibecoding a vontade. Rapido, barato, suficiente. Para uma loja, um site institucional, ou qualquer coisa que tenha de faturar e continuar a existir daqui a um ano, e preciso um alicerce, nao um ecra gerado.
Se ja tem um site construido por IA e algo esta a comecar a falhar, desde fugas de dados a perda de trafego ate ao “nao conseguimos evoluir isto”, costuma ter solucao, mas nao com mais uma instrucao. Recuperamos sites feitos por IA: auditoria de seguranca, SEO de raiz e uma decisao sobre o que reescrever e o que aproveitar. O trabalho e feito por um desenvolvedor que le o codigo que ninguem tinha lido antes.
