Robots.txt : vérifier le chemin réellement bloqué

Votre fichier robots.txt contient bien le nom de la collection « été », mais le contrôle de crawl signale une autre décision que prévu. Un développeur propose d’encoder tous les chemins ; un second suggère de les décoder avant comparaison. Ces deux corrections peuvent déplacer le problème : la règle ne vise alors plus la même adresse, même si son libellé paraît presque identique dans un export.

En pratique, l’encodage d’un chemin doit conserver ce que vous cherchez à autoriser ou à refuser. Remplacer une lettre accentuée par ses octets UTF-8 encodés ne revient pas à transformer un slash encodé en séparateur. Le diagnostic doit rapprocher l’URL réellement produite, la règle interprétée et la décision métier attendue. Une capture lisible de la barre d’adresse ne suffit pas à établir cette correspondance.

Le 23 octobre 2026, Google a précisé sa recommandation concernant l’encodage des chemins dans robots.txt. Nous partons de cette clarification pour exécuter un cas concret avec son parseur public : douze URL fictives, quatre politiques et quarante-huit comparaisons. L’exercice permet de repérer les omissions, mais aussi les chemins utiles bloqués par une correction trop large.

Cette vérification relève de notre accompagnement en SEO technique et performance des sites. Lorsqu’un catalogue produit ses adresses depuis plusieurs outils, un audit technique des URL et des règles de crawl aide à retrouver la transformation responsable. Le but est de corriger une divergence démontrée, sans attribuer à cette seule correction un gain de trafic ou une meilleure position.

Dans quel cas examiner l’encodage plutôt que réécrire robots.txt

Un catalogue dont plusieurs composants fabriquent les adresses

Le cas devient pertinent lorsque le PIM, le CMS, un import fournisseur et le moteur de recherche interne ne construisent pas les chemins de la même manière. Une référence contenant une barre oblique peut devenir deux segments dans une route, mais rester une valeur encodée dans une autre. Une collection accentuée peut également passer par une étape de conversion supplémentaire au moment de son export.

Le premier signal faible est un écart entre familles proches : une règle fonctionne pour une collection sans accent et échoue sur une autre, ou les liens du menu ne produisent pas la même adresse que ceux d’un filtre. Conservez quelques exemples de chaque origine. Un diagnostic regroupé uniquement par nom de catégorie effacerait précisément la différence que vous devez examiner.

Une restriction dont la finalité est déjà décidée

Avant de discuter des octets, le responsable SEO doit savoir quelles routes méritent d’être explorées. Fermer une catégorie commerciale parce que son encodage paraît compliqué n’est pas une stratégie. Dans notre scénario, certaines familles sont volontairement exclues de la recette, tandis que des chemins voisins restent accessibles. Cette décision est fictive et ne constitue pas une recommandation de bloquer les mêmes familles sur votre boutique.

Si le problème porte sur la désindexation d’une page, commencez par un autre diagnostic. L’introduction officielle à robots.txt distingue restriction d’exploration et retrait de l’index. Une page refusée au crawl peut encore être connue de Google ; un contenu confidentiel demande un contrôle d’accès. Améliorer l’encodage ne transforme pas robots.txt en protection documentaire ni en directive noindex.

Ce que Google a clarifié le 23 octobre sur les chemins UTF-8

Une précision documentaire, pas un changement annoncé du robot

Le journal des mises à jour de la documentation de crawl indique une recommandation supplémentaire sur l’encodage des chemins, en cohérence avec la série vidéo The Non-Canonical Cabinet. Il n’annonce pas que les accents deviennent soudainement interdits. Présenter cette date comme une rupture technique imposant une réécriture générale dépasserait les éléments publiés.

La spécification interprétée par Google accepte les chemins de règle en UTF-8 brut ou encodé. Elle explique que les formes brutes sont converties pour la comparaison et que l’écriture encodée peut faciliter l’interopérabilité avec d’autres outils. Paradoxalement, une règle accentuée déjà correcte peut donc être rendue incorrecte par une « normalisation » qui encode une seconde fois ses pourcentages.

Une politique de sérialisation à rendre explicite

Dans votre chaîne de publication, séparez le nom métier, le chemin assemblé et sa représentation destinée au fichier. Un champ intitulé seulement « URL normalisée » ne dit pas si son contenu est encore à encoder. Donnez au composant suivant une convention vérifiable : les segments reçus sont-ils bruts, ou le chemin contient-il déjà des séquences de pourcentage ?

Cette convention doit vivre près du code de génération, avec des exemples qui échouent lorsqu’une transformation supplémentaire est introduite. Le choix d’une écriture encodée peut simplifier la revue des fichiers, mais ne dispense pas d’un contrôle des sorties. Un changement cosmétique dans un export peut devenir une modification réelle de la politique de crawl si le destinataire le traite comme une donnée brute.

Distinguer lettre accentuée, séparateur et caractère littéral

Un slash encodé n’est pas un séparateur interchangeable

La RFC 3986 distingue caractères réservés et caractères non réservés. Décoder un caractère réservé peut changer l’interprétation de l’adresse. Pour notre exercice, /catalogue/A%2FB/ et /catalogue/A/B/ sont donc conservés comme deux chemins distincts à tester ; nous ne déduisons pas leur équivalence d’un affichage qui remplace visuellement les séquences encodées.

Le même soin s’applique au pourcentage lui-même. Encoder de nouveau %2F produit %252F : le second chemin ne constitue pas une simple version plus propre du premier. Il faut retrouver pourquoi cette représentation existe dans les liens et comment le serveur la traite. L’exercice ne suppose ni que ces routes renvoient toutes une page, ni qu’un routeur applicatif les distingue systématiquement.

Un astérisque peut être une donnée ou un opérateur

La RFC 9309 sur les caractères spéciaux distingue l’astérisque de correspondance et sa représentation encodée lorsqu’on vise le caractère littéral. Notre règle /catalogue/promo%2A/ ne doit donc pas être transformée aveuglément en /catalogue/promo*/. Cette dernière écriture introduit un joker et peut atteindre des chemins qui n’appartenaient pas à la cible initiale.

La question utile n’est pas « faut-il supprimer les caractères étranges ? », mais « quelle adresse exacte cette règle est-elle censée couvrir ? ». Dans une revue, faites apparaître la chaîne encodée à côté du libellé métier. Ne demandez pas au relecteur de deviner si l’étoile affichée désigne un caractère de référence, une convention de nommage ou une instruction destinée au parseur.

Collecter des URL sans perdre la transformation qui les distingue

Comparer le lien produit et la requête reçue

Récupérez d’abord les liens dans le HTML reçu, puis dans le DOM après exécution du JavaScript si le menu est construit côté navigateur. Comparez ces sorties à la représentation de la requête disponible dans vos journaux. Selon la configuration du serveur et de l’outil d’analyse, le champ consulté peut être brut ou décodé. Vérifiez cette propriété avant de rapprocher deux lignes. Si l’observabilité masque déjà la différence entre un slash et son encodage, elle ne permet pas de conclure sur cette anomalie.

Un second signal faible apparaît lorsqu’un export affiche un nombre d’adresses distinctes inférieur à celui observé en entrée. Une transformation de présentation peut avoir fusionné des chaînes différentes. Gardez un identifiant d’échantillon et les deux représentations plutôt que de remplacer l’original. Vous pourrez alors attribuer la divergence au producteur, au transport ou à la restitution du journal, au lieu d’accuser directement le crawler.

Préparer aussi les chemins qui doivent rester ouverts

Une recette composée uniquement des URL à bloquer passe facilement à côté d’une règle trop large. Ajoutez un chemin sans accent, une variation de casse pertinente, une famille voisine et une adresse extérieure au répertoire visé. Chaque témoin doit avoir une justification concrète : catégorie accessible, page de conseil ou route commerciale conservée. Un témoin inventé sans rapport avec l’application aide moins qu’un lien réellement produit.

Dans la fiche de cas, notez l’origine du lien, son chemin exact, la décision attendue et la personne qui l’a validée. Un classement « à investiguer » reste préférable à une autorisation devinée. Le seuil de recette proposé ici est zéro divergence sur les cas approuvés ; il ne signifie pas que quelques exemples couvrent toutes les URL possibles d’un catalogue international.

Exécuter quatre politiques avec le parseur public de Google

Un moteur réel, des adresses volontairement fictives

Nous avons compilé le parseur et moteur de correspondance officiel à une révision précise, puis appelé son binaire sur douze URI du domaine réservé example.com. La révision utilisée est conservée dans le programme et dans son résultat. Aucun robot distant, aucun site client et aucun processus d’indexation ne sont exécutés par ce laboratoire.

Le dépôt précise que l’appelant doit fournir des URI conformes à RFC 3986 : la bibliothèque ne réalise pas toute leur normalisation. Nos entrées sont donc des chaînes ASCII dont les séquences encodées utilisent des lettres hexadécimales majuscules. Le test ne valide pas un normaliseur universel et n’utilise pas une URL Unicode brute pour prétendre reproduire l’ensemble du traitement préalable de Googlebot.

Deux écritures équivalentes et deux corrections défectueuses

La politique encodée comporte les trois règles ci-dessous. Sa variante UTF-8 remplace uniquement le premier chemin par /catalogue/été/. Les deux autres variantes appliquent volontairement des transformations erronées aux chemins encodés : encoder de nouveau les pourcentages, ou tout décoder. Le contrat attendu reste identique, afin de mesurer les changements de décision introduits par ces opérations.

User-agent: *
Disallow: /catalogue/%C3%A9t%C3%A9/
Disallow: /catalogue/A%2FB/
Disallow: /catalogue/promo%2A/

Le programme de comparaison téléchargeable reçoit le chemin du binaire compilé. Il crée ses fichiers dans un répertoire temporaire, effectue les quarante-huit appels et produit un résultat JSON avec l’empreinte du binaire. Les fichiers robots sont des fixtures locales ; le programme ne télécharge pas votre politique et ne modifie pas le robots.txt du site.

Lire les omissions et les blocages accidentels du test

Les chemins du tableau commencent tous par /catalogue/ ; seuls leurs suffixes sont affichés pour garder la comparaison lisible. « Refus » signifie que le moteur interdit l’exploration pour le fichier fourni, pas que l’URL serait inaccessible à un navigateur. La politique UTF-8 obtient exactement les mêmes décisions que la politique encodée sur les douze entrées.

La variante doublement encodée produit six divergences : trois cibles échappent au refus et trois chemins doublement encodés sont fermés à leur place. La variante entièrement décodée produit quatre divergences, dont le blocage du voisin promoVIP et du chemin promo%252A. Le joker issu du décodage explique ces deux dernières correspondances ; une correction présentée comme un nettoyage a élargi la règle.

Les douze cas comprennent aussi ete, une majuscule accentuée, la racine du catalogue et un chemin extérieur. Ils servent de contrôles préservés, sans constituer une couverture de toutes les langues. Les deux politiques correctes réussissent chacune douze comparaisons ; les deux variantes fautives démontrent pourquoi tester seulement la présence d’une règle dans le fichier serait insuffisant.

Erreurs fréquentes : réparer l’affichage et casser la correspondance

Décoder plusieurs fois pour rendre le fichier plus lisible

Lorsqu’un tableau contient beaucoup de pourcentages, la tentation est de les remplacer avant toute comparaison. Le test montre que cette opération peut retirer une distinction utile. N’introduisez pas une boucle de décodage jusqu’à stabilisation pour « retrouver le vrai chemin ». Vous perdez alors l’information sur la représentation effectivement produite et sur l’étape qui l’a transformée.

Gardez une version de présentation si elle aide les équipes, mais conservez l’entrée originale dans le dossier de recette. Le compte rendu doit pouvoir nommer le premier caractère divergent. Si deux outils donnent des décisions différentes, vérifiez leurs entrées et leur préparation avant de conclure à une incompatibilité des moteurs. Comparer des chaînes déjà transformées différemment ne permet pas d’isoler le parseur.

Étendre un joker pour faire passer les exemples bloquants

Ajouter un astérisque large peut faire disparaître l’omission observée sur une seule URL tout en fermant une sélection utile. Dans notre scénario, le voisin promotionnel devient précisément ce témoin sacrifié. Une règle réussissant les trois refus attendus peut encore être inacceptable si elle refuse des chemins qui n’étaient pas dans son périmètre. La réussite doit porter sur les deux groupes.

L’analyse des filtres qui changent de position dans les paramètres traite un défaut différent : les délimiteurs et l’ordre de la chaîne de requête. Ne mélangez pas les deux corrections dans une modification unique sans cas séparés. Vous sauriez qu’un résultat a changé, mais pas si la cause venait de l’encodage du chemin ou du motif appliqué aux paramètres.

Priorités : corriger la règle ou le producteur d’URL

Réparer en premier les sorties dont l’intention est connue

Si la chaîne attendue est correcte mais que la règle est doublement encodée, corrigez le générateur de robots.txt et conservez un témoin de non-régression. Si les liens applicatifs produisent une représentation accidentelle, commencez par comprendre cette sortie. Une règle supplémentaire peut limiter temporairement un crawl inutile, mais elle ne corrige ni les liens internes ni les éventuels doublons de contenu.

• Corriger en priorité une catégorie utile refusée à tort après avoir reproduit l’écart.
• Corriger le composant qui transforme une représentation déjà encodée.
• Différer les regroupements de variantes dont l’équivalence métier reste inconnue.
• Refuser une règle générale sans témoins d’URL commerciales préservées.

Une canonical, un sitemap ou une redirection ne doit pas être ajouté par réflexe pour masquer le défaut. Leur rôle dépend de la ressource effectivement servie et du choix d’URL de référence. Examinez les réponses HTTP et le contenu avant de décider qu’une représentation doit disparaître. Une restriction de crawl prématurée peut empêcher de lire la correction destinée à la page elle-même.

Chiffrer le travail de reprise plutôt qu’un trafic hypothétique

Supposons, pour établir un budget d’investigation, trente exceptions examinées pendant six minutes chacune : la charge représente cent quatre-vingts minutes, soit trois heures. Si la prochaine livraison en introduit encore dix, le même mode de traitement demande une heure supplémentaire. Ces hypothèses ne mesurent aucun gain client ; elles rendent visible le coût récurrent d’une transformation mal définie.

Comparez ce travail à la correction du composant identifié et au maintien d’une petite recette. Le choix dépend du nombre de producteurs et de leur fréquence d’évolution, pas du seul volume d’URL. Ne convertissez pas une heure de diagnostic économisée en revenu SEO : les impressions, les clics et la conversion demandent des observations indépendantes et une attribution beaucoup plus prudente.

Plan d’action : porter la recette jusqu’au fichier réellement servi

Figer le contrat d’entrée et la sortie attendue avant publication

Le développeur conserve le chemin en entrée, la politique complète, l’agent testé et la sortie autorisé ou refusé. Le responsable SEO valide le contrat métier de chaque témoin ; l’exploitation vérifie l’environnement de livraison. Cette responsabilité partagée évite qu’une conversion de chaîne décide implicitement de la visibilité d’une collection. La journalisation du test associe chaque écart à son cas et à la version du générateur.

Pour un générateur versionné, exécutez la recette dans la CI avec le binaire et les cas conservés. Archivez sa sortie et faites échouer le contrôle sur une différence de décision. Fixez un seuil de zéro divergence sur les exemples approuvés et une interdiction de livrer si un témoin commercial change sans décision explicite. Notre laboratoire utilise le groupe générique ; un fichier réel peut contenir des groupes spécifiques et des règles concurrentes. Rejouez donc les cas avec le fichier entier, plutôt que de valider une ligne isolée puis de la considérer correcte dans n’importe quel contexte.

Contrôler la réponse publique sur le bon hôte

Les recommandations Google de création et publication du fichier robots.txt décrivent son emplacement à la racine et son format texte. Dans votre procédure, l’entrée du contrôle de livraison est l’hôte prévu avec son protocole et son port ; la sortie conservée comprend le statut HTTP, le contenu reçu et son empreinte. La responsabilité de l’exploitation porte sur ce fichier servi, au-delà du fichier relu dans le dépôt.

Si cette sortie diffère du contrat testé, bloquez la validation et identifiez le build, la route ou le cache qui l’a remplacée. Un cache frontal ajoute un contrôle : la revalidation vérifie auprès de l’origine si une réponse conservée reste utilisable ; l’invalidation demandée à votre CDN vise à retirer sa copie selon son mécanisme propre. Après cette action, contrôlez encore les octets reçus, sans supposer que les caches du crawler ont été effacés. Les principes de cache HTTP documentés par MDN aident à distinguer ces opérations. Conservez la version précédente pour un retour arrière ciblé. Un délai de surveillance de vingt-quatre heures peut être choisi pour l’équipe d’astreinte, mais ce budget d’observation interne ne promet aucun délai de relecture par Google. La traçabilité doit distinguer livraison réussie et prise en compte encore inconnue.

Mesurer les écarts sans confondre refus local et résultat SEO

Vérifier séparément les cibles et les témoins préservés

Après publication, classez les observations selon les mêmes familles que la recette. Une baisse globale de requêtes peut sembler favorable tout en cachant une collection fermée accidentellement. Vérifiez aussi les adresses autorisées, leurs liens de découverte et leurs réponses. Un résultat de matcher explique une décision possible pour un fichier donné ; les logs constatent des requêtes effectivement reçues, à une date donnée.

Pour une URL signalée dans Search Console, conservez l’état observé et le contexte temporel avant de le rapprocher de la livraison. Une capture ancienne ne prouve pas que le nouveau fichier a déjà été utilisé. Si aucune requête n’est observée après la correction, ce silence ne démontre pas non plus une interdiction : le robot peut simplement ne pas être revenu sur cet échantillon.

Maintenir une preuve technique dont la portée reste lisible

Le dossier de recette doit permettre à une autre personne de reproduire les décisions : révision du moteur, empreinte du binaire, fichiers testés et URI exactes. Ajoutez les paramètres de génération du fichier plutôt qu’une capture seule. Quand une nouvelle langue ou une nouvelle source de catalogue arrive, enrichissez le jeu de cas à partir de ses sorties réelles, sans supposer que les douze témoins initiaux suffisent.

Notre preuve démontre des décisions de correspondance et des erreurs de transformation sur un corpus fermé. Elle ne mesure ni charge serveur, ni budget de crawl récupéré, ni indexation, ni classement. Cette limite rend le résultat exploitable : vous savez quelle hypothèse est réfutée et quels contrôles restent à mener sur votre environnement, sans transformer un test de chaîne en promesse commerciale.

Lectures complémentaires pour relier encodage et décision de crawl

Rechercher les contradictions avant de multiplier les directives

Une règle bien encodée peut rester incohérente avec le reste des signaux de la page. Le diagnostic des divergences entre robots, canonical et statut HTTP aide à ordonner l’enquête lorsque plusieurs composants demandent des choses différentes. Il complète le contrôle de chaîne en examinant ce que l’URL renvoie et ce que les directives cherchent réellement à obtenir.

Cette lecture est utile avant de fermer une variante dont la canonical vient d’être corrigée. Demandez d’abord si le crawler peut encore lire la réponse qui doit lui transmettre cette information. L’encodage établit la correspondance entre une règle et une adresse ; il ne décide pas à lui seul du bon séquencement entre exploration, consolidation et retrait d’une page.

Décider quelles facettes garder accessibles au catalogue

L’arbre de décision sur les choix d’indexation et de restriction des facettes e-commerce intervient en amont du fichier. Une sélection filtrée peut porter une demande commerciale ou produire une combinaison sans intérêt identifié. Cette qualification évite d’utiliser la complexité d’une URL comme unique argument pour l’exclure, alors que son contenu et son usage justifieraient une autre décision.

Lorsque le choix métier est établi, transformez-le en cas de recette précis. Gardez une facette utile parmi les témoins ouverts et une combinaison exclue parmi les refus attendus. Si elles partagent un préfixe, cette proximité devient une épreuve importante pour la règle. Vous vérifiez ainsi une frontière décidée, au lieu de chercher simplement à réduire le nombre d’adresses explorables.

Conclusion : préserver l’adresse visée à chaque transformation

La précision publiée par Google invite à soigner la représentation des chemins, sans remettre en cause toute règle contenant un accent. L’erreur démontrée ici apparaît quand une conversion modifie la cible : un pourcentage réencodé, un slash redevenu séparateur ou une étoile devenue joker. Leur ressemblance dans un tableau ne constitue pas une preuve d’équivalence.

Les quarante-huit comparaisons permettent de distinguer deux écritures correctes de deux transformations défectueuses. La recette reste volontairement bornée et demande à être enrichie avec les URL de votre application. Sa valeur tient aux omissions et aux blocages accidentels qu’elle révèle, autant qu’aux refus obtenus sur les chemins attendus.

Pour une chaîne de génération difficile à retracer, un audit technique du catalogue et de son exploration rapproche liens, règles et réponses sans perdre leurs représentations originales. Il permet de désigner le composant à corriger et les témoins qui empêcheront le défaut de revenir.

Dawap vous accompagne en SEO technique et performance pour mettre ces contrôles en place avec vos équipes applicatives et d’exploitation. Nous cadrons la politique de crawl, les preuves de livraison et la surveillance des pages utiles afin qu’une modification de robots.txt reste une décision vérifiable sur votre propre catalogue.