sitemap_stale
Umbodi régénère sitemap.xml avec des dates à jour quand le Last-Modified d’une page est postérieur à la date que lui donne le sitemap, le publie dans une pull request, et vérifie que les nouvelles dates sont en ligne.
Non corrigé par Umbodi sur son propre site — impossible à y planter
Un sitemap dont les dates sont antérieures aux pages dit aux robots que rien n’a changé : les pages mises à jour sont revisitées plus tard qu’elles ne devraient.
Se déclenche quand l’en-tête Last-Modified d’une page est postérieur au lastmod de son entrée dans le sitemap. Un lastmod sans heure est comparé au jour, la précision publiée par le site. Gravité : avertissement.
L’agent régénère le sitemap à partir des pages du site pour que chaque entrée porte une date avec laquelle la page est d’accord. Aucun seuil n’est inventé : les deux dates viennent du site.
Le changement arrive sur le site sous forme de pull request qui ajoute ou modifie un fichier à la racine web du dépôt, ouverte par l’application GitHub d’Umbodi. Les blocs générés sont placés entre des délimiteurs que l’agent gère : les lignes écrites à la main ne sont jamais réécrites.
La valeur est déduite des données du site : le changement est marqué mécanique et aucun seuil de score ne s’applique. Il ne s’applique pourtant que si le propriétaire a activé l’action sans surveillance et réglé la jauge d’autonomie de cette catégorie sur automatique ; la fusion demande un accord distinct.
Une proposition sur dix est mise de côté comme groupe témoin — choisie par un hachage fixe par projet, pas à la main — et n’est jamais appliquée sans surveillance, pour mesurer l’effet des corrections par rapport à celles non faites.
Après la fusion de la pull request et l’apparition du déploiement en production, l’agent lit le fichier en ligne et le compare au diff de la fusion : chaque ligne ajoutée doit y être, et un changement qui ne faisait que retirer des lignes doit les voir disparues. Sinon, le fichier est relu jusqu’à cinq fois, environ deux heures et demie, puis l’agent annule sa propre fusion.
Il s’arrête, en disant pourquoi, quand le fichier en ligne est généré par le code du site plutôt que servi depuis le dépôt — une pull request ne changerait rien —, quand le fichier du dépôt dit déjà la même chose, quand un changement de robots.txt exige une politique que le propriétaire n’a pas choisie, ou selon les mêmes règles de fusion et de déploiement que les pages. Il n’annule jamais sur un fichier inaccessible.
Notre site n’offre aucun endroit où planter ce défaut sans casser quelque chose de réel : il n’y a donc pas de reçu en ligne. La correction n’est prouvée que par la suite de tests. La raison, telle que le code l’énonce :
same generator, same answer: build-sitemap rewrites every <lastmod> on each push, so a planted stale date is reverted by CI before the agent can act. Measured 2026-10-07; owner decision.
Dernière vérification 2026-10-11 08:43 UTC
Seulement ce que prouve la suite de tests : le chemin du constat à la correction vérifiée fonctionne sur des cas d’essai. Rien sur cette page n’affirme que cela s’est produit en ligne.
Cela ne prouve aucun changement de classement ni de citation. Umbodi n’en déduit jamais d’une correction : le classement est mesuré à part, sur Google, et rapporté tel que mesuré. Un reçu montre aussi que le chemin fonctionne sur ce site, pas sur tous les sites.
Umbodi régénère sitemap.xml avec des dates à jour quand le Last-Modified d’une page est postérieur à la date que lui donne le sitemap, le publie dans une pull request, et vérifie que les nouvelles dates sont en ligne.
Pas en ligne. Notre site n’offre aucun endroit où le planter sans casser quelque chose de réel : la correction n’est prouvée que par la suite de tests, et cette page dit pourquoi.
La page des reçus liste chaque type de défaut que l’agent corrige seul, et ceux qu’il a déjà corrigés en ligne sur ce site.