| Camada | Ferramenta | Sinal de alerta |
|---|---|---|
| PHP e servidor | Site Health (aba Status) | Versão abaixo de PHP 8.1 |
| Agendamentos | WP-CLI cron event list | wp-cron sem disparo ha 24h |
| Segurança | FULL Scan / CVE | Plugin com CVE ativo |
| Backup | UpdraftPlus / log | Último backup ha mais de 7 dias |
| Disponibilidade | Monitor de uptime | Resposta acima de 800 ms |
Legenda: a aba Status agrupa os testes por severidade, mas não cobre uptime fora do horário de acesso.
--- ## Por que o health check evita 90% dos incidentes Rodar um health check de site WordPress de forma periódica antecipa a falha porque quase todo incidente grave teve um aviso ignorado antes. Segundo o relatório de sites invadidos da Sucuri (2023), 39,1% dos sites infectados rodavam um CMS desatualizado no momento da invasão. Atualização pendente não é detalhe cosmetico: é a porta de entrada. O encadeamento técnico é direto. PHP desatualizado em servidor sem auto-update, somado a um plugin com CVE publicado, abre uma porta que não gera alerta no painel padrao, e o relatório da Sucuri aponta o Elementor Pro entre os mais explorados. O administrador só descobre quando o Google marca o domínio. Na base da FULL, com 150 mil sites conectados, boa parte dos tickets de invasão vem de sites que nunca abriram a aba Status do Site Health. A detecção precoce é o que separa um update de 2 minutos de uma limpeza de malware de dois dias. --- ## Passo a passo: Como fazer o health check em 7 etapas Fazer um health check de site WordPress leva cerca de 20 minutos e cobre da tela nativa até o uptime externo. As sete etapas abaixo seguem a ordem de risco: primeiro o que derruba o site, depois o que degrada. Execute cada uma e anote o resultado; o objetivo é sair com uma lista de pendências priorizada, não com uma sensação vaga de que esta tudo bem. ### Passo 1: Abra a tela site health e leia a aba status Acesse Ferramentas > Saude do site e leia primeiro os itens em vermelho. A aba Status separa críticos, recomendados e aprovados; um aviso recorrente é "Seu site esta rodando uma versão desatualizada de PHP", classificado pelo próprio WordPress como tipo Segurança. Anote cada crítico antes de seguir. ### Passo 2: Confirme a versão do PHP na aba info Na aba Info, abra a secao Server e verifique a versão do PHP. O alvo é PHP 8.2 ou superior; versões abaixo de 8.1 já estao sem suporte de segurança. Se o número estiver vermelho, o ajuste é no painel da hospedagem, não no WordPress. Entenda o impacto em PHP no WordPress. ### Passo 3: Teste o loopback e os agendamentos do wp-cron Ainda na aba Status, confira o teste "Seu site não conseguiu completar uma requisicao de loopback". Esse teste importa porque o loopback é o que dispara os eventos agendados. Com loopback bloqueado, o cron do WordPress para, e qualquer backup ou publicação programada deixa de rodar sem erro visivel. Confirme via WP-CLI com o comando cron event list. ### Passo 4: Cheque atualizações e plugins com CVE Liste atualizações pendentes de core, tema e plugins, e cruze com vulnerabilidades conhecidas. O aviso "Você tem plugins esperando atualização" do Site Health é o gatilho. Rode o FULL Scan para descobrir se algum plugin ativo tem CVE publicado, sem instalar nada no site. ### Passo 5: Valide o último backup de verdade Não confie no agendamento: confirme que o último arquivo existe e restaura. Abra o log do UpdraftPlus ou do plugin de backup e cheque a data do último backup completo. Backup que aparece como agendado mas nunca gerou arquivo é o caso mais comum nos tickets. Detalhe a rotina em backup automático do WordPress. ### Passo 6: Meca desempenho com PageSpeed insights Rode a home e uma página interna no PageSpeed Insights e olhe LCP e TTFB. Um TTFB acima de 800 ms costuma indicar PHP lento ou ausência de cache de página, não um problema de plugin. O desempenho entra no health check porque Core Web Vitals ruim afeta ranqueamento. Aprofunde em Core Web Vitals no WordPress. ### Passo 7: Ative o monitoramento de uptime Esta é a perna que o Site Health não cobre. Configure um monitor de uptime que verifique o site a cada minuto e avise por e-mail ou WhatsApp na primeira falha. Sem isso, você só descobre uma queda quando um cliente reclama. Veja como em monitoramento de uptime do WordPress. --- ## Quando o site health nativo não basta O Site Health do WordPress resolve o diagnóstico de um site, mas trava em dois cenarios: escala e continuidade. Ele roda dentro do WordPress, então mede o estado interno num clique, e não a disponibilidade ao longo do dia. Para quem opera dez, vinte ou cem instalações, abrir a aba Status de cada uma é inviavel. A diferenca pratica aparece num exemplo de campo. Em sites com cache de página agressivo, o teste de loopback do Site Health passa, mas o wp-cron real não dispara, porque a requisicao interna volta servida pelo cache em vez de executar o evento. O sinal disso é backup agendado que para sem erro visivel: o painel diz que esta tudo certo, e o arquivo não aparece. Capturar essa falha exige um painel central de gestão de sites WordPress que leia o estado de fora, agregue varios sites e dispare alerta por exceção. --- ## A plataforma FULL como central do health check A plataforma FULL centraliza o health check de site WordPress de todos os sites conectados num único painel, em vez de exigir login em cada instalação. O plano PRO custa R$849,90 e cobre 10 sites, o que coloca o monitoramento e a gestão em torno de R$85 por site, com alerta por exceção. Dentro desse valor entram os 17 plugins do bundle, incluindo UpdraftPlus para backup, All in One Security para a camada de proteção e WP-Optimize para a limpeza de banco, exatamente as ferramentas que o health check aponta. A gente ve no suporte que o ganho real não é o desconto por licença, e sim parar de descobrir incidente pelo cliente. Para montar a operação, conheca os planos da FULL e o checklist de manutenção do WordPress que estrutura a rotina mensal. --- ## Com que frequencia rodar o health check Um health check de site WordPress completo deve rodar a cada 30 dias, com tres checagens rapidas no intervalo: atualizações semanais, log de backup semanal e uptime continuo. Sites de e-commerce ou com trafego alto pedem cadencia menor. A regra é proporcional ao risco: quanto mais o site fatura, mais barato é olhar antes de quebrar. O ponto que muda o jogo é separar o que é continuo do que é periodico. Uptime e segurança precisam de vigilancia constante, automatizada, sem depender de alguem lembrar. PHP, backup e desempenho cabem na rotina mensal do health check, com registro do resultado para comparar evolucao. Documentar cada rodada transforma o health check de tarefa avulsa em histórico, e é esse histórico que mostra, por exemplo, que o TTFB subiu de 300 ms para 700 ms ao longo de tres meses, antes que o cliente sinta.Porque o wp-cron depende de uma requisicao de loopback que pode estar bloqueada ou ser servida pelo cache. Quando o loopback não completa, o evento agendado de backup não dispara e nenhum arquivo é gerado, sem erro visivel no painel. O sinal pratico é a data do último backup parada ha mais de 7 dias. A correcao é desbloquear o loopback no servidor ou trocar o wp-cron por um cron real do sistema operacional.
Sim. A tela Site Health é nativa do WordPress desde a versão 5.2 e fica em Ferramentas > Saude do site, rodando mais de 20 testes sem nenhum plugin extra. Ela cobre PHP, loopback, HTTPS e atualizações pendentes. O único ponto que exige ferramenta externa é o uptime, porque um teste interno não consegue medir uma queda do próprio site. Para varios sites, o WP-CLI permite a mesma leitura por linha de comando.
O Site Health mede o estado interno de um site num clique; o painel de monitoramento mede continuidade de varios sites de fora. O nativo roda dentro do WordPress e não registra uma queda fora do horário de acesso. Um painel central, como o da plataforma FULL, le o estado externamente, agrega 10 ou mais sites e dispara alerta por excecao. Para um site é suficiente o nativo; para uma operação em escala, não.
A cada 30 dias para o check completo, com atualizações e log de backup verificados toda semana e uptime monitorado de forma continua. Sites de e-commerce pedem cadencia menor, porque uma falha de wp-cron num WooCommerce trava e-mails de pedido em minutos. A regra é proporcional ao faturamento: quanto mais o site gera, mais cedo vale olhar. Registrar cada rodada cria histórico para comparar TTFB e versões ao longo do tempo.
Verifica seis camadas: versão do PHP, agendamentos do wp-cron, segurança e CVEs de plugins, integridade do backup, desempenho via Core Web Vitals e disponibilidade por uptime. A tela Site Health cobre as quatro primeiras com 20 testes nativos; PageSpeed Insights cobre o desempenho e um monitor externo cobre o uptime. O resultado é uma lista priorizada de pendências, do que derruba o site ao que apenas degrada a experiência.