Problèmes internes de recherche Google avec les crochets [] Ponctuations dans les URL

La recherche Google a rencontré quelques problèmes lors de la gestion des signes de ponctuation entre crochets (c'est-à-dire [ ]) dans les URL. John Mueller de Google a répondu à l'ancienne Googleuse, Vanessa Fox, en disant qu'il « constate certains des problèmes en interne liés à ce type de caractères dans l'URL ».

Il a ensuite ajouté entre parenthèses en disant : « (même s'ils datent d'il y a plus de 10 ans). » Il a également déclaré : « Il se peut que d'autres robots d'exploration/indexeurs/récupérateurs ne soient pas aussi précis dans cette logique, donc cela vaut peut-être la peine de vérifier ceux qui vous intéressent. »

La question initiale de Vanessa Fox portait sur Bluesky, elle a écrit :

J'ai posté cette question dans les commentaires vidéo YouTube : pour les URL dont les caractères peuvent être codés (crochets, signes plus, espaces), Google traite-t-il la version codée comme une URL distincte ? (exemple.com/category?filter[]=123 par rapport à example.com/category?filter%5B%5D=123 utilisé dans les liens par rapport aux valeurs canoniques).

John Mueller de Google a eu cette longue réponse :

Eh bien, jusqu'à ce que. J'aurais supposé qu'ils étaient équivalents, mais ils ne le sont PAS. C’était une activité secondaire amusante. « ?filtre[]=123 » ≠ « ?filter%5B%5D=123 » car dans la RFC 3986, section 2.2, les caractères entre crochets ([, ]) et les signes plus (+) sont définis dans le cadre de l'ensemble réservé.

« Les URI qui diffèrent par le remplacement d'un caractère réservé par son octet codé en pourcentage correspondant ne sont pas équivalents. Le codage en pourcentage d'un caractère réservé, ou le décodage d'un octet codé en pourcentage qui correspond à un caractère réservé, changera la façon dont l'URI est interprété par la plupart des applications. Ainsi, les caractères de l'ensemble réservé sont protégés de la normalisation… » — IETF STD 66 / RFC 3986, Section 2.2.

JavaScript peut même vérifier ceci : new URL('https://example.com/category?filter[]=123').href === nouvelle URL('https://example.com/category?filter%5B%5D=123').href // Sortie : false

Cela dit, *peut-être* que votre serveur les rend « équivalents aux 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.

Bref, choisissez-en un et utilisez-le de manière cohérente (liens, canoniques, plans de site, données structurées). La même chose est avec  »  » (espace), + (plus) et « %20 », mais avec l'avantage que cela soit différent selon l'élément d'URL dans lequel il se trouve (chemin vs chaîne de requête).

Je connaissais la partie espaces, mais les parenthèses étaient inattendues, et j'ai probablement donné une mauvaise réponse aux gens à ce sujet dans le passé. Oups. BTW pour le codage hexadécimal, la casse n'a pas d'importance, donc « %5B » === « %5b ».

Comme si cela ne suffisait pas ; parenthèses : non seulement elles ne sont pas équivalentes, mais l'URL avec ?filter[]=123 est techniquement invalide (selon la RFC 3986) puisque [ ] ne peut apparaître que dans le nom d'hôte pour envelopper les adresses IPv6 brutes 🤯. Les navigateurs les codent généralement en hexadécimal lorsque vous les saisissez, et les serveurs sont comme des chats.

Vanessa Fox a ensuite poursuivi et écrit :

Ack – j'ai vu ça ! Mais ce site particulier utilise la forme invalide de [] tout au long et l'indexation semble bien, et ce serait une tonne de travail de le changer donc ils le laissent pour l'instant… croisons les doigts ?

John Mueller a répondu :

Je m'attendrais à ce qu'il continue à fonctionner – le Web est désordonné et tout n'est pas « techniquement correct » – mais je ne créerais pas un nouveau site comme celui-ci, et je prêterais une attention particulière à tous les liens internes (y compris les métadonnées comme rel=canonical, les données structurées, etc.) pour le rendre cohérent.

De plus, vu certains des problèmes internes liés à ce type de caractères dans l'URL (même s'ils datent d'il y a plus de 10 ans), il se peut que d'autres robots d'exploration/indexeurs/récupérateurs ne soient pas aussi précis dans cette logique, il pourrait donc être utile de revérifier ceux qui vous intéressent.

Donc Google peut probablement le gérer maintenant, mais il vaut mieux être prudent ?

Discussion sur le forum à Bluesky.

Mise à jour : John a ajouté : « Aucun problème : les normes Internet pour les URL sont simplement très spécifiques. »