Como monitorar seu próprio site para detectar alterações inesperadas

Num domingo à tarde em setembro de 2022, um invasor acessou o gerenciador de conteúdo (CMS) da Fast Company e substituiu todas as manchetes da página inicial por uma mensagem obscena e racista. A equipe tirou o site do ar e conseguiu restabelecê-lo cerca de duas horas depois. Dois dias depois, o mesmo invasor disparou mensagens semelhantes aos seguidores da Fast Company no Apple News, e o portal acabou ficando fora do ar por oito dias.

Essa é a versão extrema. No dia a dia, o problema ocorre de forma mais sutil. Um deploy coloca em produção um componente de preços que renderiza uma tabela vazia. Um editor do CMS publica um rascunho com texto provisório (placeholder) no hero. Alguém restaura a política de privacidade do ano passado ao corrigir um simples erro de digitação. Ninguém recebe alerta no plantão, porque o servidor está online e todas as páginas carregam perfeitamente.

Eu trabalho no Page Deltas, uma ferramenta que a maioria das equipes usa para monitorar os sites de outras empresas. Este artigo explica como apontá-la para o seu próprio site: quais páginas acompanhar, como orientar o filtro de IA para que ele entenda o que está errado, como acionar uma verificação logo após cada deploy e onde terminam as capacidades da ferramenta.

Por que suas outras ferramentas não percebem isso

A maioria dos sites já conta com um monitor de disponibilidade (uptime). Ele faz apenas uma pergunta: a página responde? E uma página inicial desfigurada por defacement responde perfeitamente. O mesmo vale para uma página de preços com uma tabela quebrada. Verificações de uptime são excelentes para avisar que a luz apagou, mas não conseguem dizer se alguém repintou as paredes.

As ferramentas no servidor têm um ponto cego diferente. Um monitor de integridade de arquivos observa seus arquivos locais, portanto não perceberá quando um script de terceiros (um widget de chat, um gerenciador de tags, um código de anúncio) alterar o que os visitantes veem. Também não perceberá um sequestro de DNS, onde seu domínio aponta para outro servidor enquanto os seus continuam intactos. O guia sobre defacement de sites do Visualping destaca exatamente isso, e eles estão certos: a detecção precisa analisar o que a página efetivamente exibe ao visitante.

É exatamente isso que um monitor de alterações em sites faz. Ele busca a página pelo lado de fora, da mesma forma que um visitante faria, e a compara com a última checagem. A pergunta passa a ser: "esta página mudou de uma forma que nós não planejamos?"

Quais páginas você deve monitorar?

Você não precisa monitorar o site inteiro. Comece pelas páginas em que uma alteração indevida destrói receita ou confiança mais rapidamente, e onde um visitante provavelmente perceberia antes de você.

As quatro primeiras linhas são monitores de página. A última é um monitor de sitemap, que alerta quando novas URLs surgem no seu sitemap.xml. Isso ajuda contra um tipo muito específico de ataque: aquele que cria silenciosamente centenas de páginas de spam no seu domínio, desde que o seu CMS inclua essas páginas no sitemap.

O plano gratuito oferece 10 URLs monitoradas, e um monitor de sitemap conta como uma. Isso cobre sua página inicial, página de preços, três landing pages principais, duas páginas jurídicas e o sitemap, restando duas vagas livres.

Configurando o monitoramento

A configuração é a mesma do nosso guia para monitorar alterações em sites, com uma diferença: você descreve o que nunca deveria acontecer, em vez do que espera ver.

1. Adicione suas páginas com um brief

Crie uma conta gratuita, clique em New monitor (Novo monitor) e cole a URL. O campo de descrição é o prompt que nosso LLM lê para decidir se uma alteração é relevante: escreva-o como um bilhete para um colega que estivesse vigiando a página para você.

Para a sua própria página inicial, uma instrução como esta funciona muito bem:

Nossa própria página inicial (example.com). Dificilmente a alteramos fora de um deploy.
Avise-me sobre qualquer alteração no título principal, texto do hero, chamada para ação (CTA)
ou preços. Avise-me se surgir texto sem relação com nosso produto, ofensivo ou em um idioma
que não publicamos.
Ignore os logotipos rotativos de clientes e o bloco de últimos artigos do blog.

A linha de exclusão faz mais diferença do que parece. Toda página tem um elemento dinâmico que muda sozinho: se você não o nomear, passará a primeira semana recebendo alertas sobre ele.

2. Envie os alertas para dois destinos diferentes

Abra Channels (Canais) e configure os destinos. Slack, Discord e Microsoft Teams utilizam a URL de um webhook de entrada. Para o e-mail, o destinatário precisa primeiro confirmar uma mensagem de verificação, e um webhook assinado pode alimentar seus próprios sistemas. Clique em Send test (Enviar teste) em cada um para garantir que as mensagens cheguem.

Para o seu próprio site, recomendo vincular dois canali de tipos distintos, como Slack e um alias de e-mail para a pessoa de plantão. Cada alerta é disparado uma única vez por canal, sem repetições automáticas: dispor de um segundo canal garante que uma instabilidade no Slack não esconda uma página inicial invadida.

3. Faça uma checagem logo após cada deploy

Você não define uma frequência fixa de checagem no Page Deltas. O agendamento é adaptativo: páginas com mudanças frequentes são verificadas mais vezes e páginas estáveis com menor frequência, com prioridade para os planos pagos em momentos de fila cheia. Sua página inicial costuma ser bastante estável, o que é o oposto do que você deseja logo após alguém alterá-la.

A solução é disparar a verificação manualmente. Cada monitor possui o botão Check now (Verificar agora), e essa mesma ação está disponível via API, permitindo que você adicione uma chamada ao final da sua esteira de deploy:

curl -X POST \
  -H "Authorization: Bearer $PAGEDELTAS_TOKEN" \
  https://api.pagedeltas.com/api/monitors/$MONITOR_ID/check-now

Verificações manuais são limitadas a uma por minuto por monitor, o que é mais do que suficiente para deploys. Você gera a chave em Settings (Configurações) e depois API keys (requer função de editor ou admin). Ela é exibida apenas uma vez, então guarde-a diretamente nos secrets da sua CI. Nosso artigo sobre como transformar qualquer site em uma API de alterações aborda o restante da API caso você também queira automatizar a criação de monitores.

O que fazer quando um alerta chegar

Com o sistema ativo, qualquer alteração significativa gera uma mensagem única com um resumo em linguagem clara e capturas de tela de antes e depois. Se você usar o webhook assinado, o payload terá esta estrutura (valores fictícios para o exemplo):

{
  "event": "change.detected",
  "monitor_id": "01HW2X...",
  "monitor_url": "https://example.com/pricing",
  "monitor_name": "Nossa página de preços",
  "change_id": "...",
  "detected_at": "2026-10-08T07:12:00Z",
  "summary": "Os planos Pro e Business não aparecem mais. A tabela de preços agora exibe apenas o plano Free.",
  "before_screenshot_url": "https://.../before.png",
  "after_screenshot_url": "https://.../after.png",
  "dashboard_url": "https://app.pagedeltas.com/monitors/..."
}

A maioria dos alertas no seu próprio site será de alterações feitas pela sua própria equipe. Isso é normal e útil: uma resposta rápida no tópico como "fomos nós, subiu hoje" transforma o canal em um histórico contínuo do que entrou no ar e quando. O alerta crítico é aquele que ninguém da equipe reconhece.

Quando isso acontece, os prints ajudam de duas formas: mostram exatamente o que os visitantes estão vendo naquele momento e servem como registro com data do ocorrido, algo que sua equipe de segurança ou seguradora pode solicitar mais tarde. O histórico é mantido por 14 dias no plano Free e por mais tempo nos planos pagos (30 dias no Starter, até 730 no Scale); faça o download de tudo o que precisar arquivar.

Às vezes, o primeiro sinal de alerta não vem de uma notificação técnica, mas de um cliente postando um print nas redes sociais. Se você também quiser ser avisado sobre isso, nosso produto irmão KWatch.io envia alertas sempre que o nome da sua marca for mencionado no Reddit, X, LinkedIn, Facebook e Hacker News.

Onde a ferramenta para

Existem alguns cenários que essa configuração não cobrirá, e é importante conhecê-los antes de depender totalmente dela.

Nós comparamos o texto principal de cada página. Menus de navegação, rodapés e anúncios são removidos antes da análise, portanto um link de spam injetado no seu rodapé não será detectado. O mesmo vale para uma alteração puramente visual, como a troca da imagem do logotipo sem qualquer alteração no texto.

A ferramenta também não substitui um monitor de uptime. Se o seu site cair, as checagens falham em vez de alertar, e após 10 falhas consecutivas o monitor é pausado automaticamente e os administradores são notificados. Esse tempo é lento demais para uma queda de infraestrutura: mantenha seu monitor de uptime tradicional para essa finalidade.

Entre deploys, uma alteração é detectada na próxima checagem agendada, sem um intervalo fixo garantido. Se você precisa de checagens garantidas a cada poucos minutos em uma página essencial, o Visualping permite configurar a frequência por página e é mais indicado nesse caso. Além disso, analisamos apenas páginas públicas: qualquer conteúdo protegido por login permanece inacessível.

Por fim, o Page Deltas avisa que algo mudou. Ele não dirá como o invasor conseguiu entrar: esse papel continua sendo das suas ferramentas de segurança dedicadas.

Comece pela sua página inicial

Adicione primeiro sua página inicial e a de preços, adapte o brief acima com suas próprias regras de exclusão e envie um alerta de teste para ambos os canais. Em seguida, inclua a chamada check-now no seu script de deploy. O plano Free cobre 10 URLs ou sitemaps com filtragem por IA, todos os cinco canais de alerta e acesso à API, sem exigir cartão de crédito. Comece a monitorar gratuitamente.

Julien, Gerente de Produto no Page Deltas