Google tratta le parentesi quadre nell’URL come dati

Le regole sono nella sezione 2.2 della RFC 3986, tra i caratteri riservati.

Chi passa le giornate tra log di crawl, report di scansione e parametri generati dai filtri di un e-commerce le ha viste mille volte: ?filter[]=123 da una parte, ?filter%5B%5D=123 dall’altra. Molti le considerano due modi di scrivere la stessa cosa, con la codifica percentuale (percent-encoding) vista come un dettaglio cosmetico che browser e motori sistemano da soli. Lunedì John Mueller di Google ha smentito questa idea con un segno di disuguaglianza: nel suo post su Bluesky ha scritto che le due stringhe non sono equivalenti. Per chi lavora sul traffico organico di siti con filtri, faccette e parametri, la codifica fa parte dell’identità dell’URL.

Due URL che sembrano gemelli e non lo sono

Il punto di partenza non è un’opinione di Mueller ma la documentazione ufficiale. Secondo le linee guida di Google Search Central sulla struttura degli URL, Google Search supporta gli URL come definiti da IETF STD 66, cioè lo standard che corrisponde a RFC 3986. La stessa pagina precisa che i caratteri che lo standard classifica come “riservati” devono essere codificati in percentuale. IETF è l’Internet Engineering Task Force, l’organismo che pubblica gli standard tecnici di Internet. Le RFC (Request for Comments) sono i documenti in cui questi standard vengono fissati.

Le parentesi quadre rientrano in quella categoria. Nella sua forma “nuda” ?filter[]=123 usa caratteri riservati come se fossero semplici dati. La versione ?filter%5B%5D=123 invece li codifica come richiesto. Per un essere umano, e spesso anche per il browser, il risultato è identico. Per Google Search no. Bisogna allora capire quali regole stabiliscono cosa, in un URL, è dato e cosa è struttura.

Parentesi, più e slash: la grammatica che nessuno legge

La risposta sta nella specifica che Google dichiara di seguire. Come ricorda Mueller, nella Sezione 2.2 di RFC 3986 le parentesi quadre ([ e ]) e il segno più (+) sono definiti come parte dell’insieme dei caratteri riservati. RFC 3986 li divide in due gruppi. I gen-delims sono i delimitatori generali che separano le componenti dell’URL. I sub-delims hanno funzioni di delimitazione all’interno delle singole componenti. Come spiega la guida di http.dev al percent-encoding, secondo RFC 3986 [ e ] sono gen-delims e per convenzione servono a indicare gli indirizzi IPv6 letterali. Quando vengono usati come dati vanno codificati come %5B e %5D. Un CMS che scrive filter[] nella query string usa quindi come dato un carattere che lo standard riserva alla struttura dell’URL.

Con il segno più la questione si complica, perché il suo significato dipende dal contesto. Nei dati codificati tramite form, il formato che finisce di solito nella query string quando un utente invia un modulo o applica un filtro, il + rappresenta uno spazio. Un più letterale deve quindi essere scritto come %2B. Nel percorso dell’URI, cioè la parte prima del punto interrogativo, il + resta invece un semplice segno più. Lo stesso carattere ha quindi due significati diversi a seconda di dove compare nell’URL. È una fonte classica di errori quando librerie diverse costruiscono e leggono gli stessi link: una codifica lo spazio come +, un’altra lo interpreta come carattere letterale.

C’è poi un problema più a monte: gli standard stessi non concordano. Stenberg, sviluppatore di curl, ha raccontato sul suo blog quanto diverge la definizione di URL tra le specifiche. L’esempio che porta è quello degli slash dopo lo schema. La specifica WHATWG, il gruppo che definisce gli standard usati dai browser, stabilisce che un parser deve accettare un numero indefinito di slash. RFC 3986, osserva Stenberg, non è d’accordo, e con lei molti altri. Browser, librerie di programmazione e motori di ricerca non leggono quindi necessariamente gli URL allo stesso modo. Che il browser tolleri un URL scritto male non dice nulla su come lo tratterà il crawler.

Cosa controllare nei parametri da domani mattina

Il browser può tollerare ciò che Google distingue. L’unico riferimento operativo affidabile è quindi lo standard che Google dichiara di applicare, RFC 3986. Il primo controllo riguarda il modo in cui CMS, plugin di filtraggio e template generano i parametri. Le piattaforme che costruiscono array nella query string con la sintassi param[] sono le prime da verificare. Lo stesso vale per il codice front-end che compone URL con funzioni come URLSearchParams, che segue le regole della codifica dei form e quindi del + come spazio.

L’obiettivo è scegliere una sola forma, codificata in modo coerente con RFC 3986, e usarla ovunque: link interni, sitemap, canonical, redirect. Il rischio concreto è che lo stesso contenuto raggiunga il crawler in più varianti, una con le parentesi in chiaro e una con %5B%5D, oppure una con + e una con %2B. Bisogna anche capire dove si trova ogni segno più. Nel percorso è un carattere letterale. Nella query string con dati di form indica uno spazio, e se serve un più vero va scritto %2B. Un trade-off va messo in conto: cambiare la codifica dei parametri su un sito già indicizzato significa cambiare URL. Va fatto in modo coordinato, non con una correzione parziale che aggiunge un’altra variante alle esistenti.

La domanda da porsi è quante varianti dello stesso URL produca già oggi la navigazione a faccette del proprio sito senza che nessuno se ne sia accorto. Domani mattina conviene aprire i log del server e il codice che genera i link interni, cercare parentesi quadre e segni più non codificati e uniformarli secondo RFC 3986. Per Google Search la codifica fa parte dell’URL a tutti gli effetti.