sitemap_url_not_indexable
Umbodi retire les entrées du sitemap dont les pages ne servent rien de lisible pour un robot, seulement si le propriétaire a accepté les changements de politique des robots, le publie dans une pull request, et vérifie que les entrées ont disparu.
Non corrigé par Umbodi sur son propre site — impossible à y planter
Une entrée de sitemap qui renvoie une erreur ou une page vide envoie les robots dans une impasse et dépense leur attention sur une page impossible à indexer.
Se déclenche pour chaque URL du sitemap qui ne sert rien de lisible — une page vide ou faite seulement de scripts, une erreur HTTP, ou aucun site. Aujourd’hui, seul un audit de site lancé depuis l’application la détecte ; l’exécution nocturne pas encore. Gravité : avertissement ou erreur.
L’agent retire ces URL du sitemap et refuse si cela le laissait vide. C’est l’un de deux remèdes opposés — l’autre est de réparer la page — donc il n’agit qu’avec l’accord du propriétaire sur la politique des robots.
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.
Comme cela change ce que les robots peuvent lire, il y a un contrôle de plus : le propriétaire doit avoir accepté, pour le projet, les changements de politique des robots. Sans cela, l’agent propose et attend.
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 :
plantable in principle and not built: it needs a new sitemap edit that ADDS a url serving nothing (the existing sitemap_lastmod target only ages an entry), and the drill then advertises a dead page to crawlers for up to 52 hours. Measured 2026-10-07: the remedy and the plant are inverses — the agent dropping the url restores exactly what scripts/build-sitemap.mjs produces — so this is the one of the three that a later session could reasonably add. It is listed rather than attempted because a drill that lies to a crawler about a page should be a deliberate decision, not a side effect of finishing a list.
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 retire les entrées du sitemap dont les pages ne servent rien de lisible pour un robot, seulement si le propriétaire a accepté les changements de politique des robots, le publie dans une pull request, et vérifie que les entrées ont disparu.
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.