Pubblicato il - Aggiornato il
Crawling SEO: cos’è la scansione di un sito e come ottimizzarla
SEO
Quando gestisci un ecommerce o un sito molto strutturato, la cosa da valutare è quanto spesso Googlebot scansiona le pagine giuste e quanta energia spreca su filtri, parametri, duplicati e URL inutili. Capire il crawling in modo data-driven significa leggere i segnali reali (log, header, status code) e incrociarli con ciò che vedi in Search Console, per misurare dove stai bruciando crawl budget e dove invece stai rallentando indicizzazione e performance.
L’obiettivo qui è trasformare l’analisi in priorità operative chiare: cosa correggere prima, quali KPI usare per validare l’impatto. Partiamo dalle basi della scansione di un sito web.
Indice dei contenuti
Cos’è il crawling e perché conta
Il crawling è la fase in cui Googlebot scopre gli URL (tramite link interni/esterni e sitemap) e li richiede al server. In questa fase contano tantissimo i segnali “meccanici”: struttura dei link, risposta del server, status code, tempo di risposta e quantità di URL disponibili da esplorare. Su ecommerce con categorie, filtri e varianti, il punto non è avere “tante pagine”, ma avere troppe versioni della stessa pagina.
Un aspetto spesso sottovalutato è che la scansione non è solo “visitare l’HTML”. Se una pagina richiede rendering pesante (JavaScript, risorse bloccate, chiamate lente), il costo di scansione sale e la copertura può peggiorare. In pratica: più la pagina è complessa da recuperare, più è probabile che il bot riduca la frequenza o distribuisca male le richieste, soprattutto su siti molto estesi.
Da qui nasce la prima priorità operativa: ridurre la superficie di URL inutili e rendere immediata la scoperta di quelli che contano (categorie strategiche, prodotti in stock, contenuti evergreen). Se questa base non è solida, tutto il resto (ottimizzazioni di contenuto incluse) tende ad avere un impatto più lento e meno prevedibile.
Come funziona il crawling dei motori di ricerca (Google)
Capire come lavora Googlebot aiuta a prendere decisioni migliori su sitemap, link interni, JavaScript e performance. Non serve conoscere ogni dettaglio interno di Google, ma è utile capire il percorso: Google scopre un URL, lo richiede, ne analizza il contenuto e decide se vale la pena indicizzarlo. È proprio in questi passaggi che nascono molti problemi di scansione.
Googlebot e comportamento di scansione
Per la SEO, il crawler più importante è Googlebot Smartphone, perché Google utilizza un indice mobile-first. Se la versione mobile del sito è lenta, incompleta o bloccata, la scansione e la valutazione delle pagine ne risentono direttamente.
Dal punto di vista operativo, è importante verificare che Googlebot riceva risposte corrette dal server. Configurazioni errate di WAF, CDN o sistemi anti-bot possono limitare o alterare la scansione senza che il problema sia evidente agli utenti. Quando analizzi i log, inoltre, ricorda che non tutti gli user-agent che si dichiarano Googlebot sono autentici: per analisi approfondite conviene sempre validare i dati.
Come Google scopre le URL
Google scopre nuove URL soprattutto attraverso i link interni ed esterni. La sitemap XML è un supporto importante, ma non sostituisce una buona architettura del sito: una pagina presente nella sitemap ma isolata dal linking interno avrà spesso una priorità inferiore.
Per questo motivo, il linking interno è una leva di crawling ancora prima che di ranking. Su siti molto grandi, collegare correttamente le pagine strategiche significa aiutare Google a scoprirle e aggiornarle più frequentemente.
Allo stesso tempo, è importante evitare di esporre URL inutili: filtri, ordinamenti o combinazioni prive di valore SEO possono finire nel grafo di scansione e sottrarre risorse alle pagine che generano traffico e conversioni.
Crawling e rendering
Nella maggior parte dei casi Googlebot riesce a estrarre contenuti e link direttamente dall’HTML. Quando invece una pagina dipende fortemente da JavaScript, entra in gioco il rendering: una fase aggiuntiva, più costosa e potenzialmente più fragile.
Per questo è buona pratica fare in modo che l’HTML iniziale contenga già i segnali fondamentali, come contenuti principali e link essenziali, evitando di bloccare le risorse necessarie al rendering. Soluzioni come SSR o pre-rendering possono migliorare sia l’efficienza della scansione sia la stabilità dell’indicizzazione.
Qui sotto trovi il video ufficiale di Google Search Central che spiega il crawling.
Crawling, indicizzazione e ranking: differenze che cambiano le priorità
Nel lavoro quotidiano su siti grandi è facile usare questi tre termini come sinonimi, ma in realtà descrivono fasi diverse e, soprattutto, richiedono fix diversi. Se confondi i livelli, rischi di ottimizzare la cosa sbagliata (magari il contenuto) mentre il problema reale è a monte (scansione) o a valle (indicizzazione). Qui la regola pratica è: prima fai arrivare Google sulle pagine giuste, poi fai sì che le consideri indicizzabili, infine lavora per farle competere e posizionare (ranking).
La scansione lo abbiamo visto nelle sezioni precedenti. Ora approfondiamo gli altri aspetti.
Indicizzazione: cosa finisce nell’indice (e cosa resta fuori)
L’indicizzazione è la fase in cui Google decide se salvare (e come salvare) una pagina nel proprio indice. Qui entrano in gioco segnali come canonical, noindex, duplicazione, qualità e unicità del contenuto, ma anche aspetti tecnici: pagine che rispondono 200 ma hanno contenuto “scarso” o incoerente possono essere scansionate e comunque restare fuori.
In Search Console questa dinamica si vede bene nel report “Pagine”: URL “Scoperta, attualmente non indicizzata” o “Scansionata, attualmente non indicizzata” spesso indicano che Google conosce la pagina ma non la considera prioritaria o abbastanza valida da tenere in indice. Per questo l’ottimizzazione del crawling va sempre letta insieme alla qualità dell’informazione e al controllo dei duplicati.
Ranking: come la pagina compete nei risultati
Il ranking è la fase in cui, a parità di indicizzazione, Google decide dove posizionare una pagina per una query specifica. È il livello più visibile perché impatta direttamente sul traffico, ma dipende dai due livelli precedenti: una pagina non scansionata o non indicizzata non può iniziare a competere.
Ottimizzare la scansione, quindi, non è un esercizio tecnico fine a sé stesso: significa far sì che Google veda spesso ciò che vuoi spingere e molto meno ciò che non vuoi far “consumare” al bot. E questo crea un contesto più stabile per le attività di contenuto e di CRO.
Problemi tecnici che bloccano la scansione (o la rendono inefficiente)
Molti siti spesso hanno una somma di piccoli attriti tecnici che, su larga scala, diventano enormi. L’obiettivo non è azzerare ogni anomalia, ma eliminare quelle che spostano davvero la distribuzione delle scansioni o impediscono a Google di leggere correttamente le pagine importanti.
Status code e redirect: 3xx, 4xx, 5xx che rubano crawl budget
I redirect 3xx sono normali, ma diventano un problema quando sono in catena (A→B→C) o, peggio, in loop. Ogni salto è una richiesta in più e, su siti grandi, si traduce in migliaia di richieste “sprecate” al giorno. Inoltre, catene e loop complicano i segnali di canonicalizzazione e rallentano la scoperta della destinazione finale.
I 4xx sono un’altra fonte di spreco tipica negli ecommerce: prodotti rimossi, categorie rinominate, URL generate da filtri che poi spariscono. Se l’internal linking continua a puntare a URL non valide, Googlebot continuerà a provarci. Qui spesso la fix non è solo “fare redirect”, ma ripulire link interni e regole che generano URL errate.
Gli errori 5xx (o timeout) sono ancora più impattanti perché toccano la capacità di scansione: se il server è instabile, Google rallenta. In questi casi la priorità diventa tecnica e immediata: stabilità, caching, riduzione del tempo di risposta e monitoraggio, perché un miglioramento lato server può aumentare la copertura molto più di qualunque micro-ottimizzazione SEO.
Robots.txt, meta robots e X-Robots-Tag: governare cosa può essere scansionato
Qui serve chiarezza: robots.txt controlla la scansione, mentre i meta tag robots (es. noindex) controllano l’indicizzazione, ma per leggere un noindex Google deve poter scansionare la pagina. Se blocchi una directory via robots.txt e poi ti aspetti che Google “veda” il noindex o il canonical, stai inviando segnali contraddittori.
Errore frequente: bloccare risorse utili (CSS/JS) e rendere più difficile il rendering, oppure ereditare regole da ambienti di staging che finiscono in produzione. Su siti grandi, queste regressioni succedono: per questo è utile trattare robots.txt come un file “di progetto”, con controllo versione e review tecnica.
Per file non HTML (PDF, feed, asset) può entrare in gioco l’X-Robots-Tag, che permette di impostare noindex a livello di header HTTP. È una leva potente, ma va governata: prima di applicarla su larga scala, valida sempre su un campione e misura l’effetto nei log e in Search Console.
Canonical, duplicati e navigazione a faccette: ridurre la superficie di URL
Il tag canonical è uno dei principali strumenti per dire a Google qual è la versione “preferita” di un contenuto, soprattutto quando esistono molte varianti di URL. Ma funziona bene solo se i segnali attorno sono coerenti: link interni che puntano alla canonica, sitemap pulite, assenza di contraddizioni (tipo canonica verso A ma internal link che spinge B).
La navigazione a faccette (filtri) è il terreno più delicato: alcune combinazioni hanno valore SEO (e vanno rese indicizzabili), altre vanno trattate come varianti tecniche. In quel caso la scelta è architetturale: riduci le combinazioni esposte, controlla l’indexabilità e fai in modo che Google trovi facilmente le pagine “hub” che vuoi far posizionare.
Un buon indicatore di salute è vedere coerenza tra: URL in sitemap, URL linkate internamente e URL che ricevono scansioni nei log. Quando queste tre liste non “si parlano”, quasi sempre stai alimentando duplicati e sprechi.
Fattori che influenzano crawlability e profondità di scansione
Quando un sito cresce, non è solo “cosa” è indicizzabile a contare, ma anche “quanto in profondità” Googlebot riesce ad arrivare in modo affidabile. La crawlability dipende da accesso (direttive e status code), ma anche da architettura, performance e coerenenza dei segnali. Lavorare su questi fattori significa rendere più prevedibile la scansione e ridurre sprechi sistemici.
Architettura del sito, link interni e crawl depth (click depth)
La crawl depth (o click depth) è una metrica pratica: quante “mosse” servono, partendo da pagine forti (home, categorie principali), per arrivare a una risorsa. Non esiste una soglia magica valida per tutti, ma in generale le pagine troppo profonde ricevono meno attenzione e vengono aggiornate meno spesso, soprattutto su siti con tante URL concorrenti.
La profondità non dipende solo dal menu: dipende dall’intero sistema di linking (breadcrumb, moduli “prodotti correlati”, pagine hub editoriali, link in template). Su ecommerce, ad esempio, prodotti fuori categoria, o raggiungibili solo tramite ricerca interna, finiscono spesso per essere “deboli” dal punto di vista di crawling e quindi più lenti da consolidare in indice.
Un modo concreto per rendere la depth più “corta” senza stravolgere il sito è creare percorsi di scoperta intenzionali: categorie ben strutturate, sottocategorie sensate, collegamenti tra cluster tematici e pagine “di raccolta” che funzionano da snodo. Poi validi nei log: se dopo il fix vedi crescere le richieste Googlebot sulle directory strategiche, hai migliorato davvero la scansione.
Controlli di accesso e segnali di preferenza: robots, canonical e parametri URL
Nel controllo della scansione, l’obiettivo non è “vietare tutto”, ma rendere chiaro cosa vuoi far trattare come pagina primaria e cosa come variante tecnica. Robots.txt, meta robots, X-Robots-Tag, canonical e gestione dei parametri URL funzionano bene quando non si contraddicono tra loro e quando l’internal linking li supporta.
Un punto spesso sottovalutato è la normalizzazione: se lo stesso contenuto è raggiungibile con e senza slash finale, con maiuscole/minuscole, con parametri di tracking o con querystring inutili, stai aumentando artificialmente la superficie di crawling. La soluzione più pulita è combinare regole di routing (per ridurre le varianti) con canonical coerenti e link interni “puliti” che puntano sempre alla versione preferita.
Nota operativa: Google oggi si affida molto ai segnali on-page e al linking; strumenti specifici per la gestione parametri in Search Console non sono più la leva principale. Per questo, su siti grandi, conviene risolvere a monte (URL generation e linking) invece di sperare in una “scorciatoia” lato motore di ricerca.
Blocchi e direttive: robots.txt, noindex e risorse essenziali non accessibili
Un blocco in robots.txt può essere corretto o disastroso a seconda di cosa stai impedendo di scansionare. Il problema tipico non è bloccare “pagine inutili”, ma bloccare risorse necessarie (CSS/JS) o pagine che dovrebbero consolidarsi in indice. Quando succede, spesso te ne accorgi tardi: la pagina è online, ma Google la interpreta male o non riesce a valutarla come pensi.
Con noindex, invece, l’errore frequente è usarlo in modo incoerente con canonical e linking interno. Se linki fortemente pagine che poi dichiari noindex, stai dicendo a Google “sono importanti” e “non indicizzarle” nello stesso tempo. Su larga scala questo genera spreco e stati ambigui in Search Console.
La soluzione “sostenibile” è una: definire un set di URL primarie (quelle che vuoi davvero indicizzare) e allineare attorno a quel set tre elementi: linking interno, sitemap e direttive (robots/canonical/noindex). Quando questi tre livelli sono coerenti, Googlebot spreca meno e la copertura migliora in modo più stabile.
URL problematiche: duplicati, filtri, paginazioni e problemi di rendering
Duplicati e URL “quasi uguali” sono una delle cause più comuni di scansione inefficiente, perché creano un grafo interno enorme che Googlebot prova comunque a esplorare. Filtri e faceted navigation sono spesso la fonte: combinazioni infinite, contenuti simili, canonical incoerenti, paginazioni profonde che moltiplicano ulteriormente le varianti.
Sulla paginazione, la priorità è rendere i contenuti facilmente raggiungibili da Google. Infinite scroll senza alternative crawlable o contenuti caricati solo tramite JavaScript possono rendere la scoperta delle pagine più fragile. Per questo è importante mantenere percorsi navigabili e link HTML chiari, evitando al tempo stesso di moltiplicare URL e combinazioni prive di valore.
Infine, i problemi di rendering possono limitare ciò che Googlebot riesce a vedere. Se contenuti e link vengono generati solo lato client tramite JavaScript, Google deve eseguire una fase aggiuntiva di rendering prima di poterli elaborare. Per questo, sulle pagine strategiche, conviene esporre già nell’HTML iniziale i contenuti e i link principali, così da rendere la scansione più semplice e affidabile.
Crawler SEO e audit della scansione: Screaming Frog e pagine orfane
Search Console e log ti dicono cosa succede davvero, ma un crawler SEO ti aiuta a simulare una scansione controllata e a scoprire problemi strutturali prima che diventino “sistema”. È particolarmente utile quando devi capire la crawl depth, mappare redirect e canonical, o individuare pagine importanti non collegate internamente. Se lavori per iterazioni, un crawl periodico è anche un ottimo controllo di qualità post-deploy.
Screaming Frog: come usare un crawler SEO in modo operativo
Con Screaming Frog (spesso chiamato anche “SEO frog crawler”), puoi configurare una scansione molto vicina al comportamento di un bot: scegliere user-agent, gestire robots, seguire redirect, e perfino fare rendering JavaScript per verificare cosa viene realmente visto in fase di rendering. L’aspetto più utile, in ottica crawling, è che ti restituisce pattern: dove stai generando troppe URL, dove ci sono catene 3xx, quali template hanno canonical incoerenti.
Un workflow pragmatico è usare il crawl come “fotografia” della struttura interna e poi incrociare con i log. Se Screaming Frog trova migliaia di URL con parametri linkate internamente, e nei log vedi Googlebot che le scansiona spesso, hai una conferma end-to-end: non è un problema teorico, è un consumo reale di risorse.
Individuare pagine orfane incrociando crawl, sitemap e dati reali
Le pagine orfane sono URL che esistono (e magari sono in sitemap), ma non ricevono link interni. Su siti grandi è più comune di quanto sembri: prodotti non assegnati a categorie, landing create per campagne poi “dimenticate”, contenuti editoriali non collegati a nessun hub.
Per trovarle in modo affidabile, evita di basarti su una sola fonte. La combinazione che funziona meglio è: crawl del sito (cosa è linkato), sitemap (cosa dichiari importante) e dati reali (log e/o landing page da analytics). Quando una pagina è “in sitemap ma non linkata” e in più non riceve scansioni regolari, quasi sempre stai perdendo opportunità: o la colleghi meglio, o la declassi (noindex) se non ha un ruolo strategico.
Il valore non è “avere zero orfane” (impossibile su progetti grandi), ma assicurarti che non lo siano le pagine che ti aspetti portino traffico organico o conversioni. E qui torna la regola d’oro: la struttura dei link interni è uno dei modi più diretti per orientare il crawler.
Strategie pratiche per migliorare il crawling SEO
Dopo diagnosi e monitoraggio, serve un set di azioni ripetibili che migliorino davvero la scansione: più attenzione alle pagine importanti, meno spreco su varianti e errori, maggiore stabilità nel tempo. Le strategie migliori sono quelle che restano valide anche quando il sito cambia: nuove categorie, nuovi filtri, nuovi contenuti. In altre parole: ottimizzazioni sostenibili, misurabili e facili da mantenere.
Incrementare scoperta e priorità delle pagine importanti con linking interno e sitemap
Se vuoi che Googlebot visiti spesso una pagina, devi renderla facile da trovare e collegarla da URL che Google già scansiona frequentemente. La sitemap XML è un ottimo segnale di discovery, ma il linking interno è ciò che spesso determina la priorità reale: menu, categorie, hub tematici, breadcrumb, moduli “popolari” o “più venduti” possono spostare la distribuzione di scansione in modo netto.
Una strategia che funziona bene su ecommerce è trattare le categorie come “pagine hub” e alimentarle con collegamenti coerenti: categorie principali ben raggiungibili, sottocategorie sensate, pagine editoriali che linkano le categorie strategiche e viceversa. Poi misuri: nei log dovrebbe aumentare la quota di richieste su directory core e ridursi la quota su varianti tecniche.
Quando hai pagine che cambiano spesso (prodotti in stock, pagine news, listini), cura anche i segnali di aggiornamento: lastmod affidabile in sitemap e percorsi interni che le espongano a frequenza di scansione più alta. È un modo concreto per ridurre il ritardo tra aggiornamento e riflesso in SERP.
Ridurre sprechi: parametri, duplicati, thin content e gestione canonical/noindex
Ridurre lo spreco significa restringere la superficie di URL “interessanti” per il bot. In pratica: meno parametri inutili, meno combinazioni di filtri crawlable, meno duplicati e meno pagine a basso valore che continuano a essere scansionate solo perché sono linkate ovunque.
Sul piano operativo, la priorità è mettere ordine sui template che generano thin content o pagine quasi identiche. A volte la soluzione è consolidare (unire contenuti), altre volte è dichiarare in modo coerente che certe varianti non vanno in indice (noindex) o che devono convergere su una canonica. L’importante è evitare segnali “misti”: sitemap che include varianti, link interni che le spingono, canonical che dice il contrario.
Un indicatore semplice per capire se stai andando nella direzione giusta è questo: la quota di scansioni su URL canoniche e indexabili deve crescere nel tempo, mentre la quota su parametri e duplicati deve scendere. Se succede, stai liberando crawl budget dove serve.
Stabilizzare la scansione: performance server, velocità frontend e ottimizzazione redirect
La stabilità del crawling si costruisce con performance backend (server veloce e affidabile) e con un frontend che non renda ogni pagina “costosa” da processare. Googlebot si adatta: se trova lentezza, errori, timeout, riduce la velocità di scansione e diventa più conservativo.
Sul backend, le leve classiche sono caching, CDN, ottimizzazione del TTFB e gestione dei picchi. Sul frontend, invece, ridurre JavaScript superfluo e dipendenze lente migliora sia l’esperienza utente sia la “leggibilità” delle pagine per il motore di ricerca, soprattutto quando entra in gioco il rendering.
Infine, non sottovalutare l’impatto dei redirect: ripulire catene, aggiornare i link interni verso la destinazione finale e ridurre 3xx inutili è uno dei fix più “silenziosi” ma più efficaci per liberare richieste. È una di quelle attività che non fa rumore, ma che si vede chiaramente nei log.
Come far scoprire e (ri)scansionare le pagine importanti
Ottimizzare il crawling non significa solo eliminare ostacoli, ma anche aiutare Google a capire quali URL sono importanti e quali sono cambiate davvero. Su siti molto estesi, la priorità è fornire segnali chiari e coerenti.
La sitemap XML resta uno dei canali più efficaci per segnalare a Google le URL da scoprire e monitorare, ma deve contenere solo pagine canoniche, indicizzabili e prive di errori. Una sitemap piena di redirect, URL duplicate o bloccate genera rumore e riduce l’efficacia del segnale.
Su ecommerce e siti complessi è spesso utile segmentare le sitemap (categorie, prodotti, contenuti editoriali) e raccoglierle in un sitemap index. In Search Console conviene monitorare regolarmente stato di invio, URL lette ed eventuali errori, soprattutto dopo rilasci o modifiche strutturali.
Lo strumento Controllo URL è invece utile per verificare casi specifici: controllare la canonica scelta da Google, individuare blocchi e validare rapidamente un fix tecnico prima di estenderlo all’intero sito. La funzione “Richiedi indicizzazione” va usata con moderazione: è utile per URL strategiche o appena aggiornate, ma non sostituisce una corretta strategia di crawling.
Anche il campo lastmod può aiutare Google a capire quali pagine meritano una nuova scansione, purché rifletta modifiche reali. Aggiornarlo automaticamente senza cambiamenti effettivi ne riduce il valore. In generale, i segnali più affidabili restano contenuti aggiornati, internal linking coerente e sitemap pulite.
Come sempre, la verifica finale è nei dati: analizza i log e misura quanto tempo passa tra una modifica e la successiva visita di Googlebot alle pagine strategiche.
Dai log alle performance: fai scansionare a Google quello che ti fa crescere
Su siti grandi il crawling è gestione di risorse. Se separi bene crawling, indicizzazione e ranking e lavori in modo data-driven, inizi a creare una mappa chiara del sito pronta per guidare Googlebot verso URL utili, riducendo sprechi su duplicati, parametri e pagine a basso valore. Il punto è sempre lo stesso: meno frizione per il bot (struttura, status code, velocità, rendering), più controllo sul percorso di scansione e più prevedibilità sull’impatto.
Se vuoi rendere questa parte davvero operativa, comincia dai dati: incrocia log server e Search Console, definisci pochi KPI di crawling che contano per il business e monitora tutto in una dashboard, così per ogni fix si definisce una priorità e poi valida. Se invece ti serve una mano per trasformare questi insight in una roadmap di implementazione sostenibile (con priorità chiare e metriche di successo), contattami.
Mirko Ciesco
Data-Driven Growth Specialist
Aiuto aziende e startup a prendere decisioni migliori per crescere in modo misurabile. Sono specializzato in Web Analytics e performance digitale e lavoro all’intersezione tra dati, strategia e crescita.