Les crochets bruts dans une URL et leur version codée en pourcentage, %5B et %5D, sont des URL différentes, a déclaré John Mueller, avocat de la recherche Google, sur Bluesky Monday. Il a écrit qu’il aurait supposé qu’ils étaient équivalents et qu’il « avait probablement donné aux gens une mauvaise réponse à ce sujet dans le passé ».
Google explorera les deux versions, a-t-il déclaré ; s’il constate qu’ils contiennent des informations identiques, il éliminera la duplication et choisira une version ; il vous recommande de choisir un format à utiliser pour tous les liens, balises canoniques, plans de site et vos données structurées. Les règles pour les formats en double s’appliquent également aux espaces, aux signes plus et à « %20 », a-t-il déclaré.
Pourquoi les crochets codés sont une URL différente
Mueller a retracé la différence jusqu’à la RFC 3986, la norme Internet pour la syntaxe URI, qui place des crochets et des signes plus dans son jeu de caractères réservé. Selon la section 2.2, les URI qui échangent un caractère réservé contre sa version codée en pourcentage « ne sont pas équivalents ».
Il répondait à Vanessa Fox, une ancienne employée de Google qui a développé le Webmaster Central de Google ; elle avait demandé dans une réponse de Bluesky (après avoir posé la question dans les commentaires du premier épisode du Cabinet non canonique) si Google traitait la forme codée d’une URL comme une URL différente. Elle a fourni des exemples en utilisant à la fois ?filter[]=123 et ?filter%5B%5D=123 (l’un dans les liens ; l’autre lors de l’identification des versions canoniques). La vérification JavaScript qu’il a effectuée a ensuite comparé ces deux URL et a renvoyé false.
Il a souligné que l’utilisation de crochets bruts dans une chaîne de requête est également techniquement invalide selon la RFC 3986 ; en effet, la RFC 3986 restreint l’utilisation de crochets au nom d’hôte, pour encapsuler les adresses IPv6 brutes.
Il a déclaré que la casse des lettres dans le codage ne fait aucune différence, donc « %5B » et « %5b » sont équivalents ; ils adhèrent aux règles établies par la RFC 3986 concernant les caractères hexadécimaux.
Ce que Google fait avec les deux versions
Mueller a décrit ce que fait Google lorsqu’un serveur renvoie la même page pour les formulaires bruts et codés :
Cela dit, *peut-être* que votre serveur les rend « équivalents logiciels » en proposant le même contenu. Nous explorerions les deux versions, si nous voyons le même contenu (peut-être même au niveau de la somme de contrôle), nous les déduperions et en choisirions une.
Il a également déclaré qu’un navigateur peut encoder des crochets avant d’envoyer une version codée de ce qui est saisi par l’utilisateur dans la barre d’URL. Cependant, si une URL entre crochets est demandée à partir de JavaScript (ou d’un autre code), les crochets peuvent être envoyés tels quels. Il a recommandé d’encoder les parenthèses lorsqu’elles doivent être utilisées dans une URL : « toujours encoder, ne jamais afficher [].»
Ce que dit déjà la documentation de Google
La documentation sur la structure des URL de Google appelle déjà à coder des caractères tels que des crochets. Il indique que la recherche Google prend en charge les URL telles que définies par l’IETF STD 66, la norme qui contient la RFC 3986, et que « les caractères définis par la norme comme réservés doivent être codés en pourcentage ».
J’ai couvert le premier épisode du Cabinet non canonique la semaine dernière. Cet épisode traitait des emoji et des caractères non anglais dans les URL, que les navigateurs encodent en pourcentage dans un chemin d’URL. Les parenthèses sont un cas différent, car la norme les réserve comme délimiteurs.
Sites utilisant déjà des supports bruts
Vanessa Fox a répondu qu’elle pensait à un site Web qui utilise une notation entre parenthèses invalides, qui semble s’indexer très bien et a décidé de le laisser tranquille car ce serait trop difficile de le convertir en parenthèses valides.
Mueller a déclaré qu’il ne s’attendrait pas à des problèmes liés à l’utilisation de cette structure, mais qu’il « ne créerait pas un nouveau site comme celui-ci ». Mueller a également indiqué qu’il accorderait une attention particulière à tous les liens internes (y compris les métadonnées liées aux données rel=canonical et structurées) afin qu’ils soient uniformes.
De plus, Mueller a déclaré que, sur la base des problèmes rencontrés chez Google concernant le fonctionnement de ces caractères il y a plus de 10 ans, d’autres programmes d’exploration/indexation/récupération pourraient ne pas être « aussi précis dans cette logique » lors de leur traitement.
Pourquoi c’est important
Google choisira une version de l’URL, a déclaré Mueller, s’il existe plusieurs versions disponibles avec le même contenu. Si toutes vos URL utilisent le même format (c’est-à-dire brutes ou codées), alors ce choix est plus susceptible de vous convenir. La meilleure solution consiste à encoder les crochets dans l’URL comme le demande la propre documentation de Google. Mueller s’attend à ce qu’un site existant utilisant des supports bruts continue de fonctionner. Votre tâche semble donc être de vous assurer que vos liens internes et vos métadonnées pointent vers la même version de l’URL.
Regarder vers l’avenir
Mueller a suggéré de vérifier les robots d’exploration et les récupérateurs qui comptent pour vous pour savoir comment ils gèrent les URL entre crochets. Mueller n’a pas nommé spécifiquement quels robots d’exploration ou récupérateurs pourraient avoir un problème, mais il a déclaré que certains robots d’exploration/récupérateurs pourraient ne pas suivre l’exactitude de Google lorsqu’ils traitent des URL entre crochets.
Google n’avait pas encore publié le deuxième volet de la série de vidéos Google intitulé « Cabinet non canonique » concernant le fichier robots.txt au 20 octobre.
