Crochets URL : pourquoi Google distingue les versions brutes et encodées 🔍
Les crochets URL, ces fameux crochets carrés « [ ] » dans une adresse web, semblent anodins. Pourtant, ils peuvent créer deux URL différentes selon qu’ils sont utilisés bruts ou encodés en pourcentage (par exemple %5B et %5D). Cette nuance, confirmée par un porte-parole de Google, a des implications très concrètes en SEO technique : duplication potentielle, signaux contradictoires, sélection de la version canonique et consommation de budget de crawl. Bonne nouvelle : avec des règles claires et une mise en conformité méthodique, vous pouvez transformer ce risque en avantage compétitif. 🚀
Dans cet article, on clarifie pourquoi Google traite « crochets URL » bruts et encodés comme des adresses distinctes, ce que les standards (RFC 3986) exigent réellement, et surtout, comment aligner votre site pour éviter toute perte de pertinence et de visibilité. Vous trouverez aussi des checklists opérationnelles, des exemples concrets (e‑commerce, filtres, frameworks), et des conseils de migration sans douleur.
Petit rappel technique sur les crochets URL et l’encodage 🧑💻
Caractères réservés selon la RFC 3986
Au cœur du sujet, on trouve la RFC 3986, le standard qui définit la syntaxe des URI. Elle classe certains symboles (comme les crochets, le « + », le « # », le « ? », etc.) en « caractères réservés ». Concrètement, lorsqu’un caractère est « réservé », sa présence dans une URL peut changer la signification de cette URL, et son équivalent encodé en pourcentage n’est pas considéré automatiquement identique.
Appliqué aux crochets URL, cela signifie que l’URL avec crochets bruts et l’URL où ces crochets sont encodés ne sont pas équivalentes par définition du standard. Exemple simplifié :
https://exemple.com/produits?filter[]=123 ≠ https://exemple.com/produits?filter%5B%5D=123
Deux chaînes d’URL différentes = deux ressources distinctes aux yeux d’un robot, sauf si le serveur et les signaux SEO imposent clairement une consolidation.
Des crochets valides… mais pas n’importe où 🌐
La RFC 3986 autorise les crochets dans un usage spécifique : encapsuler une adresse IPv6 dans la partie hôte (par exemple https://[2001:db8::1]/). En revanche, leur emploi brut dans la requête (après le « ? ») n’est pas conforme. C’est là que l’encodage entre en jeu pour exprimer sans ambiguïté la sémantique désirée.
%5B et %5D : encodage et casse hexadécimale
Les crochets carrés se percent-encodent ainsi : [ → %5B et ] → %5D. À noter que l’encodage hexadécimal est insensible à la casse : %5B et %5b sont équivalents. En revanche, cette équivalence ne rend pas interchangeable l’encodé et le brut : c’est bien la présence du caractère réservé non encodé qui pose problème de conformité et d’interprétation.
Ce que fait Google lorsqu’il rencontre les deux versions 🤖
Crawl, déduplication et choix d’une canonique
Si votre serveur renvoie le même contenu pour l’URL avec crochets bruts et sa jumelle encodée, Google peut explorer les deux, détecter la similarité, puis dédupliquer et n’en retenir qu’une en tant que version principale. Toutefois, sans consignes claires (liens internes homogènes, balise canonical cohérente, sitemap aligné), le moteur choisira selon ses propres heuristiques. Autrement dit, vous perdez le contrôle du signal canonique, ce qui peut se traduire par des performances de recherche sous-optimales.
Liens internes, canonical, sitemaps et données structurées : un seul format
Pour que Google comprenne sans ambiguïté quelle version privilégier, il est capital d’utiliser le même format d’URL partout :
– Dans tous les liens internes (navigation, facettes, pagination, filtres, éléments de tri)
– Dans les balises rel="canonical"
– Dans les sitemaps XML
– Dans les balises hreflang
– Dans les données structurées (URL dans JSON‑LD, Microdata, RDFa)
Le principe est simple : un site, un format. Idéalement, l’encodé, pour respecter le standard et garantir la compatibilité maximale.
Navigateurs vs JavaScript : qui envoie quoi ✉️
Beaucoup de navigateurs encodent automatiquement certains caractères saisis dans la barre d’adresse. Mais des requêtes lancées par JavaScript (XHR, fetch) ou d’autres couches applicatives peuvent transmettre les crochets tels quels. Résultat : un même parcours utilisateur peut générer des URL hétérogènes, surtout si des frameworks frontend construisent les paramètres côté client. D’où l’intérêt de normaliser côté serveur et d’imposer des règles de génération d’URL côté front.
SEO pratique : que faire sur votre site pour les crochets URL 🛠️
Décider d’un format unique (recommandé : encodé)
Par alignement avec la RFC 3986 et la documentation Google, adoptez l’encodage pour tous les crochets URL. Cela élimine l’ambiguïté et évite d’exposer des caractères réservés bruts dans les paramètres. Votre convention devient : filter%5B%5D plutôt que filter[].
Forcer la normalisation au niveau serveur (301, réécritures) 🔁
Si des URL brutes circulent (backlinks, anciens liens internes, scripts), implémentez des redirections 301 systématiques vers la version encodée. Vous pouvez :
– Créer une règle de réécriture qui transforme les crochets bruts en leurs équivalents encodés.
– Bloquer la génération d’URL brutes à la source (templates, helpers d’URL, SDK front).
Le but n’est pas de « corriger » toutes les pages existantes manuellement, mais de garantir qu’une requête pour la version brute aboutira toujours à l’encodée, de manière déterministe.
Mettre à jour tous les signaux internes ⚙️
Assurez-vous que tous les composants SEO pointent vers le format choisi :
– Liens internes : navigation, facettes, tri, pagination, bannières, CTA.
– Balise canonical : qu’elle indique précisément l’URL encodée.
– Sitemaps XML : régénérez-les avec les URL encodées, puis réuploadez dans Google Search Console.
– Hreflang : utilisez la même forme encodée pour toutes les langues et alternates.
– Données structurées : mettez à jour toutes les URL présentes dans le JSON‑LD.
Contrôler dans Search Console et dans vos logs 🔎
Après la mise en conformité :
– Analysez le rapport de couverture (ou Pages) pour repérer d’éventuelles duplications restantes.
– Utilisez l’Inspection d’URL pour vérifier la canonique sélectionnée par Google.
– Surveillez les journaux serveur (logs) afin d’identifier des hits persistants vers des crochets bruts, signe qu’une source génère encore de mauvaises URL.
– Vérifiez aussi le rapport Sitemaps pour confirmer l’indexation de la version encodée.
Cas e‑commerce : paramètres de filtres et facettes 🛒
De nombreux frameworks ou librairies front expriment des tableaux dans les paramètres, par exemple ?filter[]=123&filter[]=456. Optez pour la version encodée ?filter%5B%5D=123&filter%5B%5D=456 ou, mieux encore, évitez les crochets URL en nommant les paramètres autrement (cf. bonnes pratiques plus bas). Cette rigueur réduit les risques d’URL multiples non désirées et facilite la gestion des règles de crawl.
Espaces, « + » et « %20 » : même combat ⚖️
Le cas des crochets URL illustre une règle plus large : les caractères réservés et les espaces doivent être traités de façon cohérente. Un espace peut apparaître encodé en %20 ou normalisé en « + » suivant les contextes. Si vous mélangez les deux formes sur un même site, vous créez autant de variantes d’URL, potentiellement interprétées comme distinctes. Unifiez le format choisi et appliquez-le partout.
Les risques si vous mélangez les deux formats 😬
Dilution des signaux et du maillage interne
Quand certaines pages pointent vers la version brute et d’autres vers l’encodée, vous dispersez les signaux (PageRank interne, ancres, popularité). Cette dilution peut suffire à faire perdre des positions sur des requêtes compétitives, surtout si d’autres problèmes de duplication existent déjà (tri, pagination, sessions, UTM, etc.).
Budget de crawl gaspillé
Chaque variante d’URL découverte consomme du crawl, surtout sur des sites volumineux. Même si Google déduplique, il aura quand même dépensé des ressources pour explorer, comparer et décider. Sur un site très dynamique (filtres, facettes), ces micro-inefficiences s’accumulent.
Analytics et campagnes : des rapports morcelés 📊
Deux formats d’URL pour une page identique, c’est aussi des métriques divisées entre plusieurs entrées (sessions, conversions, revenus). Les attributions de campagne et les analyses de cohortes deviennent moins lisibles, voire trompeuses. En réconciliant vos crochets URL, vous simplifiez la mesure.
Faut‑il corriger si votre site utilise déjà des crochets bruts ? 🧩
De nombreux sites fonctionnent « sans casse » avec des crochets bruts. Toutefois, ils s’exposent à des incohérences à mesure que le site grandit, que de nouveaux parcours se créent (apps, edge rendering) et que des sources externes (affiliation, marketplaces) relaient des URL moins propres. La recommandation raisonnable :
– Si le site est stable et indexé correctement, planifiez une migration en limitant l’ampleur : normalisation côté serveur (301), mise à jour progressive des liens internes, canonical et sitemaps harmonisés.
– Si vous lancez un nouveau site ou une refonte, partez directement sur l’encodé et bannissez les crochets URL bruts.
L’objectif n’est pas de « tout refaire » d’un coup mais d’empêcher la création continue de variantes. En bloquant la génération brute et en 301‑redirigeant ce qui traîne, vous ramenez l’écosystème vers une forme unique, stable et conforme.
Bonnes pratiques de nommage des paramètres (éviter les crochets URL) ✅
Évitez les caractères réservés dans les noms de paramètres
Idéalement, renoncez à l’usage des crochets dans le nom des paramètres. Des alternatives sûres existent :
– Remplacez filter[] par filter répété : ?filter=123&filter=456 (de nombreux frameworks comprennent les occurrences multiples).
– Ou utilisez des suffixes explicites : filter_id=123, filter_cat=shoes.
– Ou encodez une liste de valeurs séparées par des virgules : ?filter=123,456 (assurez-vous que votre backend gère correctement l’analyse de ces listes et l’ordonnancement pour éviter des URL différentes pour le même ensemble).
Stabilité et ordre des paramètres
La même combinaison de filtres doit produire la même URL, quel que soit l’ordre de sélection par l’utilisateur. Triez les paramètres de façon déterministe (alphabétique, par clé, etc.) pour éviter des duplications inutiles. Si nécessaire, ajoutez une couche de normalisation avant de rendre l’URL (côté serveur ou middleware).
Checklist de migration rapide (crochets URL → encodé) 🧭
1) Décidez du format cible (encodé) et inventorie les modèles d’URL actuels impliquant des crochets.
2) Mettez en place des 301 au niveau du reverse proxy ou du serveur web pour convertir automatiquement « [ » et « ] » en « %5B » et « %5D » dans la query string.
3) Mettez à jour la génération d’URL dans les templates, composants front, et helpers de routing pour n’émettre que la forme encodée.
4) Remplacez toutes les références dans le CMS : liens internes, menus, footers, bannières, blocs réutilisables.
5) Régénérez les sitemaps avec les URL encodées et soumettez-les dans Google Search Console.
6) Vérifiez et harmonisez les balises canonical, hreflang et les URL présentes dans les données structurées.
7) Testez des scénarios utilisateurs (filtres, facettes, tri, pagination) et validez que la même action produit systématiquement la version encodée.
8) Surveillez les logs pour capter les anciennes URL brutes et, si nécessaire, contactez les partenaires qui les relaient afin qu’ils mettent leurs liens à jour.
FAQ express sur les crochets URL ❓
Les crochets URL bruts et encodés sont-ils vraiment des URL différentes ?
Oui. Pour les caractères réservés, la RFC 3986 n’assimile pas brut et encodé. Les robots peuvent donc considérer ces chaînes comme distinctes, sauf consolidation explicite.
Dois-je tout encoder, même si mon site indexe correctement aujourd’hui ?
Encouragé. L’encodage réduit l’ambiguïté, normalise les signaux et prévient les problèmes à long terme. Vous pouvez migrer progressivement avec des 301 et des mises à jour ciblées.
La casse dans « %5B » vs « %5b » change quelque chose ?
Non, l’encodage hexadécimal est insensible à la casse. Préférez toutefois une écriture uniforme pour la propreté.
Est-ce que d’autres crawlers que Google gèrent cela pareil ?
Pas toujours. D’où l’intérêt de respecter strictement le standard et d’être cohérent, pour maximiser la compatibilité inter‑plateformes.
Les espaces et le signe « + » posent-ils le même genre de problème ?
Ils relèvent du même principe de cohérence. Mélanger « + » et « %20 » pour un même espace peut créer des variantes d’URL. Unifiez vos pratiques.
Je vois « ?filter[]= » partout dans mon site e‑commerce. Faut-il supprimer les crochets URL ?
Deux options : encoder les crochets systématiquement, ou mieux, renommer vos paramètres pour éviter les caractères réservés. Choisissez selon vos contraintes techniques et votre roadmap.
Exemples concrets et pièges courants 🧪
E‑commerce à facettes
Un catalogue avec plusieurs filtres actifs peut produire : ?filter[]=123&filter[]=456, une URL parfois dupliquée avec ?filter%5B%5D=123&filter%5B%5D=456. Sans redirection et signaux cohérents, vous multipliez les variantes. Solution : normalisation au serveur + liens internes encodés + canonical vers une seule forme.
UTM et tracking
Les paramètres UTM ne devraient pas reposer sur des crochets URL. Assurez-vous que vos gabarits d’URL de campagne n’introduisent aucun caractère réservé non encodé, pour éviter la fragmentation des données d’attribution.
Frameworks JS et génération côté client
Certains outils de routing ou de gestion d’état (par exemple, la sérialisation d’objets en query string) peuvent émettre des crochets bruts. Paramétrez-les pour encoder systématiquement, ou interceptez la génération afin d’appliquer votre normalisation.
Mesurer l’impact SEO après la normalisation 📈
Indicateurs à suivre
– Diminution des URLs « alternatives » ou « dupliquées » dans les rapports d’indexation.
– Hausse du taux de présence de la version encodée dans l’index.
– Stabilisation de la canonique choisie (Search Console, Inspection).
– Légère amélioration de l’exploration (moins d’URL non pertinentes dans les logs).
– Consolidation des métriques analytics (séances, conversions) sur une seule URL par page.
La normalisation n’est pas un levier « spectaculaire », mais elle supprime une friction technique qui, combinée à d’autres optimisations (vitesse, contenu, maillage), peut faire une différence tangible sur la visibilité globale.
Pourquoi ce sujet dépasse le « détail technique » 💡
La cohérence d’URL est un socle. Les moteurs s’appuient sur des signaux multiples (liens, canonical, sitemaps, structure des paramètres). Mélanger des formats pour un même contenu revient à transmettre des messages contradictoires. Dans un écosystème SERP de plus en plus concurrentiel, éliminer ces ambiguïtés maximise vos chances de voir la bonne page, avec la bonne URL, pour la bonne requête.
En résumé : la stratégie gagnante pour les crochets URL ✅
– Les crochets URL bruts et encodés sont considérés comme des URL différentes, conformément à la RFC 3986.
– Adoptez un format unique, idéalement encodé, pour tous les signaux (liens, canonical, sitemaps, hreflang, données structurées).
– Forcez la normalisation côté serveur avec des 301 pour tout ce qui arrive en brut.
– Mettez à jour vos générateurs d’URL (frontend, backend, CMS) et contrôlez via Search Console et les logs.
– Lorsque c’est possible, évitez les crochets URL dans les noms de paramètres en choisissant des alternatives stables et sans caractères réservés.
Cette discipline évite le gaspillage de crawl, la dilution des signaux, et sécurise la sélection de la version canonique qui vous avantage. À la clé : un site plus propre, plus prévisible, et mieux armé pour performer durablement sur Google. ✨
