Automatisation des crawls et alertes
Stabilisez les paramètres de crawl et la vérification avant de vous appuyer sur des comparaisons et alertes récurrentes.
Crawl borné
Preuves traçables
Vérification comparable
Un calendrier planifie une tentative, pas un crawl garanti
Choisissez quotidien, hebdomadaire ou mensuel, avec fuseau nommé, heure, minute et jour approprié. Le jitter répartit les admissions. Cinq calendriers au plus sont disponibles par site. Un calendrier non vérifié peut exister mais sera ignoré comme `site_unverified`.
La prochaine échéance exprime le moment où le système doit tenter une admission. Elle ne prouve ni qu’un run a été créé, ni que le worker a collecté des pages, ni que le rapport secondaire a été publié.
Due et started sont deux événements
Le dispatcher contrôle disponibilité du site, run actif, capacité, quotas, plafonds mensuels, budget et solde. Un calendrier dû sans nouveau run n’est pas un succès silencieux.
L’historique doit conserver la tentative, le résultat d’admission et la raison d’un éventuel skip. Cette séparation permet de distinguer une règle de calendrier correcte d’un blocage opérationnel ou financier.
Lire la raison exacte d’un skip
- site non vérifié ou indisponible
- run déjà actif
- capacité ou quota mensuel de l’organisation atteint
- plafond de runs ou budget du calendrier atteint
- solde insuffisant pour la réservation
La fenêtre mensuelle suit le fuseau du calendrier
Les valeurs par défaut sont quatre runs et 50 € par mois. Séparez estimation, réservation et règlement réel, notamment lorsque le rendu est admissible ou requis.
Pause et reprise recalculent la prochaine échéance
La pause efface l’échéance actuelle; la reprise en calcule une nouvelle. La suppression reste logique afin de ne pas réécrire les anciens runs.
Les alertes couvrent des changements nommés
Sont pris en charge: nouveaux liens cassés, nouveau noindex, changements robots, canonical, titre ou meta description, régressions structured data et sitemap, baisse Health et anomalie bot. Définissez sévérité, seuil, digest run, quotidien ou hebdomadaire et, si utile, calendrier ciblé.
Une alerte exige une baseline comparable
La règle utilise le run comparable ou réussi précédent. Un run non comparable n’est pas transformé en fausse variation.
Vérifiez la publication secondaire, le périmètre et la couverture des deux runs. Sans baseline admissible, l’absence d’alerte signifie seulement qu’aucune comparaison sûre n’a produit d’événement.
Utilisez l'historique et la comparaison des crawls pour vérifier les deux rapports derrière une alerte avant d'agir.
Les destinataires doivent pouvoir agir
Les plafonds actuels sont 25 règles et dix destinataires par site. Gardez une liste courte avec une personne responsable de l’enquête; une notification n’est pas une décision automatiquement assignée.
Alignez les accès et responsabilités de l'équipe avec les personnes chargées d'examiner les alertes.
Événement et livraison ont des preuves séparées
Un run conserve au plus 100 événements, scanne jusqu’à 1 000 éléments et retient cinq exemples par défaut. La livraison suit son propre état fournisseur et tente jusqu’à trois envois.
Distinguez l’événement enregistré, l’e-mail mis en file, la tentative du fournisseur et la livraison confirmée. Une notification visible dans Crawl Foundry ne prouve pas à elle seule que chaque destinataire l’a reçue.
Réduire le bruit sans cacher le run
La suppression va de 0 à 720 heures et vaut 24 heures par défaut. Seuils et suppression limitent les répétitions; le run source reste disponible pour l’enquête.