Le filtre est bloqué en premier, puis autorisé après le tri

Votre équipe a bloqué les filtres du catalogue dans robots.txt. Pourtant, les logs continuent à montrer des requêtes sur les mêmes combinaisons. Une URL testée à la main est refusée ; une autre, générée par le tri de la boutique, passe. Le filtre n’a pas changé. Il apparaît simplement après un autre paramètre, à un endroit que votre règle ne reconnaît plus.

Dans ce scénario fictif, la règle vise le chemin /catalogue/ et attend « filtre= » immédiatement après le point d’interrogation. Elle refuse une catégorie suivie de ?filtre=bleu. La même catégorie suivie de ?tri=prix&filtre=bleu reste autorisée par le parseur testé. Paradoxalement, corriger cette omission avec un joker placé devant le mot filtre crée un autre problème : une clé appelée autrefiltre, ou une valeur contenant ce mot, peut être bloquée à son tour.

En pratique, la recette doit couvrir le nom et ses frontières dans l’adresse brute : davantage de refus ne prouve pas une politique plus juste. Cette anatomie s’adresse aux responsables SEO et aux équipes qui génèrent les URL d’un catalogue. Notre accompagnement en SEO technique permet de relier la règle aux adresses réellement produites. L’audit technique du parcours d’exploration vérifie ensuite le périmètre à préserver avant de modifier les restrictions.

Vous allez suivre trois politiques sur douze URL fictives, distinguer un nom de paramètre d’un morceau de texte et préparer une recette qui refuse les filtres ciblés sans fermer les pages utiles. L’exercice utilise le parseur C++ officiel de Google, épinglé à une révision précise. Il ne fait naviguer aucun Googlebot réel et ne mesure aucun gain de crawl ou d’indexation.

• Le test manuel réussit, mais les filtres permutés restent accessibles.
• Une correction trop large interdit des URL dont le paramètre ne porte pas le sens recherché.
• L’équipe confond la décision du parseur avec l’état d’une page dans les résultats de recherche.

Dans quel cas examiner la position du paramètre

Une même facette produit plusieurs écritures

Le bon point de départ est une paire d’adresses qui décrit le même choix de filtre, mais que votre politique classe différemment. Le tri, la pagination ou un lien ajouté par un composant peuvent placer une autre clé devant celle que vous cherchez à interdire. Un utilisateur ne remarque souvent aucune différence dans le résultat affiché ; la chaîne transmise au serveur possède pourtant un ordre distinct.

Ce diagnostic convient lorsque l’équipe a déjà décidé que certaines combinaisons ne doivent pas être explorées. Il ne décide pas à sa place quels filtres méritent une page indexable. Une sélection portant une demande commerciale, du stock et un contenu utile doit être examinée séparément. Corriger le rapprochement d’une règle ne justifie pas de bloquer toutes les facettes.

Ne pas déduire ce défaut d’un résultat GSC isolé

Une URL visible dans Search Console n’établit ni la règle utilisée lors de son dernier accès ni la version actuelle du fichier. Avant de retenir notre angle, comparez des adresses exactes avec le même robots.txt et le même agent. Si leur décision ne dépend pas de l’ordre des clés, cherchez une autre cause : groupe spécifique, règle Allow, mauvais hôte ou fichier différent.

La présence d’une URL dans l’index ne prouve pas non plus que son contenu a été récemment exploré. Pour ce diagnostic, gardez distincts l’autorisation calculée, la requête observée dans les logs et l’information disponible sur l’indexation. Trois observations peuvent raconter des étapes différentes sans se contredire. Aucun pourcentage global de pages bloquées ne remplace ce rapprochement.

Conserver les deux URL avant de normaliser le rapport

Le tri de l’outil d’audit peut effacer la différence

Exportez l’adresse brute, puis une représentation séparée de ses paramètres. Si votre rapport trie automatiquement les clés avant de tester robots.txt, il peut transformer les deux écritures en une seule. Le tableau paraît alors cohérent, tandis que les liens réellement servis gardent une variante autorisée. Une normalisation utile pour regrouper les observations devient trompeuse si elle remplace l’entrée du test.

Notre paire de départ est /catalogue/luminaires?filtre=bleu et /catalogue/luminaires?tri=prix&filtre=bleu. Elle ne contient pas de donnée client. Le choix bleu est identique par construction ; le tri explicite modifie la chaîne. Dans un catalogue réel, faites confirmer l’équivalence fonctionnelle par l’équipe applicative au lieu de la déduire de noms de paramètres qui semblent familiers.

Rattacher l’adresse au composant qui l’a produite

Relevez la page source, le lien HTML ou l’action qui génère l’URL, le moment de collecte et le contexte de navigation. Une adresse peut provenir du rendu serveur, d’un composant JavaScript ou d’un ancien lien conservé. La correction ne sera pas la même si un seul composant permute les paramètres ou si plusieurs générations coexistent après une livraison.

Gardez la forme brute dans les logs de diagnostic et dans les cas de recette. Le regroupement peut disposer d’une autre colonne normalisée ; il ne doit pas écraser celle que le matcher reçoit. Cette séparation permet de vérifier ensuite une correction du générateur de liens sans prétendre qu’elle a fait disparaître les anciennes adresses de toutes les sources de découverte.

Pourquoi la règle initiale reconnaît seulement le premier filtre

Le point d’interrogation fixe une position

La première politique du laboratoire contient un groupe User-agent: * et la restriction Disallow: /catalogue/*?filtre=. Dans les entrées utilisées, le joker couvre la fin du chemin de catégorie ; la séquence qui suit exige ensuite le point d’interrogation immédiatement accompagné de filtre=. Il n’y a rien entre ces deux morceaux pour reconnaître tri=prix&.

Le parseur refuse donc le filtre placé en premier et laisse passer celui placé en deuxième ou troisième position. L’URL contenant deux occurrences de filtre, toutes deux après tri, passe également avec cette politique. Ces résultats portent sur les chaînes de l’exercice. Ils ne démontrent pas que votre propre boutique utilise ce contrat ni que chaque moteur d’exploration appliquerait une implémentation identique.

Ce n’est pas une recherche dans un dictionnaire de paramètres

La règle ne demande pas à l’application « cette URL contient-elle la clé filtre ? ». Elle rapproche un motif d’une adresse. La spécification de Google décrit un joker pour une suite de caractères et un marqueur de fin. Elle ne propose pas la syntaxe d’une expression régulière complète.

Cette différence explique pourquoi tester uniquement l’écran filtré donne une preuve insuffisante. La même interface peut produire plusieurs chaînes. Un contrôle qui appelle seulement le routeur applicatif et inspecte son dictionnaire ne teste pas le comportement de robots.txt. Il faut donner au matcher l’URL exacte qui sera présentée au crawler, avec ses délimiteurs et son encodage.

Le joker ajouté devant filtre peut bloquer le mauvais texte

Un autre nom de clé devient un faux positif

La deuxième politique remplace le motif initial par Disallow: /catalogue/*?*filtre=. Les variantes en deuxième et troisième positions sont désormais refusées. Mais le cas /catalogue/luminaires?autrefiltre=bleu l’est également. Le motif trouve la suite filtre= à la fin d’un autre nom ; il ne dispose d’aucune frontière qui lui impose de commencer une clé.

Nous avons déclaré autrefiltre hors de la politique à bloquer pour ce contrat fictif. Ce nom n’a aucune signification universelle. Dans votre application, la recette doit inclure de vrais paramètres voisins dont l’accès doit rester possible. Sans témoins négatifs, une correction peut afficher davantage de refus et paraître réussie alors qu’elle a simplement étendu son périmètre.

Une valeur peut contenir la même suite de caractères

La deuxième politique refuse aussi /catalogue/luminaires?retour=filtre=bleu. Ici, filtre= appartient au texte de la valeur retour dans notre contrat, pas à une nouvelle clé. La variante où le signe égal de cette valeur est encodé, retour=filtre%3Dbleu, reste autorisée dans le même exercice. La représentation de la chaîne influence donc la décision ; le sens attribué par votre application doit être vérifié séparément.

Un test qui construit seulement des clés attendues ne découvre pas cette extension. Ajoutez des valeurs susceptibles de contenir des mots voisins, des destinations ou des références. Le matcher ne doit pas servir d’interprète métier de ces valeurs. Le contrat de recette précise lesquelles sont hors du blocage, puis vérifie la décision réellement obtenue sans reconstruire une URL plus commode.

Recetter deux positions délimitées dans le périmètre du catalogue

Séparer le début de la requête des clés suivantes

La troisième politique conserve Disallow: /catalogue/*?filtre= et ajoute Disallow: /catalogue/*?*&filtre=, dans le même groupe de l’exercice. La première restriction couvre filtre comme première clé. La seconde demande un séparateur & avant ce nom, après le début de la requête. Dans nos douze entrées, cette paire classe chaque URL selon la décision locale attendue.

Elle laisse notamment passer autrefiltre et la valeur retour contenant filtre=. Le chemin /support?filtre=bleu reste également autorisé : nos motifs concernent /catalogue/. C’est un résultat de la recette, pas une proposition de règles à coller dans n’importe quel site. Une autre arborescence, des alias de clés ou une syntaxe de filtres différente demandent leurs propres cas.

Documenter les limites du contrat utilisé

Dans ce cas concret, Filtre avec une majuscule reste autorisé ; la valeur vide de filtre est refusée. Ces décisions correspondent à notre convention : nom exact en minuscules, restriction indépendante de la valeur. Si votre application traite Filtre comme un alias de filtre, cette convention serait incomplète. Si une valeur vide correspond à une page utile, elle serait trop restrictive. La recette doit précéder le choix du motif.

Nous ne testons pas une syntaxe utilisant des points-virgules comme séparateurs de clés ni toutes les combinaisons d’encodage possibles. Les douze URL ne constituent pas une preuve exhaustive. L’équipe responsable des routes doit fournir les écritures acceptées, les noms répétés, les alias et les adresses historiques. La correction est approuvable lorsque cette liste et ses résultats attendus sont explicites.

Exercice corrigé : comparer trente-six décisions du parseur

Un même jeu de données pour les trois politiques

Nous avons compilé le parseur officiel google/robotstxt à la révision 22b355ff855419e6a3ff8ff09c0ad7fdb17116f9. Son exécutable reçoit un fichier local, le token Googlebot et une URL fictive. Les trois fichiers restent séparés. Les trente-six appels exécutent le matcher réel, avec les mêmes douze entrées pour chaque politique ; aucun accès réseau n’intervient pendant ces appels.

Le tableau regroupe les variantes lisibles. « Autorisée » signifie seulement que cet appel du matcher permet l’accès avec la politique choisie. Il ne signifie ni page indexée, ni lien découvert, ni passage d’un robot réel. Les empreintes du binaire, la révision du code et les résultats complets sont conservés dans notre recette pour éviter qu’une nouvelle compilation soit confondue avec celle examinée.

Lire les erreurs avant de lire le total

La première politique classe neuf cas sur douze selon le contrat : elle oublie trois variantes. La seconde en classe dix : elle corrige ces omissions mais refuse deux témoins qui devaient rester accessibles. La troisième classe les douze. Ce total ne devient utile qu’avec la nature des écarts. Dans un catalogue réel, refuser une page commerciale essentielle peut peser davantage qu’autoriser une variante peu découverte.

Le dépôt officiel précise que la normalisation de l’URI fournie appartient à l’appelant et que le parseur n’englobe pas toute la logique d’un crawler. Notre exercice respecte cette séparation. Il n’évalue pas la récupération du fichier distant, les délais de son cache, le rythme d’exploration ou les interactions propres à d’autres robots. La recette réelle complète ces observations au lieu de déduire un comportement global du seul exécutable.

Vérifier la politique entière avant de publier un motif

Un groupe spécifique peut rendre le test générique trompeur

Nos fichiers ne contiennent qu’un groupe générique. Dans votre fichier, une section plus spécifique peut donner une autre décision. Selon la documentation Google, les groupes spécifiques et génériques ne se cumulent pas, tandis que plusieurs groupes applicables au même agent peuvent être réunis. Une règle située dans la section * ne démontre donc pas à elle seule la restriction effective pour Googlebot.

Testez l’agent prévu avec le fichier complet, sans extraire uniquement les deux lignes qui vous intéressent. Gardez un témoin pour chaque famille d’URL commerciale à préserver. Le résultat doit indiquer le fichier exact et sa version ; un rapport qui annonce simplement « interdit » sans ces éléments ne permet pas de reproduire la décision lors de la livraison suivante.

Allow et le périmètre peuvent changer la décision

La documentation de Google attribue la priorité à la règle applicable la plus spécifique ; en cas de conflit de même priorité, l’autorisation l’emporte. Nos trois politiques ne contiennent aucune règle Allow. Leur réussite locale ne certifie donc pas les résultats d’un robots.txt plus complexe. Ajoutez la politique réelle aux cas de recette et recherchez les exceptions qui visent la même route.

L’hôte, le protocole et le port de la cible doivent également appartenir au dossier. Une préproduction peut servir un autre fichier que la boutique publique. Cette différence est normale si elle est voulue ; elle devient un défaut de recette si vous attribuez le résultat du premier environnement au second. Vérifiez la réponse réellement livrée avant d’accuser le motif de paramètre.

Erreurs fréquentes : obtenir plus de refus sans corriger le défaut

Trier les clés seulement dans le contrôle

Une normalisation appliquée par l’outil de QA peut rendre tous les témoins identiques et produire une fausse réussite. La correction devrait éventuellement porter sur le générateur de liens ; elle ne doit pas être simulée uniquement au moment de vérifier les règles. Gardez deux tests distincts : l’écriture réellement produite par l’application et la décision du matcher sur cette écriture.

Ne transformez pas non plus le motif en expression régulière avec des parenthèses ou une alternative supposée. Une syntaxe familière dans votre langage n’est pas un contrat pris en charge par robots.txt. Préférez une politique dont les cas sont lisibles, puis vérifiez les exclusions et les autorisations sur le même matcher. Une règle plus courte n’est pas forcément plus fidèle au besoin.

Bloquer la lecture d’une correction destinée à l’index

L’introduction de Google à robots.txt rappelle qu’une interdiction de crawl ne constitue pas une désindexation : une URL peut encore apparaître sans son contenu. Si votre objectif est de faire lire un noindex ou une canonical corrigée, fermer l’accès peut empêcher cette lecture. Décidez du séquencement avec le responsable SEO avant de traiter toutes les variantes comme du gaspillage. L’URL utile et la variante à retirer peuvent demander des actions différentes.

Ne retenez pas non plus une baisse du nombre de requêtes comme preuve suffisante. Elle pourrait accompagner la fermeture accidentelle d’une catégorie importante. Le contrôle doit regarder les variantes visées et les pages préservées, ainsi que leurs liens de découverte. Une perte d’accès aux témoins commerciaux est un motif de retour arrière, même si le total de hits paraît meilleur.

Plan d’action : recetter le filtre à partir de vos liens réels

Faire signer la décision sur chaque famille d’URL

Le responsable SEO classe d’abord les familles à garder accessibles et celles à restreindre. L’équipe applicative fournit les paramètres, leurs alias et les écritures réellement produites. L’exploitation conserve le fichier complet servi par chaque hôte. Cette préparation évite de demander au développeur de décider seul si une facette soutient une page commerciale ou représente une combinaison sans intérêt identifié.

• Collecter les URL brutes depuis les liens et les requêtes observées.
• Définir les variantes filtrées à refuser et les témoins utiles à conserver.
• Tester l’ordre des clés, les noms voisins et les valeurs contenant la séquence filtre=.
• Exécuter les cas avec le fichier entier et l’agent concerné.
• Vérifier le fichier livré, puis surveiller les deux groupes après publication.

Pour chaque cas, l’entrée du matcher réunit l’adresse brute, l’agent et la version du fichier. La sortie conserve autorisation ou refus et son écart au contrat attendu. La responsabilité du classement reste partagée avec le responsable SEO : si une catégorie témoin est refusée, alors la livraison est bloquée, même lorsque les filtres inutiles sont bien fermés. Le seuil de cette recette est zéro divergence sur les cas approuvés ; il ne décrit pas une exhaustivité du Web.

Un échec doit garder son entrée exacte, la décision attendue et la décision obtenue. Pour notre défaut initial, « variante deuxième position autorisée » est plus exploitable que « robots incorrect ». Pour le joker trop large, nommez également le témoin fermé à tort. L’équipe peut alors corriger le bon périmètre sans élargir aveuglément l’interdiction.

Porter la recette jusqu’au fichier servi

Intégrez le jeu de cas à la CI lorsque la génération des règles appartient au dépôt. La livraison doit vérifier le contenu rendu par la route publique robots.txt, son statut et l’hôte attendu. Une recette portant uniquement sur le fichier source oublie une transformation au build, un déploiement sur le mauvais domaine ou une réponse conservée par un cache intermédiaire.

L’exploitation porte la responsabilité de vérifier cette sortie publique. La journalisation de livraison conserve l’hôte demandé, la réponse robots.txt et son empreinte, à côté de l’entrée testée en CI. Si le fichier servi diffère du contrat recetté, alors le contrôle reste ouvert et aucune réussite du matcher local ne ferme le dossier. Le seuil d’acceptation sur ce témoin est une identité complète du fichier attendu, avec un repli vers la version précédente si la publication a livré un contenu différent.

Si une couche de cache distribue le fichier, faites contrôler son invalidation et la réponse obtenue après revalidation selon votre infrastructure. Conservez l’ancienne version pour un retour arrière explicite. Cette procédure ne fixe aucun délai universel de prise en compte par Google ; elle établit que votre propre serveur livre la politique recettée, condition nécessaire à l’analyse ultérieure.

Mesurer la correction sans lui attribuer un gain inventé

Observer séparément omissions et fermetures accidentelles

Suivez les variantes du filtre dans leur ordre brut, leur présence dans les liens et les accès observés après la livraison. Ajoutez un suivi des témoins qui doivent rester ouverts : catégories sans filtre, sélections commerciales retenues et routes hors périmètre. Le diagnostic doit répondre à deux questions : les omissions disparaissent-elles et les pages utiles gardent-elles leur accès attendu ?

Les logs servent à constater des requêtes ; ils ne révèlent pas à eux seuls la politique mise en cache par chaque crawler ni sa décision d’indexation. Rapprochez-les de la date de livraison et des informations disponibles sur les pages. Si une variante n’a jamais été observée, le silence après correction ne prouve pas que la règle l’a empêchée. Son résultat de matcher reste la preuve locale pertinente.

Conserver les limites dans le compte rendu

Un compte rendu crédible distingue le défaut reproduit, les cas corrigés et les effets encore inconnus. Notre exercice démontre une omission liée à la position, puis deux faux positifs dus au joker. Il ne chiffre pas le budget de crawl récupéré, ne promet pas une meilleure position et n’établit pas qu’une page commerciale a reçu davantage de trafic qualifié après intervention.

Dans votre suivi, les résultats SEO demandent leurs propres fenêtres et leurs propres observations. Une page recrawlée tardivement ne permet pas de comparer deux périodes comme si le changement avait été visible dès le déploiement. Documentez cet écart au lieu de transformer une réussite technique en résultat commercial. La correction gagne déjà en valeur lorsqu’elle élimine un défaut précis sans fermer les routes utiles.

Lectures complémentaires pour décider quoi explorer

Comprendre les permutations avant de restreindre leur accès

L’analyse de l’entropie des paramètres et de l’espace de crawl examine la multiplication des écritures. Elle aide à retrouver les composants qui fabriquent ces adresses. Notre exercice intervient ensuite sur un motif particulier, lorsque les variantes à traiter ont déjà été reconnues.

La méthode de normalisation qui conserve les tris et filtres utiles distingue les formes brutes de leur interprétation. Elle permet de corriger la génération sans modifier le sens d’une navigation. Un tri de clés ne doit pas devenir une suppression de choix métier.

Relier la restriction à la politique d’indexation

La grille indexer, canoniser, bloquer ou supprimer une facette aide à choisir la destination de chaque famille. Le matcher ne tranche pas cette question : il permet seulement de recetter une restriction retenue. Une réussite du motif ne vaut pas validation de la stratégie de catalogue.

Le diagnostic des divergences entre robots, canonical et statut HTTP sert lorsque plusieurs directives racontent des intentions différentes. Il évite de demander simultanément au crawler de lire une correction et de lui interdire l’accès. Nos témoins utiles doivent rester cohérents avec cette décision d’ensemble.

Conclusion : tester la clé dans l’URL qui sera réellement reçue

Le défaut peut tenir à un seul emplacement : un motif reconnaît filtre immédiatement après le point d’interrogation et oublie la même clé après tri. Ajouter un joker devant le nom corrige ces omissions dans notre exercice, mais ferme également une autre clé et une valeur. Le nombre de refus augmente ; la fidélité de la politique n’est pas encore établie.

La paire de motifs délimités classe correctement nos douze URL fictives. Ce résultat demande un contrat de paramètres précis et reste lié au fichier complet, à l’agent et à l’arborescence testés. Conservez les chaînes brutes, les témoins négatifs et les pages commerciales à préserver avant de retenir une correction pour votre site.

Notre audit SEO technique du catalogue relie les écritures produites, les restrictions et les accès observés. Il permet de qualifier le périmètre et une recette reproductible avec vos équipes, puis de vérifier les effets sans confondre décision locale, crawl réel et indexation.

Si vos filtres restent explorés malgré une règle annoncée comme valide, Dawap peut cadrer votre correction SEO technique à partir des deux URL qui divergent, du fichier effectivement servi et des pages que vous devez garder accessibles. La correction commence avec cette différence vérifiable, avant toute promesse de trafic.