Crochets dans les URL : John Mueller confirme que filter[]= et sa forme encodée sont deux URL distinctes

Google a eu des problèmes internes avec les crochets dans les URL. John Mueller l'a reconnu sur Bluesky, dans un échange avec Vanessa Fox, ancienne de l'équipe Google Search, repéré par Barry Schwartz le 20 octobre. Il confirme surtout que ?filter[]=123 et sa version encodée ?filter%5B%5D=123 ne sont pas équivalentes au regard du standard. Deux écritures, deux URL. Mueller admet au passage avoir « probablement donné la mauvaise réponse » sur ce sujet par le passé.

Un caractère interdit que vos frameworks adorent

La RFC 3986, le standard qui définit la syntaxe des URL, classe [ et ] parmi les délimiteurs réservés. Leur seul usage légal : encadrer une adresse IPv6 dans le nom d'hôte, comme https://[2001:db8::1]/. Partout ailleurs, y compris dans une chaîne de paramètres, ils doivent être encodés en %5B et %5D. Un client strict qui applique le standard considère donc la forme brute et la forme encodée comme deux URL différentes.

Or l'écriture filter[]= est partout. PHP l'a imposée comme convention pour passer des tableaux en paramètres, et Laravel, Symfony, Rails ou jQuery l'ont reprise. Des millions de navigations à facettes e-commerce génèrent donc des URL avec crochets bruts. Les navigateurs les envoient telles quelles, certains outils les encodent à la volée, et le même filtre vit sous deux orthographes. Liens internes dans une forme, sitemap XML dans l'autre (le XML impose l'échappement), canonical parfois dans une troisième : trois déclarations divergentes pour la même page.

Mueller précise que les soucis internes de Google datent d'il y a plus de dix ans. Le moteur s'en sort aujourd'hui : « le web est bordélique », et Google déduplique quand les deux formes renvoient le même contenu. Sa réserve vise les autres robots : crawlers SEO, fetchers et bots IA ne gèrent pas tous ces caractères avec la même précision. Sa position personnelle est nette.

Je m'attends à ce que ça continue de fonctionner, mais je ne construirais pas un nouveau site comme ça.

Google déconseillait déjà cette syntaxe : sa documentation sur la structure des URL classe les paramètres à crochets parmi les formes à éviter. Elle recommande le classique ?category=dresses&sort=price, avec une virgule pour les valeurs multiples d'un même paramètre. Mon avis : impact mineur sur l'existant, Google encaisse. Mais pour un site français en refonte, surtout un e-commerce sous PHP ou Rails avec facettes, c'est le bon moment pour trancher la convention d'URL. La duplication de paramètres se paie ailleurs : la navigation à facettes multiplie déjà les URL à crawler, et le budget de crawl y passe.

Qui doit vérifier, qui peut passer son chemin

Si vos URL de filtres utilisent param[]=, vous êtes concerné. Le cas typique : une boutique Prestashop, Magento ou Laravel dont les facettes empilent color[]=rouge&size[]=m. Vérifiez quelle forme Google indexe réellement, et laquelle vos liens internes, votre canonical et votre sitemap déclarent. Trois sources qui se contredisent, c'est trois signaux dilués pour la même page.

Si vos paramètres s'écrivent déjà ?cle=valeur&autre=valeur, rien à faire : l'échange ne décrit aucun changement d'algorithme, juste une règle de syntaxe que Google applique avec tolérance. Même chose si vos URL à crochets sont bloquées au robots.txt ou non indexables : le sujet ne vous coûte rien. Le risque se loge plutôt hors de Google, chez les robots plus stricts. Un agent IA ou un outil d'audit qui encode systématiquement peut requêter une URL que votre serveur ne reconnaît pas, ou compter double ce que Google compte simple.

Sources

• Search Engine Roundtable - Google Had Internal Issues With Square Brackets [] Punctuation Marks In URLs (20 octobre 2026)
• IETF - RFC 3986, Uniform Resource Identifier: Generic Syntax (janvier 2005)
• Google Search Central - URL structure best practices