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.

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 TelegramA 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 fonteA 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.xmlA 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 XMLDepois de obter o sitemap, precisamos transformar o XML em dados que o n8n consiga processar.O objetivo é chegar a uma estrutura simples:URL 1URL 2URL 3URL 4URL 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 HTTPA 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ível301 → redirecionamento302 → redirecionamento temporário404 → página não encontrada500 → erro no servidor503 → serviço temporariamente indisponívelNem 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áticosDepois 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:URLStatus HTTPTipo de erroData da verificaçãoIsso é 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 alertaOutro 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:ErroErroErroErroErroErro...Isso rapidamente se transforma em ruído.Por isso, o workflow primeiro coleta os problemas encontrados e depois monta uma única mensagem.Por exemplo:🔴 Links com problema encontrados1. URL: /exemplo-1/ Status: 4042. URL: /exemplo-2/ Status: 5003. URL: /exemplo-3/ Status: 404Total: 3 URLsAssim, a pessoa recebe um resumo e pode investigar somente o que realmente precisa de atenção.6. Telegram como camada de alertaO 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 +TelegramCada 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 workflowDurante 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 alertaO alerta deve aparecer quando realmente existir algo para investigar.9. O que eu melhoraria em uma próxima versãoA 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:URLStatus anteriorStatus atualPrimeira ocorrênciaÚltima ocorrênciaNúmero de falhasIsso permitiria diferenciar um erro temporário de um problema persistente.Outra possibilidade seria implementar diferentes níveis:404 → atenção500 → prioridade alta503 → verificar novamente301 → informação200 → normalTambé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çãoO 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 manualmentepodemos ter:publicar conteúdo↓sitemap atualizado↓workflow executado automaticamente↓URLs verificadas↓alerta somente quando necessárioEsse 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ãoUm 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.