Crawl waste nei cataloghi: come controllare faccette, parametri e URL senza valore
2 Settembre 2026 · SEO
Prima di iniziare
Il perimetro di «Crawl waste nei cataloghi» deve essere approvato prima di raccogliere dati. Le prime due condizioni da rendere esplicite sono «Pattern URL inventariati» e «Googlebot verificato nei log». Senza queste fondamenta il team rischia di produrre un’analisi corretta dal punto di vista tecnico ma incapace di modificare il processo reale.
Prima di confrontare crawl e log, occorre allineare il campione: intervallo temporale, fuso orario, host inclusi, regole di normalizzazione dei parametri e modalità con cui viene riconosciuto Googlebot. Va anche annotato quali filtri sono generati dal frontend, quali dalle sitemap o dai link interni e quali sopravvivono da configurazioni precedenti.
Criteri di completamento
| Condizione | Evidenza richiesta | Governance |
|---|---|---|
| Pattern URL inventariati | Documento, configurazione, test o dato che dimostra il completamento | Owner e data di revisione |
| Googlebot verificato nei log | Documento, configurazione, test o dato che dimostra il completamento | Owner e data di revisione |
| Faccette utili selezionate | Documento, configurazione, test o dato che dimostra il completamento | Owner e data di revisione |
| Robots, noindex e canonical usati correttamente | Documento, configurazione, test o dato che dimostra il completamento | Owner e data di revisione |
| Sitemap pulite | Documento, configurazione, test o dato che dimostra il completamento | Owner e data di revisione |
| Test pilota prima del rollout | Documento, configurazione, test o dato che dimostra il completamento | Owner e data di revisione |
Un pattern può essere segnato come risolto quando un nuovo crawl non lo genera più nei percorsi indesiderati, i log confermano il comportamento atteso e i controlli su canonical, robots, noindex e sitemap non introducono conflitti. Il test va ripetuto sia su URL già noti sia su combinazioni appena create.
Quando il metodo non è sufficiente
Su cataloghi distribuiti tra CDN, motore di ricerca interno, PIM e frontend, una correzione SEO può incidere su cache, navigazione o disponibilità dei prodotti. Le modifiche che toccano regole server, dati personali nei parametri o grandi insiemi di URL richiedono quindi verifiche infrastrutturali, di sicurezza o legali pertinenti al caso.
L’esito va descritto in termini osservabili: pattern rimossi dai link, richieste dei crawler redistribuite e URL utili ancora raggiungibili. Da questi segnali si può formulare una valutazione tecnica, non dedurre automaticamente crescita organica o ricavi, perché domanda, concorrenza, qualità del catalogo e comportamento dei motori restano variabili esterne.
Distinguere crawl waste e crawl budget
Il crawl budget diventa critico soprattutto nei siti grandi o molto dinamici. Il crawl waste è una diagnosi più concreta: richieste ripetute a URL senza valore, parametri, redirect, errori o faccette inutili.
Inventariare le fonti di moltiplicazione
Ordinamento, prezzo, disponibilità, sessione, tracking, paginazione, ricerca interna, combinazioni di attributi e varianti possono creare URL. Ogni pattern deve avere funzione e regola.
Usare log e crawl insieme
Il crawler mostra ciò che il sito collega; i log mostrano ciò che i bot richiedono. L’incrocio identifica spazi invisibili, richieste legacy e differenze tra Googlebot e altri crawler.
Scegliere lo strumento corretto
Robots limita la scansione ma non garantisce rimozione dall’indice; noindex richiede accesso; canonical consolida segnali ma non impedisce sempre il crawl; rimuovere link e parametri inutili agisce alla fonte.
Proteggere le faccette utili
Alcune combinazioni hanno domanda e contenuto autonomo. Devono avere URL stabile, Title, testo, linking e controllo delle combinazioni. Le altre restano funzioni di navigazione.
Monitorare dopo le modifiche
Riduzione delle richieste inutili, aumento della quota su template importanti, status più puliti e maggiore rapidità di aggiornamento sono segnali, non garanzie di ranking.
Matrice operativa
| Pattern | Valore utente | Indicizzazione | Intervento |
|---|---|---|---|
| Ordinamento | Temporaneo | No | URL non linkato/canonical |
| Filtro singolo richiesto | Alto | Possibile | Landing governata |
| Combinazione rara | Basso | No | Faccetta non indicizzabile |
| Ricerca interna | Alto per utente | Generalmente no | Bloccare spazio e misurare |
| Parametro tracking | Nessun contenuto nuovo | No | Pulizia link/canonical |
Applicazione operativa
Il primo deliverable è un catalogo dei pattern URL, non un elenco di singole pagine. Ogni pattern indica origine, parametri, link che lo generano, status, canonical, indicizzazione desiderata e valore utente. Questo rende possibile intervenire sul template.
Nei log si segmentano Googlebot, altri bot e utenti, verificando gli indirizzi secondo la documentazione Google. Si confronta la quota di richieste su categorie, prodotti, filtri, redirect, errori e asset. Il dato assoluto conta meno della distribuzione.
Le modifiche vanno testate su una faccetta o categoria pilota. Cambiare robots, canonical e linking su tutto il catalogo contemporaneamente può rendere difficile capire quale intervento ha prodotto l’effetto.
Come misurare il risultato
Si osservano richieste su URL non desiderati, catene, errori, tempo di risposta, scoperta di nuovi prodotti e frequenza di scansione degli URL prioritari. La riduzione delle richieste inutili è positiva se non riduce l’accesso a contenuti utili.
L’indicizzazione va controllata separatamente: bloccare la scansione di un URL già indicizzato non equivale a rimuoverlo.
Esempio ragionato
Un catalogo permette di combinare colore, materiale, disponibilità, ordine e fascia prezzo. Ogni click crea un URL linkabile. I log mostrano che gran parte delle richieste dei crawler riguarda ordinamenti e combinazioni senza domanda.
Il progetto conserva landing governate per materiale e applicazione, rende gli ordinamenti non linkabili, pulisce i parametri e aggiorna sitemap e canonical. Dopo il test, la scansione si concentra maggiormente su prodotti e categorie.
Checklist di esecuzione
- Pattern URL inventariati
- Googlebot verificato nei log
- Faccette utili selezionate
- Robots, noindex e canonical usati correttamente
- Sitemap pulite
- Test pilota prima del rollout
Errori da evitare
- Bloccare tutto in robots senza verificare l’indice.
- Applicare noindex a milioni di URL e aspettare risparmio immediato.
- Creare landing per ogni filtro disponibile.
- Analizzare solo il crawl del tool e non i log.
- Confondere minore crawl con migliore ranking automatico.
Domande frequenti
Googlebot ha un limite per singola pagina?
Google ha documentato nel 2026 un limite di fetch di 2 MB per molti URL non PDF; è distinto dal crawl budget del sito.
I parametri URL sono sempre negativi?
No. Sono un problema quando creano duplicati, spazi infiniti o segnali incoerenti.
Conviene disalloware i filtri?
Dipende da indicizzazione, linking e necessità di vedere canonical o noindex. Va progettato per pattern.
Fonti e riferimenti
- Google Crawling Infrastructure — Crawl Budget Management — https://developers.google.com/crawling/docs/crawl-budget
- Google Crawling Infrastructure — Faceted navigation URLs — https://developers.google.com/crawling/docs/faceted-navigation
- Google Search Console — Crawl Stats report — https://support.google.com/webmasters/answer/9679690?hl=en
Come trasformare la guida in un’attività concreta
Classificare tutti i pattern di URL, incrociare crawl e log, scegliere quali faccette meritano landing e rimuovere alla fonte le combinazioni prive di valore.
Approfondisci il servizio: SEO tecnica.