Como monitorar links quebrados no WordPress com n8n e Telegram
Neste artigo mostro como montei um workflow no n8n para monitorar links quebrados de um site WordPress e enviar um alerta pelo Telegram quando algum endereço apresenta erro.
A ideia surgiu de um problema simples: em um site que publica conteúdo com frequência, verificar manualmente todos os links e URLs rapidamente deixa de ser uma tarefa prática.
Em vez de abrir página por página, podemos usar o sitemap do próprio WordPress como fonte de URLs e deixar o n8n fazer a verificação automaticamente.
Este fluxo foi implementado como parte da infraestrutura do Radar Apostas, um projeto em WordPress no qual diferentes processos de publicação, monitoramento e manutenção são automatizados. A necessidade surgiu justamente para verificar periodicamente se as URLs já publicadas continuavam acessíveis sem depender de verificações manuais.
O problema
Sites WordPress podem acumular URLs com problemas por vários motivos:
- uma página foi removida;
- um artigo teve o slug alterado;
- um link externo deixou de existir;
- uma página passou a retornar erro 500;
- uma URL foi configurada incorretamente;
- uma estrutura de links foi alterada durante uma manutenção.
O problema é que nem sempre esses erros são percebidos imediatamente.
Um link quebrado pode continuar existindo durante semanas até que alguém encontre o problema manualmente.
Por isso, a proposta deste workflow é simples:
verificar periodicamente as URLs do WordPress e avisar somente quando houver um problema.
Arquitetura do workflow
A estrutura que utilizei foi:
Agendamento semanal
↓
Configuração do site
↓
Sitemap Index
↓
Post Sitemap
↓
Parser XML
↓
Separação das URLs
↓
Verificação HTTP
↓
É um link quebrado?
/ \
Não Sim
↓ ↓
fim Preparar detalhes
↓
Agrupar ocorrências
↓
Enviar alerta Telegram
A vantagem dessa abordagem é que o workflow não precisa manter uma lista manual de todos os artigos.
O WordPress já possui uma fonte centralizada de URLs: o sitemap.
1. Usando o sitemap como fonte
A primeira etapa do workflow acessa o sitemap do site.
Em instalações que utilizam um sitemap index, primeiro obtemos o índice e depois identificamos o sitemap que contém os posts.
Por exemplo:
/sitemap_index.xml
A partir daí, o workflow pode localizar o sitemap de posts.
Isso torna o processo mais fácil de manter porque novos artigos publicados no WordPress entram automaticamente no sitemap.
Não precisamos editar o workflow toda vez que um novo artigo é criado.
2. Fazendo o parsing do XML
Depois de obter o sitemap, precisamos transformar o XML em dados que o n8n consiga processar.
O objetivo é chegar a uma estrutura simples:
URL 1
URL 2
URL 3
URL 4
URL 5
...
Cada URL passa então a ser um item individual do workflow.
Essa separação é importante porque permite executar a verificação HTTP para cada endereço.
3. Verificando o status HTTP
A próxima etapa utiliza uma requisição HTTP para verificar cada URL.
O objetivo não é analisar o conteúdo da página, mas descobrir se o endereço continua respondendo corretamente.
Alguns exemplos:
200 → página disponível
301 → redirecionamento
302 → redirecionamento temporário
404 → página não encontrada
500 → erro no servidor
503 → serviço temporariamente indisponível
Nem todo código diferente de 200 significa necessariamente que existe um problema.
Por isso, em uma implementação real, é importante definir claramente quais respostas devem gerar alerta.
O workflow pode ser ajustado de acordo com a necessidade do projeto.
4. Separando os links problemáticos
Depois da verificação, utilizamos uma condição:
É Link Quebrado?
Se a resposta for negativa, o item termina normalmente.
Se for positiva, o workflow envia os dados para uma etapa específica de tratamento.
Um registro de erro pode conter informações como:
URL
Status HTTP
Tipo de erro
Data da verificação
Isso é muito mais útil do que receber apenas uma mensagem dizendo:
Existe um link quebrado.
Com os detalhes, conseguimos identificar rapidamente qual URL precisa ser analisada.
5. Agrupando os erros antes do alerta
Outro detalhe importante é evitar o envio de dezenas de mensagens consecutivas para o Telegram.
Imagine um site com 20 URLs problemáticas.
Se cada URL gerar uma mensagem individual, o resultado pode ser uma sequência desnecessária de alertas.
Por isso, o workflow primeiro coleta os problemas encontrados e depois monta uma única mensagem.
Por exemplo:
🔴 Links com problema encontrados
1. URL: /exemplo-1/
Status: 404
2. URL: /exemplo-2/
Status: 500
3. URL: /exemplo-3/
Status: 404
Total: 3 URLs
Assim, a pessoa recebe um resumo e pode investigar somente o que realmente precisa de atenção.
6. Telegram como camada de alerta
O Telegram funciona como uma camada simples de notificação.
A ideia não é transformar o Telegram em um sistema complexo de monitoramento.
Ele serve apenas para responder a uma pergunta:
Existe algum problema que precisa da minha atenção?
Se nenhuma URL apresentar problema, nenhuma mensagem precisa ser enviada.
Se houver problemas, o workflow envia o resumo.
Isso reduz bastante o ruído operacional.
7. Por que usar n8n?
Uma das razões para escolher o n8n é a facilidade para conectar diferentes serviços.
Neste caso temos:
WordPress
+
Sitemap XML
+
HTTP Request
+
Lógica de condição
+
Telegram
Cada etapa possui uma função específica.
Também é possível adicionar outras etapas posteriormente, como:
- salvar histórico das verificações;
- enviar alertas por e-mail;
- gravar resultados em uma planilha;
- enviar dados para um banco de dados;
- criar um relatório semanal;
- monitorar links externos;
- adicionar diferentes níveis de severidade.
O workflow pode começar pequeno e evoluir conforme a necessidade.
8. Teste do workflow
Durante o teste, o workflow foi executado contra as URLs disponíveis no sitemap do projeto.
Na execução de validação foram verificadas 16 URLs e nenhuma delas apresentou condição que exigisse um alerta.
Esse comportamento também é importante.
Um sistema de monitoramento não deve enviar notificações apenas para demonstrar que está funcionando.
Quando tudo está normal, o resultado esperado pode simplesmente ser:
nenhum alerta
O alerta deve aparecer quando realmente existir algo para investigar.
9. O que eu melhoraria em uma próxima versão
A versão inicial resolve o problema principal, mas existem várias possibilidades de evolução.
Uma delas seria armazenar o histórico de cada URL:
URL
Status anterior
Status atual
Primeira ocorrência
Última ocorrência
Número de falhas
Isso permitiria diferenciar um erro temporário de um problema persistente.
Outra possibilidade seria implementar diferentes níveis:
404 → atenção
500 → prioridade alta
503 → verificar novamente
301 → informação
200 → normal
Também seria possível fazer uma segunda verificação antes de enviar o alerta.
Isso ajudaria a evitar notificações causadas por uma indisponibilidade momentânea da rede ou do servidor.
10. A principal lição
O ponto mais interessante deste projeto não é apenas verificar URLs.
É utilizar uma fonte de dados que já existe e transformar uma tarefa manual em um processo automático.
Em vez de:
publicar conteúdo
↓
lembrar de verificar links
↓
abrir várias páginas
↓
procurar problemas manualmente
podemos ter:
publicar conteúdo
↓
sitemap atualizado
↓
workflow executado automaticamente
↓
URLs verificadas
↓
alerta somente quando necessário
Esse mesmo princípio pode ser aplicado a várias outras tarefas de manutenção de sites.
A automação não precisa substituir todas as decisões humanas.
Ela pode simplesmente eliminar as verificações repetitivas e deixar para a pessoa somente aquilo que realmente precisa de análise.
Conclusão
Um monitor de links quebrados é um projeto relativamente simples, mas é um bom exemplo de como o n8n pode conectar WordPress, HTTP, processamento de dados e sistemas de notificação.
O mais importante é começar com um fluxo pequeno, testar cada etapa e só depois adicionar novas funções.
Para projetos WordPress que publicam conteúdo regularmente, esse tipo de monitoramento pode ser uma forma prática de descobrir problemas antes que eles se acumulem.