John Mueller rivela che Google tratta le parentesi quadre raw e codificate come URL diversi. Analisi tecnica e rischi di duplicazione per il business SEO.

Google vede due pagine diverse dove noi ne vediamo una?

Immaginate un imprenditore che investe migliaia di euro in una strategia di acquisizione traffico, convinto che la struttura dei suoi URL sia lineare e univoca. Per l'occhio umano, e persino per molti browser moderni, un link che termina con ?filter[]=123 e uno che termina con ?filter%5B%5D=123 portano esattamente allo stesso contenuto. Eppure, per l'algoritmo di Google, queste non sono due strade che portano alla stessa destinazione, ma due indirizzi completamente diversi.

Questa discrepanza non è un errore di programmazione momentaneo, ma una conseguenza rigorosa di come Google interpreta la sintassi del web. Quando un sito utilizza entrambe le forme, Google non si limita a ignorarne una; effettua il crawling di entrambe le versioni. Se il contenuto è identico, il motore di ricerca interverrà per eliminare la duplicazione, scegliendo autonomamente quale versione mantenere nell'indice. Questo processo di selezione arbitraria può destabilizzare il posizionamento di pagine strategiche se non gestito con precisione tecnica.

L'equivoco di John Mueller

La verità è emersa non da un comunicato ufficiale, ma da un'interazione su Bluesky. John Mueller, Search Advocate di Google, ha dovuto fare i conti con una domanda di Vanessa Fox, ex dipendente Google e creatrice di Webmaster Central. Fox ha sollevato il dubbio se la forma codificata di un URL venisse trattata come un'entità distinta, portando esempi concreti basati sull'uso di parentesi quadre nei parametri di filtro.

Mueller ha ammesso apertamente di aver probabilmente fornito risposte errate in passato, dichiarando: 'I would have assumed they were equivalent and that I probably gave people the wrong answer on this in the past'. Per verificare la questione, Mueller ha eseguito un controllo tramite JavaScript che ha confrontato i due URL, restituendo un risultato negativo: i due indirizzi non sono equivalenti. Questa ammissione mette in luce quanto sia sottile il confine tra l'intuizione di un esperto e la realtà tecnica del codice che governa l'indicizzazione globale.

Il rigore tecnico dell'RFC 3986

Per comprendere perché Google operi in questo modo, è necessario fare un passo indietro verso le fondamenta del web. Il riferimento è l'RFC 3986, lo standard internazionale che definisce la sintassi degli URI (Uniform Resource Identifiers). Questo documento non è un suggerimento, ma la grammatica fondamentale su cui poggiano i crawler di Google.

Secondo la Sezione 2.2 dell'RFC 3986, i caratteri riservati — tra cui rientrano le parentesi quadre e i segni più — hanno un significato specifico. Lo standard stabilisce chiaramente che gli URI che sostituiscono un carattere riservato con la sua versione percent-encoded non sono equivalenti. C'è poi un dettaglio ancora più critico: l'uso di parentesi quadre raw all'interno di una query string è, tecnicamente, non valido. L'RFC 3986 limita l'uso delle parentesi quadre esclusivamente all'hostname, per racchiudere gli indirizzi IPv6.

Analisi strategica: Questo significa che molte aziende stanno utilizzando URL che sono formalmente non conformi agli standard internet. Sebbene i browser moderni siano permissivi e "ripuliscano" l'URL per l'utente, il crawler di Google segue la norma tecnica. Operare in una zona grigia di non conformità espone il business a rischi di instabilità nell'indicizzazione.

%5B e %5D (analisi)

Entriamo nel dettaglio dei codici. Le sequenze %5B e %5D sono le rappresentazioni percent-encoded delle parentesi quadre aperta e chiusa. Mentre per un utente queste stringhe siano illeggibili, per il server e per Google rappresentano l'unico modo standardizzato di trasmettere tali caratteri in un URL.

Un punto di chiarimento fondamentale sollevato da Mueller riguarda il case-sensitivity: l'uso di lettere maiuscole o minuscole nell'encoding non produce differenze. Pertanto, %5B e %5b sono considerati equivalenti, poiché rispettano le regole dell'RFC 3986 relative ai caratteri esadecimali. La distinzione netta rimane invece tra il carattere raw (la parentesi visibile) e la sua versione codificata.

I pericoli della frammentazione tra sitemap e canonical

Il rischio reale per un'impresa non risiede nella scelta di uno dei due formati, ma nell'uso incoerente di entrambi. La frammentazione si verifica quando un sito web invia segnali contrastanti a Google. Ad esempio, se un'azienda inserisce nell'XML sitemap l'URL con parentesi codificate, ma utilizza il tag canonical per puntare alla versione raw, o viceversa, crea un conflitto di autorità.

Quando Google riscontra questa incoerenza, deve decidere quale versione è quella "ufficiale". Se il motore di ricerca decide di indicizzare la versione che l'azienda non ha ottimizzato o che non è coerente con i link interni, si può verificare una dispersione del link equity. In termini di business, questo si traduce in una perdita di efficienza della SEO tecnica: si spendono risorse per spingere una pagina che Google potrebbe aver "sostituito" con una versione speculare a causa di un dettaglio di encoding.

Questa problematica non riguarda solo le parentesi. Mueller ha specificato che le stesse regole di duplicazione si applicano agli spazi, ai segni più e alla sequenza %20. Ogni variazione in questi caratteri riservati può generare un nuovo URL agli occhi del crawler.

Scegliere un unico standard per i link

Per evitare l'instabilità dell'indicizzazione, è necessario implementare una politica di uniformità assoluta. La raccomandazione di Google è di selezionare un unico formato e applicarlo rigorosamente in ogni punto di contatto con il motore di ricerca.

Elemento di Controllo	Azione Richiesta	Obiettivo Tecnico
Link Interni	Utilizzare esclusivamente un unico formato (raw o encoded)	Evitare il crawling di URL duplicati
Tag Canonical	Allineare l'URL canonical al formato scelto per i link	Confermare l'unica versione autorevole
XML Sitemap	Dichiarare solo la versione standardizzata	Guidare il crawler verso l'URL corretto
Structured Data	Coerenza totale con gli altri punti di contatto	Evitare errori di validazione dei dati strutturati

L'impatto dei caratteri riservati sulla crawlability

La crawlability, ovvero la capacità di un bot di scansionare efficientemente un sito, viene compromessa ogni volta che l'architettura degli URL introduce ambiguità. Se un sito e-commerce con migliaia di filtri utilizza parentesi quadre in modo incoerente, rischia di gonfiare artificialmente il numero di URL da scansionare. Questo può portare al problema del crawl budget: Google spreca tempo a scansionare versioni duplicate di pagine identiche invece di scoprire nuovi contenuti o aggiornamenti di quelli esistenti.

In un contesto di evoluzione verso l'AI Search, come dimostrato dalle recenti implementazioni di Google AI Overviews, la precisione dei link diventa ancora più critica. Sebbene le AI Overviews stiano aumentando il numero di link, la capacità di Google di mappare correttamente le fonti dipende dalla stabilità tecnica degli URL. Un'architettura URL frammentata potrebbe, in teoria, complicare la modalità con cui l'AI associa un contenuto a un'autorità specifica.

Scenario futuro 1: Implementazione di sistemi di normalizzazione automatica lato server che forzano l'encoding di tutti i caratteri riservati prima che l'URL venga servito. Indicatore verificabile: Riduzione del numero di URL "Esclusi per duplicazione" all'interno di Google Search Console.

Scenario futuro 2: Aggiornamento dei browser che standardizzano la visualizzazione degli URL codificati per l'utente finale, rendendo la distinzione raw/encoded invisibile anche negli strumenti di debug. Indicatore verificabile: Rilascio di nuove versioni di Chrome o Firefox con modifiche alla gestione della barra degli indirizzi per i caratteri RFC 3986.

Gestione degli URL e conformità tecnica per l'ecosistema web europeo

Per le imprese italiane ed europee, l'attenzione alla conformità tecnica degli URL non è solo una questione di SEO, ma di interoperabilità. In un mercato regolato da standard rigorosi, l'adozione di pratiche conformi all'RFC 3986 garantisce che i sistemi di indicizzazione e i software di analisi dati operino senza errori di interpretazione.

Sebbene l'AI Act e la direttiva NIS2 si concentrino maggiormente sulla governance dei dati e sulla sicurezza informatica, la robustezza tecnica dell'infrastruttura web è il presupposto per qualsiasi strategia di digitalizzazione sicura. Un sito che ignora gli standard di base della sintassi URI è un sito più vulnerabile a errori di configurazione che possono essere sfruttati per attacchi di injection o problemi di caching. Per l'imprenditore europeo, investire nella pulizia tecnica del proprio asset digitale significa ridurre il debito tecnico e preparare l'azienda a un'integrazione più fluida con i futuri ecosistemi di ricerca basati su AI.

Domande frequenti

---

Fonti: Searchenginejournal (2), Semasocial ·

glacom · Intelligenza artificiale per aziende: i modelli girano sui tuoi server, i dati non escono →