Parametri URL e SEO: l'effetto su scansione e indicizzazione

Ogni volta che un filtro, un ordinamento o un tag di tracciamento aggiunge una stringa dopo il punto interrogativo, nasce tecnicamente una nuova URL. Per un utente è la stessa pagina vista con un'opzione diversa; per Googlebot è un indirizzo distinto da valutare, scansionare e, potenzialmente, indicizzare. Su un sito con poche decine di pagine il problema è invisibile. Su un e-commerce con filtri per colore, taglia, prezzo e disponibilità, o su un blog con parametri di tracciamento su ogni link condiviso, la stessa manciata di contenuti può generare migliaia di varianti URL — e ognuna consuma una fetta, piccola ma reale, del budget di scansione che Google dedica al sito.

Il problema non è avere parametri nell'URL: è non distinguere quali parametri cambiano davvero il contenuto della pagina da quelli che si limitano a rietichettarla, tracciarla o ricordarne lo stato di sessione. Questa distinzione decide quale strumento usare — e quando nessuno strumento è la risposta giusta.

Da dove arrivano i parametri: filtri, ordinamento, paginazione, sessione, tracciamento

I parametri URL non sono tutti uguali nella loro origine, anche se sintatticamente sembrano identici: una chiave, un segno di uguale, un valore, separati da un e commerciale quando sono più di uno. Riconoscere da dove viene un parametro è il primo passo per capire cosa fare con lui.

La fonte del parametro non determina da sola il suo effetto SEO — lo determina cosa succede al contenuto quando quel parametro cambia. Ed è qui che entra in gioco la distinzione che conta davvero.

• Filtri: colore=rosso, taglia=m, prezzo_max=50 — restringono un catalogo o un elenco a un sottoinsieme.
• Ordinamento: ordina=prezzo-asc, sort=recenti — cambiano la sequenza degli stessi elementi, non l'insieme.
• Paginazione: pagina=2, page=3 — dividono un elenco lungo in porzioni successive dello stesso insieme.
• Identificatori di sessione: sessionid=8f3a..., PHPSESSID=... — tracciano lato server una visita specifica.
• Tracciamento e campagne: utm_source=newsletter, ref=homepage, fbclid=... — misurano la provenienza del traffico.
• Parametri di visualizzazione: print=1, vista=griglia — cambiano il formato, non il contenuto sostanziale della pagina.

La distinzione che conta: contenuto che cambia contro contenuto che non cambia

Un parametro può fare due cose molto diverse alla pagina che genera. Può produrre un insieme di risultati realmente diverso: un filtro che restringe cinquecento prodotti a dodici è contenuto nuovo, anche se il template e la struttura sono identici a quelli della pagina non filtrata. Oppure può lasciare il contenuto sostanzialmente identico, cambiando solo l'ordine in cui appare, tracciando la provenienza della visita o portando dietro lo stato di una sessione: lo stesso elenco di cinquecento prodotti resta lo stesso elenco, che sia ordinato per prezzo o per data, che arrivi da una newsletter o da una ricerca organica.

Questa distinzione, non l'aspetto sintattico del parametro, è quella che decide la scelta tecnica giusta.

Trattare un parametro di ordinamento come se generasse contenuto nuovo, o all'opposto bloccare un filtro che in realtà crea una pagina con una domanda di ricerca propria, è l'errore all'origine della maggior parte dei problemi di indicizzazione legati ai parametri.

• Contenuto diverso e utile per la ricerca, come una categoria filtrata con una domanda propria: può meritare l'indicizzazione come pagina a sé, con una URL pulita quando possibile.
• Contenuto diverso ma di scarso valore autonomo, come incroci di filtri troppo specifici: va tenuto fuori dall'indice, non necessariamente fuori dalla scansione.
• Contenuto identico, solo riordinato o rietichettato, come ordinamento, tracciamento o sessione: va sempre ricondotto alla URL canonica, senza eccezioni.

Perché i parametri moltiplicano le URL e bruciano il crawl budget

Il crawl budget, cioè il tempo e le risorse che Googlebot è disposto a dedicare a un sito in un dato periodo, non è infinito, ed è tanto più stretto quanto più il sito è grande. Ogni combinazione di parametri che Googlebot scopre e considera meritevole di scansione è una richiesta che non va a un'altra pagina, magari nuova o appena aggiornata.

Il meccanismo è combinatorio e cresce in fretta. Una categoria con quattro filtri, ciascuno con tre o quattro valori possibili, più due opzioni di ordinamento e una paginazione su cinque pagine, non genera qualche decina di varianti: genera facilmente qualche migliaio di combinazioni URL uniche, tutte derivate dallo stesso sottoinsieme di prodotti reali. Se a queste si aggiungono parametri di sessione e tracciamento, che per definizione cambiano a ogni visita, il numero di URL tecnicamente distinte scoperte nel tempo non ha più un limite pratico.

• Ogni variante scansionata è tempo che Googlebot non spende sulle pagine che contano davvero per il posizionamento.
• Su siti grandi, le pagine nuove o aggiornate possono aspettare a lungo prima di essere scansionate se il budget viene assorbito dalle varianti dei parametri.
• Un numero eccessivo di URL quasi identiche nell'indice diluisce anche i segnali di qualità del sito, perché Google valuta pattern a livello di sito, non solo pagina per pagina.

Gli strumenti disponibili e i loro compromessi onesti

Non esiste un'unica soluzione che risolve tutti i casi. Ogni strumento ha un effetto preciso e un limite altrettanto preciso, ed è pensato per un livello diverso della pipeline: scansione, indicizzazione o semplice segnalazione.

In pratica, la combinazione più solida per parametri che non devono essere indicizzati è: link interni che puntano sempre alla URL pulita, più un canonical dalla variante alla pulita per i casi in cui la variante viene comunque raggiunta, per esempio da un link esterno. Il disallow in robots.txt va riservato ai pattern di parametri che si vogliono davvero escludere dalla scansione fin dall'inizio, sapendo che si rinuncia al controllo più fine che canonical e noindex offrono.

• Tag canonical: indica quale URL considerare la versione di riferimento quando più URL restituiscono contenuto equivalente. È un consolidamento dei segnali di indicizzazione, non un blocco alla scansione: Google può comunque visitare la versione con parametro per verificare che il canonical sia corretto, e lo tratta come un forte suggerimento, non un ordine vincolante.
• Disallow in robots.txt: impedisce a Googlebot di scansionare gli URL che corrispondono al pattern indicato. Ferma efficacemente la scansione, ma non garantisce la rimozione dall'indice di URL già indicizzate, e soprattutto impedisce a Google di leggere qualunque tag, incluso un eventuale noindex, presente su quelle pagine, perché la pagina bloccata non viene più scaricata.
• Meta tag noindex: rimuove effettivamente una pagina dall'indice, ma solo se Google può ancora scansionarla per leggere il tag, motivo per cui noindex e disallow sullo stesso insieme di URL sono in conflitto tra loro, non complementari.
• Link interni coerenti verso la URL pulita: è lo strumento meno appariscente e il più efficace nel tempo. Se il sito non collega mai internamente una versione con parametro quando esiste una versione pulita, Googlebot scopre soprattutto le URL pulite, e le varianti restano marginali invece di diventare il pattern dominante scoperto durante la scansione.

Lo strumento Parametri URL di Search Console non esiste più

Per anni, Google Search Console ha offerto uno strumento dedicato, chiamato proprio Parametri URL, che permetteva di dichiarare manualmente, parametro per parametro, se cambiasse il contenuto della pagina e come Googlebot dovesse trattarlo: ignoralo, usa solo il valore rappresentativo, oppure scansiona ogni combinazione. Google lo ha ritirato: non è più presente nell'interfaccia attuale di Search Console, ed è stato dismesso da tempo.

Qualunque guida o articolo che oggi consiglia di andare a configurare i parametri URL in Search Console descrive uno strumento che non esiste più, e non è una differenza cosmetica: senza quella superficie di configurazione manuale, i controlli disponibili sono di nuovo, ed esclusivamente, quelli architetturali descritti sopra — canonical, robots.txt, noindex e la struttura dei link interni. Non c'è più un modo per dire a Google, tramite un pannello, come interpretare un parametro: bisogna renderlo evidente attraverso la struttura stessa del sito.

UTM e parametri di tracciamento: perché non devono mai essere il link usato internamente

I parametri UTM come utm_source, utm_medium e utm_campaign, e i parametri di tracciamento equivalenti come fbclid, gclid o ref, nascono per un unico scopo: misurare la provenienza del traffico quando un link viene distribuito fuori dal sito, in una newsletter, in un annuncio o in un post social. Sono pensati per l'URL che qualcuno clicca arrivando da fuori, non per l'URL che il sito usa per collegare le proprie pagine tra loro.

• Se un menu, una scheda prodotto correlata o un link ad articoli simili punta internamente a una URL con un parametro di tracciamento, si crea una variante URL in più per ogni singola pagina collegata in quel modo, moltiplicando esattamente il problema descritto sopra, senza alcun beneficio.
• Il tracciamento interno inquina anche l'analisi del traffico: un click su un link con UTM interno può essere attribuito come nuova sessione o nuova campagna, sporcando i dati che gli UTM dovrebbero rendere più puliti, non meno.
• La regola pratica è netta: gli UTM si costruiscono solo per link destinati a uscire dal sito, come email, social, annunci o link a partner. Ogni link interno punta sempre e solo alla URL canonica, senza parametri di tracciamento, indipendentemente da dove si trova quel link nel sito.

L'identificatore di sessione: il caso peggiore

Tra tutti i parametri, l'identificatore di sessione, nelle sue varianti sessionid, PHPSESSID o jsessionid, merita una menzione a parte perché rompe l'assunto su cui si basano gli altri rimedi: che il numero di varianti, per quanto alto, sia comunque finito e riconducibile a un pattern. Un filtro ha un numero limitato di valori possibili; un identificatore di sessione no. Se il valore cambia a ogni visita, incluse potenzialmente le visite di Googlebot stesso, ogni scansione della stessa pagina genera tecnicamente una URL mai vista prima.

Il risultato non è un numero grande di varianti, ma un numero che non smette mai di crescere: canonical e noindex funzionano bene su un insieme di pattern riconoscibili, molto meno su un flusso continuo di URL uniche generate una alla volta, spesso più veloce di quanto la scansione riesca a consolidarle. La soluzione corretta non è tecnica SEO a valle, ma architetturale a monte: lo stato di sessione va gestito con un cookie o un token lato server, senza mai esporlo nell'URL. Se un sistema legacy espone ancora l'identificatore di sessione nell'URL, l'obiettivo non è gestirlo bene con un canonical, ma eliminarlo dalla URL il prima possibile.

Come verificare cosa è già indicizzato

Prima di intervenire, vale la pena capire quanto il problema sia già presente nell'indice, non solo teoricamente possibile.

Nessuno di questi controlli richiede strumenti avanzati: richiede la disciplina di guardarli con una certa regolarità, perché il numero di parametri in un sito tende a crescere silenziosamente, un filtro o un tag di tracciamento alla volta.

• Nel rapporto sulle pagine di Search Console, la sezione delle pagine escluse mostra spesso pattern riconoscibili: la dicitura che indica una duplicata per cui Google ha scelto una URL canonica diversa da quella indicata è il segnale più diretto di parametri che stanno creando duplicazione.
• Una ricerca diretta su Google con l'operatore site: combinato a inurl:? mostra rapidamente quante URL con parametri sono indicizzate, e i valori dei parametri stessi indicano quali pattern sono coinvolti.
• Lo strumento di ispezione URL, applicato a un esempio di URL con parametro, mostra se Google la considera un duplicato e quale URL ha scelto come canonica, utile per verificare che le indicazioni date vengano effettivamente rispettate.
• Un controllo periodico, non solo una tantum, ha senso perché nuovi parametri, come una nuova funzione di filtro o un nuovo strumento di tracciamento adottato dal marketing, possono reintrodurre lo stesso problema mesi dopo aver risolto quello originale.