Comment un agent SEO empêche-t-il sans risque robots.txt de bloquer les moteurs ?

Ce que c’est, et pourquoi c’est important

Un Disallow de tout le site pour Googlebot, Bingbot ou tous les robots demande au web de recherche d’oublier le site. Resté d’une version de test, il retire le site des résultats.

Comment il est détecté

Se déclenche quand robots.txt interdit tout le site à un grand robot — Googlebot, Bingbot ou tous. Gravité : erreur.

Comment il est corrigé

L’agent retire le blocage de tout le site pour ce robot dans un bloc délimité qu’il gère, et laisse intactes les autres règles du site. Écrire un nouveau robots.txt exige la politique choisie par le propriétaire pour les robots d’IA (autoriser ou bloquer) ; sans elle, l’agent s’arrête et demande.

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.

Quand l’agent peut agir sans personne

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.

Comment la correction est vérifiée

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.

Quand il s’arrête plutôt

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.

Le reçu de ce site

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 :

the plant is "Disallow: / on the live robots.txt" for up to 52 hours — telling every crawler to stop reading umbodi.ai. On a site whose entire product is search and AI-answer visibility that is not a worse snippet, it is the worst available outcome, and it would also suppress the rank measurements every other drill depends on. Measured 2026-10-07: our robots.txt currently disallows 2 admin prefixes and allows everything else.

Dernière vérification 2026-10-11 08:43 UTC

Ce que cela prouve, et ce que cela ne prouve pas

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.

Questions sur ce défaut.