Trappole di scansione: gli spazi infiniti del sito

Una trappola di scansione è uno spazio di URL che il tuo stesso sito continua a generare, pagina dopo pagina, senza che nessuno lo abbia pianificato così. Non parliamo di filtri, ordinamenti o parametri di tracciamento in querystring: quello è un problema di parametri URL, affrontato in un articolo dedicato, e lì la soluzione passa quasi sempre da un canonical o da una regola di normalizzazione sulla stringa di query. Qui la trappola è più subdola, perché spesso nell'URL non c'è nessun punto interrogativo: è un calendario che propone sempre il mese successivo, una combinazione di filtri diventata un percorso statico, uno scroll infinito che continua a caricare pagine oltre l'ultimo contenuto reale, o un link relativo scritto male che si annida su se stesso all'infinito.

Il sintomo che porta chi legge fin qui è quasi sempre lo stesso: Googlebot scansiona migliaia di URL che nessuna persona visiterà mai, il budget di scansione si consuma su pagine che non valgono nulla, e in Search Console il rapporto «Scansionata, non indicizzata» cresce senza una causa evidente. Vediamo come riconoscere ciascun tipo di trappola dalla sua firma nei log, e come si corregge — perché bloccarla in robots.txt senza toccare il link che la genera non risolve il problema, lo nasconde soltanto.

Cos'è (e cosa non è) una trappola di scansione

Una trappola di scansione esiste quando seguire link perfettamente funzionanti — nessun errore, nessun 404, risposta 200 su tutta la linea — porta a un numero di URL nuovi che cresce senza un limite naturale, e ognuno di questi URL ne genera altri a sua volta. È utile distinguerla da due cose con cui viene spesso confusa.

Non è un errore di scansione: un errore è una richiesta che fallisce, un 404, un 500, un redirect rotto, ed è un problema già trattato altrove. Una trappola è l'opposto: la richiesta riesce sempre, il server risponde con contenuto valido, e proprio per questo è più difficile da individuare. Niente segnala che qualcosa non va, perché tecnicamente non sta andando nulla di storto: il sito sta facendo esattamente ciò per cui è stato costruito, solo senza un punto di arresto.

Non è nemmeno il problema dei parametri URL. Filtri, ordinamenti, ID di sessione e parametri di tracciamento in querystring hanno una soluzione consolidata basata su canonical e regole sui parametri, e sono trattati in un articolo a parte. Le trappole di cui parliamo qui nascono dalla struttura di navigazione del sito, non dalla querystring: l'URL è spesso pulito, senza un solo punto interrogativo, il che le rende invisibili a chi ha già risolto il problema dei parametri e pensa di aver chiuso la questione.

Le famiglie più comuni che vedremo sono quattro:

• Calendari che continuano a produrre mesi futuri all'infinito
• Combinazioni di faccette che si moltiplicano da sole
• Scroll infinito senza un vero limite legato al contenuto
• Link relativi che si annidano su se stessi

Calendari che continuano a produrre mesi futuri

Un widget di calendario — booking, eventi, disponibilità — quasi sempre mostra un link «mese successivo». Un crawler che lo segue arriva al mese dopo, trova di nuovo un link «mese successivo», lo segue ancora, e così via. Un calendario, per definizione, non ha una fine: non esiste un mese oltre il quale il link semplicemente scompare, a meno che qualcuno non l'abbia codificato esplicitamente.

Il risultato è che il crawler può camminare avanti di anni, generando migliaia di pagine quasi identiche tra loro: stesso template, nessun evento programmato, cambia solo la data nell'intestazione. Ognuna di queste pagine è tecnicamente valida, risponde 200, ha un contenuto anche se vuoto, e non genera nessun errore che un audit tecnico superficiale possa intercettare. Il numero di URL generati non è fissato da nessuna proprietà del calendario stesso: è pari, semplicemente, al numero di richieste che un crawler è disposto a fare prima di rinunciare.

Combinazioni di faccette che si moltiplicano da sole

La navigazione a faccette — colore, taglia, marca, fascia di prezzo — è la spina dorsale di quasi ogni catalogo e-commerce, e il problema che crea è ben noto quando è implementata con parametri in querystring. Ma quando le stesse faccette sono implementate come segmenti di percorso invece che come parametri — /scarpe/running/nike/nere/42/ invece di ?colore=nere&taglia=42 — smettono di somigliare a un problema di parametri e cominciano a somigliare a normali pagine di categoria statiche. Chi ha già sistemato la querystring spesso considera chiuso il capitolo, e proprio per questo la trappola sopravvive indisturbata.

Il meccanismo è combinatorio, non additivo: aggiungere una quarta faccetta a tre già esistenti non aggiunge un certo numero di pagine, le moltiplica per il numero di valori possibili di quella faccetta. La maggior parte di queste combinazioni ha zero o un solo prodotto corrispondente, il testo attorno cambia poco o nulla da una combinazione all'altra, e il risultato è un numero enorme di pagine sottili e quasi duplicate che il crawler continua comunque a trovare, perché ogni pagina di faccetta linka ad altre faccette applicabili.

Un esempio aiuta a vedere la scala del problema: un catalogo con cinque colori, sei taglie e quattro marche genera, moltiplicando semplicemente queste tre faccette tra loro, oltre un centinaio di percorsi diversi per una sola sottocategoria di prodotto — e questo prima ancora di aggiungere fascia di prezzo, disponibilità o valutazione. Ogni faccetta aggiuntiva non si somma alle altre, si moltiplica con loro, ed è per questo che un catalogo che sembra avere poche centinaia di prodotti può facilmente esporre un numero di percorsi combinatori di ordini di grandezza superiore.

Scroll infinito senza un vero limite

Lo scroll infinito è una scelta di interfaccia legittima: l'utente scorre, il contenuto si carica, nessuno clicca su «pagina 2». Il problema nasce quando, dietro le quinte, quello scorrimento corrisponde a URL reali e paginati — /articoli/pagina/842 — e quel numero di pagina non è vincolato al conteggio effettivo dei contenuti disponibili.

Se il server continua a rispondere con un 200 anche oltre l'ultima pagina che ha davvero senso, magari restituendo un contenitore vuoto o ripetendo gli ultimi elementi, il crawler non ha nessun segnale per capire che ha raggiunto la fine. Un 200 vuoto viene letto come «c'è ancora contenuto da esplorare», non come «sei arrivato in fondo», e la scansione continua a spingersi oltre, richiesta dopo richiesta, su pagine che non contengono più nulla di reale.

Link relativi che si annidano su se stessi

Questa è la trappola meno intuitiva delle quattro, ed è un vero bug di codice più che una questione di regole di scansione. Succede quando un link è scritto come percorso relativo invece che assoluto, e quel percorso relativo viene risolto rispetto alla directory corrente invece che rispetto alla radice del sito.

Un esempio concreto: dalla pagina /catalogo/, un link relativo «prodotti/» punta correttamente a /catalogo/prodotti/. Il problema si manifesta se lo stesso componente — spesso un elemento di template condiviso, come una scheda «prodotti correlati» o un breadcrumb mal configurato — ripropone lo stesso link relativo «prodotti/» anche sulla pagina appena raggiunta. Da /catalogo/prodotti/, quel link relativo non punta più a /catalogo/prodotti/ come ci si aspetterebbe, ma a /catalogo/prodotti/prodotti/. Se il server o il CMS instradano qualunque profondità di percorso verso lo stesso contenuto — cosa comune quando il routing riconosce solo l'ultimo segmento dell'URL e ignora tutto ciò che lo precede — quella pagina risponde comunque 200, con lo stesso link relativo al suo interno, e la profondità continua a crescere senza limite: /catalogo/prodotti/prodotti/prodotti/, e così via all'infinito.

Non c'è nessun errore server-side che segnali il problema, perché dal punto di vista del server ogni richiesta è legittima e riceve una risposta valida. È una delle poche trappole di scansione che non si corregge con regole o direttive, ma solo intervenendo sul codice che genera il link.

Riconoscere la trappola: la firma nei log e in Search Console

La firma di una trappola di scansione nei log del server è riconoscibile: un pattern di URL specifico — tutto ciò che comincia con /calendario/, o con /catalogo/prodotti/ — riceve un volume di richieste da Googlebot sproporzionato rispetto al numero di pagine reali che quel pattern dovrebbe generare, mentre le richieste provenienti da sessioni utente reali sullo stesso pattern restano praticamente piatte. È logico: una persona non clicca duecento volte su «mese successivo», ma un crawler che segue link non ha motivo di fermarsi prima. Quando questo squilibrio compare in modo netto su un solo pattern di percorso, hai individuato la sezione responsabile, ancora prima di sapere quale delle quattro famiglie sia in gioco.

In Search Console il segnale complementare è la crescita del rapporto «Scansionata, non indicizzata» concentrata su URL che condividono lo stesso pattern: significa che Google ha visitato quelle pagine, ha valutato il contenuto e ha deciso, sistematicamente, che non merita un posto nell'indice — esattamente ciò che ci si aspetta da migliaia di varianti quasi identiche di uno stesso calendario o di una stessa combinazione di faccette.

Vale la pena una nota a parte per le pagine di risultati di ricerca interna collegate da qualche punto del sito: quando questi risultati sono paginati con URL puliti invece che con querystring, il pattern che si osserva nei log è molto simile a quello di una trappola di scansione ordinaria. È una delle sorgenti più comuni di trappole senza punto interrogativo, ma merita un trattamento specifico che va oltre lo scopo di questo articolo, ed è già approfondito in un articolo dedicato proprio alle pagine di risultati della ricerca interna.

Un ultimo controllo utile, prima di intervenire, è capire da dove viene il link che alimenta la trappola: risalendo dalla pagina più profonda che compare nei log fino alla pagina che genera il primo link della catena, di solito si arriva a un unico punto — un widget di calendario, un blocco di faccette correlate, un componente di template — ed è esattamente lì, e non sulle migliaia di pagine generate, che va applicata la correzione.

La correzione, trappola per trappola

Ogni famiglia richiede un intervento diverso, perché la causa è diversa:

• Calendari: metti un limite esplicito ai mesi futuri visibili (dodici o diciotto mesi sono ragionevoli per la maggior parte dei casi), rimuovi o disattiva il link «mese successivo» oltre quella soglia invece di lasciarlo attivo all'infinito, e sulle pagine che restano raggiungibili oltre il limite applica un canonical verso il mese corrente o un noindex,follow.
• Faccette: decidi esplicitamente quali combinazioni meritano una pagina indicizzabile, di solito una singola faccetta alla volta e non tutte le combinazioni possibili, applica un canonical dalle combinazioni minori verso la pagina di categoria pulita, e soprattutto limita a monte, nel template che genera i link, quali combinazioni vengono effettivamente collegate nel sito.
• Scroll infinito: fai coincidere l'ultima pagina realmente disponibile con il conteggio effettivo dei contenuti, e oltre quel limite restituisci un segnale inequivocabile — un 404, o un redirect alla prima pagina — invece di un 200 vuoto che il crawler continuerà a interpretare come «c'è ancora altro da vedere».
• Link relativi annidati: qui non basta nessuna direttiva di scansione, perché il problema è nel codice. Converti i link in percorsi assoluti, o correggi la base da cui vengono risolti i percorsi relativi, e verifica nei log, dopo il rilascio, che la profondità dei percorsi smetta effettivamente di crescere.