SEO per siti con molti parametri URL: canonical, robots.txt e controllo della scansione
I parametri URL sono utili per filtrare prodotti, ordinare risultati, tracciare campagne, mantenere sessioni e modificare ciò che gli utenti vedono senza creare una sezione completamente separata di un sito. Il problema SEO inizia quando una singola pagina utile può essere raggiunta tramite decine, migliaia o persino milioni di indirizzi parametrizzati. Una categoria come /shoes/ può esistere anche in versioni contenenti parametri relativi a colore, taglia, prezzo, ordinamento o tracciamento, anche se molti di questi URL mostrano sostanzialmente lo stesso contenuto. I motori di ricerca devono quindi stabilire quali indirizzi meritano di essere sottoposti a scansione e indicizzati e quali rappresentano semplicemente versioni alternative. Per grandi siti di e-commerce, directory, siti editoriali e altri siti con sistemi di filtraggio avanzati, la gestione di questi URL è quindi una parte importante della SEO tecnica. L’obiettivo non è eliminare i parametri utili, ma chiarire quali URL rappresentano pagine di valore, quali sono duplicati e quali non dovrebbero consumare inutilmente risorse di scansione.
Perché i parametri URL possono diventare un problema SEO
Un motore di ricerca considera ogni URL accessibile alla scansione come una potenziale pagina. Dal punto di vista di un crawler, /jackets/, /jackets/?sort=price e /jackets/?utm_source=email sono indirizzi diversi finché non viene compresa la relazione tra loro. Questo aspetto diventa particolarmente importante quando più parametri possono essere combinati. Cinque colori, otto taglie, sei marchi e diverse opzioni di ordinamento possono generare centinaia o migliaia di combinazioni a partire da una sola categoria. Aggiungendo identificatori di tracciamento, paginazione o parametri di sessione, il numero può crescere ulteriormente. Google identifica specificamente la navigazione a faccette come una causa comune di spazi URL molto estesi e di scansioni inutili, perché i crawler possono dover richiedere numerose combinazioni prima di stabilire che hanno scarso valore.
La presenza di URL parametrizzati non significa automaticamente che un sito abbia un problema SEO. Alcune combinazioni di parametri possono rappresentare pagine realmente utili. Un rivenditore, ad esempio, può avere un numero sufficiente di prodotti e una domanda di ricerca tale da giustificare una pagina accessibile alla scansione dedicata alle scarpe da corsa nere o ai televisori da 55 pollici. Altri parametri modificano soltanto l’ordine degli elementi esistenti, registrano la provenienza di una visita o memorizzano informazioni necessarie al funzionamento del sito. In genere, queste versioni non devono competere nei risultati di ricerca con la categoria principale. Trattare tutti i parametri nello stesso modo può quindi essere quasi altrettanto problematico quanto lasciare senza controllo ogni possibile combinazione.
Il primo passo pratico consiste nell’identificare cosa fa realmente ciascun parametro. I parametri di tracciamento, come i comuni tag delle campagne, solitamente non modificano il contenuto principale. I parametri di ordinamento possono cambiare la disposizione degli stessi prodotti senza creare una pagina significativamente diversa. I filtri possono andare da combinazioni di scarso valore a landing page utili, mentre gli identificatori di sessione possono creare un nuovo indirizzo per ogni visitatore. Una volta raggruppati i parametri in base alla loro funzione, le decisioni SEO diventano molto più semplici. Il sito può mantenere accessibili le pagine filtrate di valore, consolidare i duplicati effettivi e ridurre l’accesso dei crawler agli schemi URL che non hanno alcun motivo di comparire nella ricerca organica.
Distinguere le pagine filtrate utili dalle varianti URL superflue
Una regola utile consiste nel valutare le pagine parametrizzate in base al loro contenuto e alla loro funzione, anziché semplicemente in base alla presenza di un punto interrogativo nell’URL. Se una pagina filtrata risponde a un’esigenza distinta dell’utente, contiene una selezione utile di elementi e può mantenere il proprio valore nel tempo, può avere senso consentirne l’indicizzazione. La pagina dovrebbe inoltre avere un URL stabile, contenuti descrittivi quando appropriato, collegamenti interni chiari e un numero sufficiente di risultati disponibili da giustificarne l’esistenza. Creare migliaia di combinazioni indicizzabili solo perché il sistema di filtraggio può generarle è diverso dal mantenere intenzionalmente un numero limitato di varianti di categoria realmente utili.
I parametri di scarso valore dovrebbero essere gestiti in modo più rigoroso. Codici di tracciamento, ID di sessione, versioni di stampa, opzioni di ordinamento arbitrarie e combinazioni che producono sostanzialmente la stessa pagina possono moltiplicare il numero di URL senza aggiungere contenuti utili per la ricerca. Possono inoltre rendere più complessa l’analisi dei dati, perché visite e link possono essere distribuiti tra diverse versioni della stessa pagina. Google è generalmente in grado di riconoscere molti URL duplicati, ma affidarsi completamente all’elaborazione automatica offre al sito un controllo minore sugli indirizzi utilizzati nei link interni, inclusi nelle sitemap e indicati come versioni preferite.
Anche le combinazioni di filtri vuote o prive di senso richiedono attenzione. Le attuali indicazioni di Google sulla navigazione a faccette raccomandano di restituire una vera risposta HTTP 404 quando una combinazione di filtri non produce risultati, invece di mantenere una quantità potenzialmente illimitata di pagine vuote accessibili alla scansione. Lo stesso principio si applica alle combinazioni impossibili di parametri e alla paginazione oltre il numero effettivo di pagine disponibili. Impedire che questi spazi URL si espandano rende il sito più facile da comprendere per i crawler e riduce le richieste verso pagine che non possono soddisfare gli utenti. Per i siti di grandi dimensioni, questa gestione preventiva può essere più utile che tentare di correggere una struttura parametrica incontrollata solo dopo la generazione di milioni di URL.
Utilizzare gli URL canonical per consolidare le varianti parametrizzate
L’elemento link canonical è uno dei principali strumenti per indicare quale URL dovrebbe rappresentare un gruppo di pagine duplicate o molto simili. Se un parametro di tracciamento produce la stessa pagina prodotto dell’URL pulito, la versione parametrizzata può indicare l’indirizzo pulito come canonical. Lo stesso approccio può essere appropriato per le varianti di ordinamento quando l’unica differenza significativa riguarda l’ordine in cui vengono mostrati contenuti identici. In questo modo, Google riceve un segnale chiaro sul fatto che l’indirizzo preferito è la versione principale. Anche i link interni e le sitemap XML dovrebbero normalmente rafforzare questa scelta utilizzando lo stesso URL preferito, invece di esporre ripetutamente alternative non necessarie.
Un canonical è un segnale, non un’istruzione assoluta. Google valuta diversi segnali quando sceglie un URL canonico e può selezionarne uno differente se le indicazioni risultano in conflitto. Ciò significa che aggiungere tag canonical mentre si creano molti link interni verso alternative parametrizzate è una pratica poco efficace. La configurazione più solida è coerente: la pagina preferita ha un canonical autoreferenziale, le versioni duplicate puntano ad essa, la navigazione interna utilizza l’URL preferito e la sitemap XML contiene la versione canonica. I redirect permanenti possono rappresentare una soluzione ancora più chiara quando un URL alternativo non deve più rimanere disponibile agli utenti.
I tag canonical dovrebbero inoltre riflettere una reale somiglianza tra le pagine. Una pagina filtrata che mostra un insieme sostanzialmente diverso di prodotti non dovrebbe puntare automaticamente a una categoria più ampia solo perché entrambe le pagine utilizzano lo stesso modello. Se l’URL filtrato possiede un valore di ricerca indipendente ed è destinato all’indicizzazione, un canonical autoreferenziale è generalmente più appropriato. Al contrario, se un parametro modifica soltanto le informazioni di tracciamento o l’ordinamento e non produce contenuti realmente nuovi, consolidarlo con la pagina principale è una scelta sensata. La decisione dovrebbe quindi partire dalla funzione della pagina, non da una regola generale applicata indistintamente a tutti i parametri.
Perché i tag canonical non sostituiscono la gestione della scansione
La canonicalizzazione aiuta i motori di ricerca a stabilire quale versione di contenuti duplicati debba essere considerata rappresentativa, ma non impedisce immediatamente ai crawler di visitare gli URL alternativi. Google può continuare a richiedere versioni parametrizzate per confrontarne il contenuto e confermare la relazione tra esse. Su un sito con poche centinaia di varianti, questo può essere irrilevante. Su un grande sito di vendita al dettaglio o una directory in cui i filtri possono generare milioni di URL, consentire la scansione di ogni variante e fare affidamento esclusivamente sui tag canonical può comunque consumare notevoli risorse del server e rallentare l’elaborazione degli URL più importanti.
Questa distinzione spiega perché i tag canonical funzionano meglio come parte di una politica URL più ampia. Gli URL duplicati che rimangono utili ai visitatori possono utilizzare la canonicalizzazione, mentre gli schemi di parametri che non hanno alcuna funzione nella ricerca possono richiedere restrizioni alla scansione. Anche la navigazione interna dovrebbe evitare, ove possibile, di generare combinazioni non necessarie. Ad esempio, se modificare l’ordine dei prodotti crea un nuovo URL, il sito non deve necessariamente inserire migliaia di link accessibili ai crawler verso ogni possibile ordinamento all’interno di ogni categoria. Ridurre il numero di URL superflui esposti tramite link interni limita il problema prima ancora che sia necessario intervenire con robots.txt o altri controlli.
La canonicalizzazione non dovrebbe essere combinata con istruzioni contraddittorie. Una pagina identificata come canonical preferita dovrebbe normalmente essere accessibile alla scansione, indicizzabile e utilizzata in modo coerente in tutto il sito. Google sconsiglia inoltre di utilizzare robots.txt come metodo di canonicalizzazione e di usare noindex semplicemente per obbligare il motore di ricerca a scegliere un’altra pagina come canonical. Quando le pagine duplicate devono rimanere accessibili, rel="canonical" è il segnale appropriato. Quando una pagina non deve comparire affatto nei risultati di ricerca, può essere opportuno utilizzare una direttiva di indicizzazione. Quando un URL non dovrebbe essere sottoposto a scansione perché appartiene a uno spazio parametrico inutile, robots.txt affronta invece un problema diverso.
Utilizzare robots.txt e i controlli di scansione senza bloccare pagine importanti
Robots.txt controlla l’accesso dei crawler a determinati schemi URL. Può quindi essere utile quando filtri, controlli di ordinamento, risultati della ricerca interna o altri parametri generano un numero molto elevato di pagine prive di valore per la ricerca. Un sito potrebbe, ad esempio, impedire a Googlebot di richiedere URL contenenti uno specifico parametro di ordinamento, lasciando invece accessibili le normali categorie e alcune landing page SEO selezionate. Le attuali linee guida di Google raccomandano espressamente di prendere in considerazione robots.txt per gli URL indesiderati della navigazione a faccette quando tali pagine non devono apparire nella Ricerca Google. Per grandi spazi URL indesiderati, questa soluzione può essere più efficace che aspettarsi che i soli tag canonical riducano gradualmente la scansione.
Robots.txt non dovrebbe però essere utilizzato come metodo per rimuovere un URL dall’indice di Google. Un URL bloccato può comunque essere individuato tramite link e, in determinate circostanze, può apparire nei risultati di ricerca senza che il suo contenuto sia stato sottoposto a scansione. Questo comportamento è diverso da noindex, che indica al motore di ricerca di non mantenere la pagina nei risultati. Affinché noindex funzioni, il crawler deve poter accedere alla pagina e leggere l’istruzione. Bloccare contemporaneamente la stessa pagina tramite robots.txt può quindi impedire a Googlebot di rilevare la direttiva noindex. Questa è una delle fonti di confusione più comuni quando il controllo della scansione e quello dell’indicizzazione vengono considerati la stessa cosa.
La gestione della scansione nei siti di grandi dimensioni dovrebbe inoltre essere proporzionata alle reali esigenze. Il crawl budget rappresenta principalmente una questione operativa per siti molto estesi, siti che cambiano rapidamente o siti in cui Googlebot si avvicina alla capacità massima del server di gestire le richieste. I siti più piccoli generalmente ottengono pochi vantaggi dal tentativo di manipolare la frequenza di scansione. Googlebot regola automaticamente la propria attività in base a diversi fattori, tra cui la risposta del server e la domanda di scansione, e Google non supporta l’istruzione non standard crawl-delay nel file robots.txt. Anche il precedente strumento di Search Console per limitare la frequenza di scansione è stato ritirato nel gennaio 2024, quindi la gestione moderna della scansione si basa soprattutto su una buona architettura degli URL, sulla stabilità del server, su regole robots.txt appropriate e sulla limitazione della generazione di URL non necessari.
Definire una politica di scansione e monitorarne i risultati
Una politica di scansione pratica parte da un inventario degli URL, non da un lungo file robots.txt. I proprietari dei siti dovrebbero identificare quali tipi di parametri producono contenuti indicizzabili, quali creano versioni duplicate e quali generano pagine prive di una funzione nella ricerca. Link interni, sitemap XML, tag canonical e regole robots.txt possono quindi sostenere la stessa strategia. Gli URL canonici dovrebbero prevalere nei link interni e nelle sitemap, le pagine filtrate utili dovrebbero rimanere accessibili alla scansione e gli spazi URL non necessari non dovrebbero essere continuamente esposti ai crawler dei motori di ricerca. Questo approccio è più sicuro rispetto all’aggiunta di regole di esclusione molto ampie senza prima comprendere quali parti del sito verrebbero interessate.
Il monitoraggio è importante perché i problemi legati ai parametri spesso diventano evidenti solo su larga scala. Google Search Console può mostrare schemi di indicizzazione, scelte canonical e statistiche di scansione, mentre i log del server forniscono un registro diretto degli URL richiesti da Googlebot. Un aumento improvviso delle richieste contenenti parametri di ordinamento, filtro o tracciamento può rivelare una trappola di scansione prima che coinvolga una parte più ampia del sito. Lo strumento Controllo URL può quindi essere utilizzato su esempi rappresentativi per verificare il canonical selezionato da Google e confermare se le pagine importanti sono accessibili alla scansione e indicizzabili. In genere, analizzare un campione di ciascun principale schema URL è più utile che controllare singolarmente indirizzi scelti a caso.
Il miglior risultato a lungo termine è un sito in cui gli URL utili siano facili da raggiungere e le varianti non necessarie siano difficili da generare per i crawler. I parametri di per sé non costituiscono un difetto SEO: il problema nasce dalla duplicazione incontrollata e da una relazione poco chiara tra indirizzi alternativi. I tag canonical stabiliscono le versioni preferite, robots.txt può limitare la scansione di spazi URL indesiderati e una gestione attenta dei link interni impedisce in partenza la creazione di molti percorsi duplicati. Quando questi segnali sono coerenti tra loro, i motori di ricerca dedicano meno risorse all’elaborazione di URL ripetitivi e dispongono di un insieme di pagine più chiaro da valutare. Per un sito di grandi dimensioni, ciò rende notevolmente più semplice gestire scansione, indicizzazione e analisi SEO.