Détecteur Liens Cassés Automatique | n8n

Cette première étape configure le déclenchement automatique du workflow. Le Schedule Trigger est le point d'entrée qui lance l'analyse de votre site à intervalle régulier, sans aucune intervention manuelle de votre part.

En configurant un déclenchement quotidien à minuit, vous vous assurez que votre site est scanné chaque nuit pendant les heures creuses. Ainsi, vous découvrez les nouveaux liens cassés dès le lendemain matin dans votre boîte mail ou votre Drive.

💡 Astuce : Si votre site reçoit beaucoup de trafic en journée, privilégiez un déclenchement nocturne pour éviter toute charge supplémentaire sur votre serveur.

Ce nœud Set initialise les variables essentielles du workflow : l'URL de votre sitemap XML et votre nom de domaine. Ces valeurs seront réutilisées par les nœuds suivants pour le crawling et le filtrage des liens.

C'est ici que vous personnalisez le workflow pour votre propre site. En centralisant ces paramètres dans un seul nœud, vous facilitez la maintenance et l'adaptation à différents projets.

💡 Astuce : Vérifiez que votre sitemap est accessible publiquement en l'ouvrant directement dans votre navigateur avant de configurer le workflow.

Ce nœud crée automatiquement un nouveau document Google Sheets qui servira de rapport pour cette exécution. Le titre du document inclut la date du jour, permettant un historique organisé de vos analyses.

Chaque exécution génère un fichier distinct, ce qui vous permet de comparer l'évolution des liens cassés dans le temps et de mesurer l'efficacité de vos corrections.

💡 Astuce : Vous pouvez modifier le format de date selon vos préférences : 'dd-MM-yyyy' pour le format européen ou 'yyyy-MM-dd' pour le format ISO.

Ce nœud Set prépare la structure de données qui sera utilisée pour enregistrer les liens cassés détectés. Il définit deux champs essentiels : l'URL source et le lien cassé.

Cette étape établit le schéma de données cohérent qui sera rempli plus tard dans le workflow lorsqu'un lien cassé est effectivement détecté.

Ce nœud Google Sheets est configuré pour ajouter une nouvelle ligne au rapport chaque fois qu'un lien cassé est détecté. Il mappe les colonnes A et B aux données source_url et broken_link.

C'est le nœud qui alimente concrètement votre rapport avec les résultats de l'analyse, créant une ligne par lien cassé trouvé.

Ce nœud Google Drive déplace le rapport nouvellement créé vers un dossier organisé dans votre Drive. Cela permet de garder tous vos rapports de liens cassés au même endroit.

L'organisation automatique de vos fichiers évite l'accumulation de documents à la racine de votre Drive et facilite la consultation de l'historique.

💡 Astuce : Créez le dossier "Broken Link Checker" dans votre Drive avant la première exécution, puis sélectionnez-le dans la liste déroulante.

Ce nœud HTTP Request télécharge le contenu de votre sitemap XML. Il utilise l'URL définie à l'étape 2 pour récupérer la liste complète de toutes les pages indexées de votre site.

Le sitemap est le point de départ de l'analyse : il contient toutes les URLs que vous souhaitez crawler pour y détecter les liens cassés.

Ce nœud XML transforme le contenu XML du sitemap en format JSON exploitable par n8n. Cette conversion est indispensable car n8n manipule nativement les données en JSON.

Sans cette conversion, les données du sitemap seraient inutilisables par les nœuds suivants qui ont besoin de parcourir la liste des URLs.

💡 Astuce : Si votre sitemap est très volumineux, cette étape peut prendre quelques secondes. C'est normal.

Ce nœud Split Out extrait chaque URL individuelle du sitemap pour créer un élément séparé par page à analyser. Il cible spécifiquement la structure urlset.url du sitemap XML standard.

Cette transformation est cruciale : elle permet au workflow de traiter chaque page de votre site de manière séquentielle.

Ce nœud SplitInBatches divise le traitement des pages en lots individuels. Avec une taille de lot de 1, chaque page est traitée séquentiellement pour éviter de surcharger votre serveur.

Le traitement séquentiel est important pour ne pas créer un pic de requêtes qui pourrait être interprété comme une attaque ou ralentir votre site.

💡 Astuce : Si votre serveur est robuste, vous pouvez augmenter cette valeur à 5 ou 10 pour accélérer l'analyse, mais surveillez la charge.

Ce nœud HTTP Request récupère le contenu HTML de chaque page listée dans le sitemap. L'URL est extraite dynamiquement du champ loc de chaque entrée du sitemap.

Le contenu HTML téléchargé sera ensuite analysé pour en extraire tous les liens internes présents.

Ce nœud Code est le cœur du workflow. Il analyse le HTML de chaque page pour extraire tous les liens, puis applique un filtrage sophistiqué pour exclure les ressources CDN, les fichiers statiques et les API.

Le code JavaScript utilise une expression régulière pour capturer les URLs des attributs href et src, les dédoublonne, et filtre les patterns de CDN courants (Cloudflare, AWS, Google, etc.).

Logique du code :

• Récupération du HTML depuis $input.item.json.data
• Extraction du domaine depuis le nœud "Set Domain"
• Nettoyage du domaine (suppression de www., https://, http://)
• Regex pour capturer les URLs dans href et src
• Déduplication via Set JavaScript
• Filtrage des patterns CDN : cloudflare, cloudfront, googleapis, gstatic, cdnjs, jsdelivr, unpkg, etc.

💡 Astuce : Vous pouvez personnaliser le tableau cdnPatterns pour ajouter d'autres domaines à exclure spécifiques à votre stack technique.

Ce nœud Merge consolide tous les liens extraits des différentes pages en une seule liste unifiée. Cela prépare les données pour l'envoi au sous-workflow de vérification.

L'agrégation est nécessaire pour transmettre l'ensemble des liens à vérifier en une seule requête webhook.

Ce nœud HTTP Request envoie la liste complète des liens à vérifier vers un webhook qui déclenche le sous-workflow de test. Le payload JSON inclut l'ID du rapport et tous les liens à analyser.

Cette architecture en deux workflows permet de séparer l'extraction (workflow principal) de la vérification (sous-workflow), rendant le système plus modulaire et maintenable.

💡 Astuce : Remplacez l'URL du webhook par celle de votre propre instance n8n. Vous la trouverez dans le nœud Webhook du sous-workflow.

Ce nœud Webhook est le point d'entrée du sous-workflow de vérification. Il reçoit les données envoyées par le workflow principal et lance le processus de test de chaque lien.

Ce sous-workflow fonctionne de manière indépendante et peut être déclenché manuellement pour des tests ponctuels.

Ce nœud Split Out extrait les données reçues par le webhook pour les préparer au traitement individuel de chaque lien.

Ce nœud SplitInBatches traite chaque lien individuellement pour effectuer le test HTTP. Le traitement un par un évite de surcharger les serveurs cibles.

Ce nœud HTTP Request effectue une requête HEAD sur chaque lien pour vérifier son statut. La méthode HEAD est plus rapide que GET car elle ne télécharge pas le contenu de la page.

Le code de statut retourné (200, 404, 500, etc.) détermine si le lien est valide ou cassé.

💡 Astuce : L'option "Ignorer les erreurs SSL" est importante pour ne pas marquer comme cassés des liens vers des sites avec des certificats auto-signés ou expirés.

Ce nœud IF vérifie si le code de statut HTTP est différent de 200. Si c'est le cas, le lien est considéré comme cassé et sera enregistré dans le rapport.

Cette condition filtre les liens valides (200 OK) des liens problématiques (404, 500, 301, etc.).

💡 Astuce : Vous pouvez affiner cette condition pour inclure ou exclure certains codes (par exemple, ignorer les redirections 301 si vous les considérez comme acceptables).

Ce nœud Google Sheets ajoute une ligne au rapport pour chaque lien cassé détecté. Il enregistre l'URL de la page source et l'URL du lien cassé.

C'est l'étape finale de documentation qui alimente votre rapport avec les problèmes à corriger.

Ce nœud Merge consolide tous les résultats de vérification en une seule liste pour préparer la réponse finale du webhook.