Verificação dos sites que (sua empresa) administra. 

Execute imediatamente, sem fazer perguntas — ninguém está acompanhando.

MÉTODO
Para cada domínio da lista: WebFetch na home. Se a home responder, pegue o
LINK_INTERNO retornado e faça WebFetch nele também (confere se páginas
internas abrem).

Use este prompt em cada WebFetch:
"Responda curto, em 4 linhas: STATUS: OK ou PROBLEMA. TITULO: título da
página. PROBLEMAS: liste se houver erro de banco de dados, 'account
suspended', erro crítico do WordPress, texto de invasão ('hacked by'), spam
(cassino/apostas/farmácia/adulto), página vazia ou redirecionamento para
domínio estranho; senão escreva 'nenhum'. LINK_INTERNO: uma URL completa de
página ou notícia interna."

CONSIDERE PROBLEMA
Erro de banco de dados, "account suspended", erro crítico do WordPress, HTTP
500/502/503, defacement, spam injetado (marsbahis, jojobet, casibom,
betpark, tipobet, bets10, plinko, aviator e similares), página praticamente
vazia, redirecionamento para domínio externo desconhecido, título da aba
trocado por spam ou sem o nome do site.

REGRA OBRIGATÓRIA — CONFIRMAR ANTES DE ALERTAR (cache-buster)
Se qualquer página vier com spam, NÃO alerte ainda. Refaça a MESMA URL com um
parâmetro único (ex.: ?nocache=chk2) e compare:
- Suja SEM parâmetro e LIMPA COM parâmetro → é CACHE servindo HTML velho, não
  invasão. Reporte como "cache sujo", diga qual URL, sem chamar de
  comprometimento e SEM push.
- Suja NAS DUAS → injeção ativa; trate como invasão e alerte.
Sinal extra: <title> truncado ou sem o sufixo do site na versão cacheada, em
relação à versão com parâmetro, confirma HTML velho.
Mesma lógica para 403: repita uma vez com parâmetro (?v=chk1) antes de
concluir. O fetch tem cache de 15 min por URL — nunca repita a MESMA URL
esperando resultado diferente; mude o parâmetro.

LISTA: (coloque aqui a sua lista)
https://....com.br/
https://...net.br/
https://...com/
...
...


SE O WEBFETCH FOR BLOQUEADO
Se os fetches falharem com PROVENANCE_REQUIRED (aprovação interativa), não
insista mais que duas tentativas. Faça o plano B: busca `site:<domínio>` nos
18 domínios e verifique se algum título indexado virou spam de
aposta/cassino/farmácia. Deixe explícito no relatório que é sinal fraco — vê
o índice do buscador, não o site agora; não pega queda, erro de banco nem
invasão recente. Atenção: o operador `site:` não é respeitado à risca, então
resultados de outros domínios aparecem e domínio sem resultado próprio é
limitação da busca, NÃO achado sobre o site. Nesse caso envie push de alerta
avisando que o monitoramento está cego — mas no máximo UM push por dia sobre
essa falha: se o doc do projeto já registrar uma falha de
PROVENANCE_REQUIRED hoje, apenas registre no chat e no doc, sem push.

SAÍDA
1. PushNotification (status "proactive", uma linha, menos de 200 caracteres)
   APENAS se houver problema real — comece com "ALERTA:" e diga quais
   domínios. Tudo normal NÃO gera push: a rotina roda 8x por dia e
   notificação de rotina vira ruído. Cache residual sozinho também não gera
   push.
   Exceção: na rodada das 18h BRT (21h UTC), envie push de fechamento do dia
   mesmo se estiver tudo certo, no formato "Verificação OK: todos os sites
   normais".
2. Sempre escreva no chat o relatório completo: uma linha por site com
   status, e detalhamento dos que deram problema.
3. Se houver problema real (ou falha de execução), atualize o doc do projeto
   claude/verificacao-sites.md com a data e o achado.

LIÇÃO A LEMBRAR
A rotina observa HTML público de um IP estrangeiro, através de camadas de
cache que não controla. Ela serve para apontar onde olhar, não para concluir
que um site está comprometido. Conclusão de comprometimento exige
verificação no servidor.