Auditor de Saúde do Site WP

Quando Usar Esta Habilidade

• O usuário cola um relatório de Saúde do Site do WordPress (Tools > Site Health), como texto ou captura de tela
• O usuário cola informações de depuração brutas da Saúde do Site (Tools > Site Health > Info) e pergunta o que está errado
• O usuário menciona "saúde do site", "melhorias recomendadas" ou "problemas críticos" para um site WordPress
• O usuário pede para limpar, proteger ou acelerar uma instalação WP com base nessa tela

Transforma um relatório de Saúde do Site do WordPress (Problemas críticos / Melhorias recomendadas / Testes aprovados) em um plano de correção priorizado e com níveis de risco — em seguida, executa as correções seguras e entrega o restante com comandos ou código exatos.

⚠️ Segurança — leia antes de tocar em qualquer arquivo

Esta habilidade edita configurações equivalentes a wp-config.php, .htaccess e php.ini, e exclui plugins e temas. Todas as três estão a um erro de edição de distância de uma tela branca da morte ou de um caminho de upload quebrado. Nunca pule esta seção, mesmo para uma alteração de uma linha, mesmo que o usuário esteja com pressa.

Antes de qualquer edição ou exclusão, nesta ordem:

1. Faça backup do(s) arquivo(s) específico(s) que você está prestes a tocar fora da raiz da web, não apenas "tenha um backup em algum lugar":

   umask 077
   backup_dir="../wp-site-health-backups/$(date +%Y%m%d-%H%M%S)"
   mkdir -p "$backup_dir"
   cp -p wp-config.php "$backup_dir/wp-config.php"
   cp -p .htaccess "$backup_dir/.htaccess"
   

   Se o acesso ao shell não estiver disponível, diga ao usuário para baixar o arquivo atual via SFTP/gerenciador de arquivos do host primeiro, e não prossiga até que ele confirme que o tem.
2. Confirme se existe um backup completo do site/banco de dados antes de excluir qualquer plugin ou tema, ou executar wp search-replace. Se o usuário não tiver um e tiver um plugin de backup ativo (UpdraftPlus, etc.), ative um backup primeiro: wp updraftplus backup ou o comando WP-CLI próprio do plugin, ou diga a ele para clicar em "Fazer Backup Agora" e esperar a confirmação antes de continuar.
3. Nunca execute wp search-replace sem --dry-run primeiro, e sempre mostre a saída do teste de execução (dry-run) para o usuário antes de executá-lo de verdade. Este comando reescreve o banco de dados no local — um padrão incorreto pode corromper dados serializados em todas as tabelas que ele toca.
4. Após qualquer edição de arquivo PHP, verifique a sintaxe (lint) antes de recarregar o site:

   php -l wp-config.php
   

   Para alterações em .htaccess, execute apachectl configtest se disponível, ou verifique o site imediatamente. Um erro de sintaxe em wp-config.php derruba o site inteiro imediatamente. Não pule a verificação de sintaxe para economizar uma etapa.
5. Altere uma coisa de cada vez, depois verifique se o site ainda carrega (página inicial + wp-admin) antes de fazer a próxima alteração. Não agrupe várias edições de arquivo de Nível 2 em uma única passagem — se algo quebrar, você quer saber qual alteração fez isso.
6. Forneça ao usuário o comando exato de reversão junto com cada edição:

   cp ../wp-site-health-backups/<timestamp>/wp-config.php wp-config.php
   

   Declare isso mesmo que nada dê errado — custa uma linha e salva um usuário em pânico mais tarde.

Se o usuário disser "faça logo, pule o backup" — ainda crie o backup silenciosamente como parte da sequência de edição e diga a ele que você o fez. Recuse-se a pular a etapa 1 ou 4 inteiramente; essas duas são inegociáveis independentemente da urgência, pois o modo de falha (wp-config.php corrompido, site inoperante) é pior do que os dez segundos que um backup custa.

Visão Geral

A tela de Saúde do Site é diagnóstica, não prescritiva. Ela informa ao proprietário do site que algo está errado (por exemplo, "você deve usar um cache de objeto persistente"), mas não como corrigi-lo, e mistura itens que são seguros com um clique (desativar um plugin) com itens que exigem alterações no nível do host (php.ini, backend de cache de objeto) ou são puramente informacionais (versão do servidor SQL — nenhuma ação necessária). Esta habilidade resolve isso — com segurança.

Fase 1 — Analisar o relatório

A entrada geralmente é uma das seguintes:

• Texto simples colado copiado de Tools > Site Health (aba Status)
• Texto simples colado de Tools > Site Health > Info (a exportação de dados de depuração)
• Uma captura de tela da aba Status
• Saída do WP-CLI (wp site-health check não é um comando principal; anote isso de imediato, não invente um — veja Fase 4)

Extraia três grupos exatamente como o WordPress os rotula:

1. Problemas críticos (vermelho) — sempre corrija primeiro, sempre confirme antes de tocar.
2. Melhorias recomendadas (amarelo) — a maior parte do trabalho real; triagem por nível de risco abaixo.
3. Testes aprovados (verde) — pule. Não "corrija" nem verifique novamente os testes aprovados, a menos que o usuário peça. Não