Excesso de plugins: quando um build com IA o deixa com 40 plugins ativos

#Quando a lista de plugins é mais longa que o mapa do site

Se o build também incluiu PHP personalizado de um assistente de IA, combine esta auditoria com a auditoria de código de plugins WordPress gerado por IA. Quando excesso, código personalizado e perda de tráfego se somam, o trabalho encaixa na recuperação de sites feitos por IA.

#O caso anonimizado: 38 plugins, 1,47 s de TTFB

Um site de serviços B2B (formação e consultoria para indústrias reguladas no mercado português) chegou-nos depois de um stakeholder interno ter corrido Lighthouse e perguntado porque é que «o WordPress parecia lento». O site foi montado em cerca de três semanas com Cursor e ChatGPT: estrutura de páginas, rascunhos de copy, fluxos de formulários e escolhas típicas de «instala algo para isso» do diretório de plugins. Ninguém era dono da lista de plugins.

O alojamento não mudou: um VPS de 2 vCPU com um fornecedor ibérico, PHP 8.2, sem object cache na entrada. Adicionámos Redis após a passagem de plugins, o que cortou mais ~120 ms de TTFB, mas a maior parte do ganho veio de remover e fundir plugins, não de upgrades de infraestrutura.

A primeira reação do cliente foi previsível: «Só adicionámos o que precisávamos». É assim que o excesso se apresenta. Cada instalação individual tinha uma razão plausível. O custo era acumulativo.

#Como builds com IA chegam a 40 plugins mais depressa que os manuais

O excesso manual costuma crescer durante meses: um freelancer adiciona um slider, marketing um popup, alguém instala um segundo plugin SEO «só para experimentar». O excesso assistido por IA comprime o mesmo comportamento em dias porque o modelo optimiza conclusão plausível, não coerência da pilha.

Padrões recorrentes em intakes de recuperação:

1. Um prompt, um plugin. O assistente não diz «estende o teu plugin de formulários existente». Devolve um slug.
2. Sem memória de inventário. A sessão dois não sabe que a sessão um instalou Rank Math; a quatro recomenda Yoast para «melhor schema».
3. Empilhamento de tutoriais. Posts e transcrições de YouTube com que o modelo foi treinado recomendam listas de «melhores plugins para X». O build herda a lista inteira.
4. Código personalizado mais excesso comercial. O mesmo assistente que sugeriu doze plugins também gerou três plugins personalizados pequenos como «correcções rápidas», acrescentando PHP sem manutenção sobre dependências sem manutenção.
5. Plugins optimizadores como penso. Quando o TTFB sobe, o próximo prompt é «instala um plugin de cache», por vezes sem desactivar o primeiro plugin de cache.

Nada disto requer má fé nem incompetência. Requer uma lacuna de processo: ninguém com responsabilidade de arquitectura WordPress reviu a pilha antes do lançamento.

#Oito categorias que sobressaem em builds com IA

No site anonimizado, estes oito baldes representavam 31 dos 38 plugins. A sua lista será diferente, mas as categorias repetem-se em recuperações.

#1. Ferramentas SEO e schema duplicadas

Dois plugins SEO activos. Ambos emitiam schema. Ambos ligados a wp_head. Um ficou de uma migração do alojamento anterior, outro da semana do build com IA. Mantenha um. Funda definições manualmente; não confie cegamente em importadores automáticos.

#2. Vários construtores de formulários

Contact Form 7, um construtor drag-and-drop de um prompt e um plugin leve de formulário modal captavam leads em caixas distintas. A consolidação moveu três formulários para um único construtor e eliminou o resto.

#3. Plugins de cache e otimização em competição

Um plugin de cache ao nível do alojamento e um segundo «speed booster» minificavam scripts em simultâneo. Produziram JavaScript partido intermitente na página de preços. Nunca execute duas camadas completas de cache HTML. Escolha um sistema e configure-o.

#4. Excesso de analítica e píxeis

Conector GA, plugin de píxel Facebook, plugin de tag LinkedIn Insight, trial de heatmap e GTM inserido duas vezes (uma por plugin, outra por snippet no cabeçalho). A medição não melhorou. O peso dos pedidos sim.

#5. Page builder e pacotes de addons

Elementor mais pacote comercial de addons mais slider legacy deixado «por precaução». A home usava o builder; páginas internas não. Exportámos secções estáticas onde foi possível e removemos o slider por completo.

#6. Duplicados de segurança e manutenção

Dois limitadores de login, um plugin gestor de ficheiros (removido de imediato) e um «limpador de base de dados» que corria em cada carregamento do admin. A segurança pertence a uma pilha deliberada, não a três plugins sobrepostos.

#7. Ferramentas de conteúdo e imagem com IA

Um plugin escritor com IA e uma ferramenta de alt automático acrescentavam cron jobs no admin e chamadas API externas. Os fluxos editoriais passaram para o processo de redacção; os plugins saíram.

#8. mu-plugins personalizados de IA

Três ficheiros em mu-plugins/ de PHP colado: um manipulador de redireccionamentos, um «fix» de permissões REST e um ajuste de coluna no admin. Um plugin de redireccionamento duplicava regras de .htaccess. Um tweak REST desactivou uma integração que marketing usava diariamente. Após a revisão de segurança, mantivemos o ajuste de coluna como código verificado num único ficheiro mantido e eliminámos os outros dois.

#Autodiagnóstico: sinais de que está muito fundo em plugins

Execute isto antes de instalar outro optimizador.

Instale Query Monitor em staging (não em produção se a política o proibir), carregue a home sem sessão e capture o stack de consultas. Essa única vista muitas vezes envergonha o suficiente para alguém assumir responsabilidade pela pilha.

#Triagem: manter, fundir, substituir, remover

Usamos um registo de quatro colunas em cada recuperação por excesso. Cada plugin activo recebe exactamente uma etiqueta.

Manter - único dono de uma função, mantido, sem sobreposição. Exemplo: o único plugin SEO após fundir definições.

Fundir - dois plugins com trabalhos adjacentes que uma ferramenta mantida pode cobrir. Exemplo: três plugins de formulários num só.

Substituir - o trabalho do plugin é válido mas a implementação é pesada; substituir por algumas linhas em child theme ou um padrão de bloco. Exemplo: um plugin de posts relacionados com WP_Query em cada vista substituído por um bloco curado.

Remover - abandonado, duplicado, perigoso ou sem uso. Plugins gestor de ficheiros, testes SEO hello-world e ferramentas de debug «temporárias» vão aqui.

Trabalhe em lotes de cinco a oito plugins no máximo. Desactive, teste checkout e formulários, meça TTFB, depois apague. Apagamentos em massa são como a produção parte numa sexta-feira.

No site anonimizado a divisão foi assim:

• Manter: 21 plugins após consolidar (um SEO, formulários, uma cache, uma suite de segurança)
• Fundir: 9 plugins absorvidos por ferramentas mantidas
• Substituir: 4 trabalhos de plugin movidos para código de tema ou blocos
• Remover: 8 plugins apagados (incluindo 2 abandonados, 1 gestor de ficheiros, 1 cache duplicada)

#Plugins personalizados de IA continuam a ser plugins

As equipas contam frequentemente só plugins do diretório e esquecem mu-plugins ou plugins de «code snippets» que injectam PHP. Assistentes de IA adoram gerá-los porque parece mais rápido do que ensinar estrutura correcta de plugin.

Trate cada ficheiro personalizado como código de terceiros:

• Procure guards ABSPATH, nonces e $wpdb->prepare()
• Verifique se a funcionalidade duplica um plugin existente
• Mova código que sobrevive para controlo de versões, não para uma caixa de colar no wp-admin

Se encontrar nonces em falta e SQL concatenado, pare de desinstalar plugins comerciais até o código personalizado estar delimitado. PHP personalizado mau mais uma pilha comercial a encolher pode expor endpoints que ninguém recordava.

#Fluxo de consolidação em staging

1. Congele novas instalações. Nenhuma resposta de plugin até existir o registo.
2. Exporte a lista activa para uma folha: slug, versão, data da última actualização, trabalho declarado, trabalho real.
3. Assinale sobreposições em SEO, cache, formulários, analítica e segurança primeiro.
4. Desactive duplicados em staging, limpe todas as caches, teste caminhos de conversão principais.
5. Meça TTFB e contagem de consultas na home, landing mais pesada e página de agradecimento de checkout/contacto.
6. Apague em lotes pequenos, meça de novo após cada lote.
7. Documente a pilha final no README do projeto ou na entrega ao cliente, para que a próxima sessão de IA tenha um inventário para consultar.

O preço do trabalho de recuperação é sempre individual porque a contagem de plugins é apenas uma variável. O inchaço da base de dados, o código personalizado de IA e o nível de tráfego pesam tanto como o número no wp-admin.

#De quem é a licença dos plugins premium

Numa recuperação, a pergunta que trava o trabalho mais vezes não é técnica: em nome de quem foram compradas as licenças. O problema é transversal, mas no mercado português aparece com uma frequência que já não nos surpreende, porque muitos sites de PME nasceram de um tema multipropósito comprado numa marketplace pela agência ou pelo freelancer que fez o build.

O tema traz plugins agrupados, tipicamente um construtor visual e um plugin de sliders, com licença associada ao tema e não ao cliente. A agência acrescenta as suas próprias licenças de campos personalizados, formulários e caching, todas na conta dela. Depois entra um build assistido por IA, que instala versões gratuitas de coisas que já existiam em versão paga. Um ano mais tarde o cliente muda de fornecedor e descobre que metade da lista não recebe atualizações.

Não é uma questão de custo. É uma questão de superfície de ataque: um plugin premium sem licença ativa continua a funcionar e deixa de receber correções de segurança, que é o pior dos dois mundos.

Faça este inventário antes de decidir o que fica. Transfira ou volte a comprar o que sobrevive à triagem, e só depois trate a lista como uma decisão de arquitetura, porque até esse momento ela é sobretudo uma herança administrativa.

Duas notas de campo. Primeira: peça o acesso à conta onde as licenças estão registadas, não apenas as chaves, porque uma chave sem acesso à conta não permite mudar o domínio ativado. Segunda: escreva na proposta que, a partir da entrega, o titular de todas as licenças é o cliente. É uma linha de contrato que poupa a conversa difícil daqui a doze meses.

#O que não fazer

• Não instale um plugin «gestor de plugins» para corrigir o excesso. Está a adicionar outro plugin.
• Não active duas caches de página completa «por segurança».
• Não deixe um assistente de IA gerar um script de limpeza que apague linhas em massa em wp_options sem cópia de segurança e revisão diff.
• Não assuma que plugins desactivados são inofensivos. Alguns continuam a carregar código em init em estados estranhos; apague após verificação.
• Não omita testes de formulários e checkout porque «é só um blog». No caso anonimizado, o JavaScript partido estava na página de preços, não no índice do blog.

#Quando escalar para recuperação

A limpeza incremental funciona quando as sobreposições são óbvias, o código personalizado é mínimo e alguém técnico controla staging. Escale para uma recuperação de sites feitos por IA formal quando:

• Os plugins activos se mantêm acima da meia-treintena após um primeiro passe
• Vários plugins personalizados de IA tocam autenticação, uploads ou SQL
• O TTFB sem cache permanece acima de ~1 s após remover cache e SEO duplicados
• O negócio não se pode permitir um formulário ou fluxo de pagamento partido durante apagamentos sem orientação
• Scans de segurança mostram CVE conhecidos em plugins abandonados que ninguém actualizará

Recuperação não é um eufemismo de reconstrução. No caso acima, 17 plugins abandonaram a pilha e o site manteve o mesmo tema e tier de alojamento. A entrega é um registo medido, não um pitch de venda para uma plataforma nova.

#Medir sucesso para além da contagem de plugins

A contagem de plugins é um proxy. Acompanhe métricas que reflectem a experiência do utilizador:

Após consolidar, defina um orçamento de plugins: para esta classe de site, nenhum plugin novo sem retirar ou fundir um existente. Escreva essa regra no ficheiro de instruções do projeto para assistentes de IA e o próximo pedido não desfará a recuperação numa tarde.

#Glossário

• Plugin sprawl / excesso de plugins - acumulação de plugins activos com trabalhos sobrepostos até degradarem desempenho, segurança e manutenibilidade.
• TTFB (Time to First Byte) - tempo de resposta do servidor antes do browser renderizar conteúdo; sensível à contagem de hooks PHP e consultas à base.
• mu-plugin - plugin must-use carregado em cada pedido a partir de wp-content/mu-plugins/; frequentemente usado para «correcções rápidas» geradas por IA.
• Opções autoload - opções WordPress carregadas em cada pedido; inchadas por plugins que guardam arrays grandes com autoload=yes.
• Excesso de consultas - consultas excessivas à base por vista de página, habitual quando muitos plugins obtêm metadados de forma independente.

#Conclusão

Quarenta plugins de profundidade não é uma falha moral. É o que acontece quando a montagem rápida assistida por IA ultrapassa a revisão de arquitectura. O site anonimizado deste guia passou de 38 para 21 plugins activos, mediana de TTFB sem cache de 1,47 s para 0,68 s, e consultas na home de 187 para 94 sem mudar de alojamento nem reconstruir o tema. O trabalho foi tedioso, mensurável e na maior parte desinstalações.

Comece pelo registo, elimine camadas duplicadas de SEO e cache, audite ficheiros personalizados de IA antes de celebrar apagar plugins comerciais, e meça após cada lote. Se a pilha continuar a resistir, é para isso que serve a recuperação de sites feitos por IA: uma divisão manter-reescrever-remover com números anexos, não outra recomendação de plugin. Só desempenho: Core Web Vitals resgate para sites WordPress feitos com IA.