Esplorare tutte le pagine di un sito web implica scegliere il metodo giusto tra una decina di approcci disponibili. Sitemap XML, operatori di ricerca, crawler SEO, analisi dei log: ogni tecnica copre un ambito diverso e lascia angoli morti distinti. L’obiettivo non è conoscerle tutte, ma capire quale rileva cosa, e soprattutto cosa non rileva.
Rendering JavaScript e crawl: cosa vede realmente ogni robot
La capacità di uno strumento di esplorare le pagine di un sito dipende direttamente dalla sua gestione del JavaScript. Googlebot rende il JavaScript dal 2019 e accede quindi ai contenuti generati lato client. Al contrario, i crawler di IA generativa (GPTBot, ClaudeBot, PerplexityBot, Meta-ExternalAgent, Bytespider) non rendono alcun JavaScript: scaricano i file JS senza eseguirli.
Per un sito costruito in SPA (single-page application) o fortemente dipendente dal rendering lato client, questa differenza cambia tutto. I link interni generati dinamicamente rimangono invisibili per questi robot. Un crawl con uno strumento che non rende il JS produrrà quindi un elenco di URL incompleto, a volte in modo significativo.
Un progetto di esplorazione completa deve anche tenere conto della limite di dimensione HTML di Googlebot, fissata a 2 MB per URL. Oltre, i link situati in fondo alla pagina non vengono semplicemente letti. Gli strumenti di terze parti che imitano il pipeline di Googlebot ereditano questa restrizione.
Per coloro che cercano un punto d’ingresso concreto, è possibile esplorare le pagine del sito Marcelllin tramite la sua sitemap, il che illustra bene il funzionamento di un indice XML strutturato.
Confronto dei metodi per trovare tutte le pagine di un sito
Ogni metodo di scoperta di URL copre un ambito preciso. La tabella qui sotto sintetizza le capacità reali di sei approcci comuni.
| Metodo | Pagine indicizzate | Pagine orfane | Pagine bloccate (robots.txt) | Rendering JS |
|---|---|---|---|---|
| Operatore site: Google | Sì | No | No | Sì (tramite Google) |
| Sitemap XML | Sì (se dichiarate) | No | Possibile | Non pertinente |
| Crawler SEO (Screaming Frog, ecc.) | Sì | Parzialmente | Configurabile | Opzionale |
| Google Search Console | Sì | No | No | Sì |
| Analisi dei log server | Sì | Sì | Sì | Non pertinente |
| Crawlers IA (GPTBot, ClaudeBot) | Parziale | No | No | No |
Il risultato che emerge: nessun metodo isolato copre la totalità delle URL di un sito. L’operatore site: di Google mostra solo le pagine indicizzate, e Google non garantisce di mostrare tutte le URL conosciute. La sitemap elenca solo le URL volontariamente dichiarate dal webmaster. Solo l’analisi dei log server rileva le pagine orfane, poiché registra ogni richiesta HTTP ricevuta, comprese quelle provenienti da bot o da vecchi link esterni.
Sitemap XML e file robots.txt: due letture complementari
Il file robots.txt indica ai robot cosa non devono esplorare. Consultarlo prima di un crawl permette di individuare le directory volutamente escluse (pagine di amministrazione, ambienti di staging, URL di filtraggio). La sitemap XML, invece, fornisce l’elenco delle URL che il sito desidera vedere indicizzate.
<pIncrociare i due rivela incoerenze frequenti: URL presenti nella sitemap ma bloccate dal robots.txt, o viceversa. Questi scostamenti segnalano spesso errori di configurazione che danneggiano il posizionamento.
Crawler SEO con rendering JavaScript: l’ambito più ampio
Un crawler SEO come Screaming Frog o Sitebulb, configurato con il rendering JavaScript attivato, offre la copertura più estesa tra gli strumenti accessibili senza accesso server. Segue i link interni, esegue il JS e può integrare la sitemap come fonte di URL di partenza.
- Configurare il crawl affinché ingoi la sitemap XML come elenco di seed URLs consente di rilevare le pagine dichiarate ma non collegate internamente
- Attivare il rendering JavaScript garantisce la scoperta dei link generati dinamicamente, cosa che né la sitemap né l’operatore site: fanno:
- Esportare l’elenco delle URL crawlate e confrontarlo con i log server su un periodo dato fa emergere le pagine orfane visitate solo da bot o tramite link esterni
Questa combinazione (crawler JS + sitemap + log) costituisce il protocollo più affidabile per redigere un inventario completo delle URL di un sito.
Pagine orfane e pagine in impasse: gli angoli morti del collegamento interno
Una pagina orfana non ha alcun link interno che punta verso di essa. Esiste sul server, può essere indicizzata se un link esterno la collega, ma rimane invisibile per un crawler che parte dalla homepage. I log server sono l’unico modo per rilevarla senza conoscere in anticipo la sua URL.
Le pagine in impasse pongono un problema simmetrico: esistono nell’alberatura ma non contengono alcun link in uscita verso altre pagine del sito. Un visitatore che vi atterra non può fare altro che lasciare il sito. Per i motori di ricerca, queste pagine diluiscono il budget di crawl senza ridistribuire l’autorità tramite link interni.
- Identificare le pagine orfane incrociando log/crawl, quindi collegarle al collegamento interno o eliminarle
- Rilevare le pagine in impasse dall’assenza di link in uscita nell’esportazione del crawler
- Verificare che ogni pagina strategica sia accessibile in massimo tre clic dalla homepage
Un sito di diverse migliaia di pagine accumula naturalmente queste anomalie nel corso delle ristrutturazioni e degli aggiustamenti di contenuto. Un audit trimestrale del collegamento interno limita il debito tecnico.
Struttura del sito e budget di crawl: cosa prioritizzano i motori
I motori di ricerca allocano un numero limitato di richieste per sessione di crawl a ciascun sito. Questo budget di crawl dipende dalla dimensione del sito, dalla sua velocità di risposta e dalla frequenza di aggiornamento. Una struttura piatta, in cui ogni pagina è accessibile in pochi livelli di profondità, facilita la scoperta rapida di tutte le URL.
Le URL parametriche (filtri, ordinamenti, paginazioni) consumano il budget di crawl senza apportare contenuti unici. Bloccarle nel robots.txt o gestirle tramite tag canonical riduce lo spreco. Il robots.txt controlla il crawl, il tag canonical controlla l’indicizzazione: entrambi agiscono a livelli diversi e si completano a vicenda.
L’architettura di un sito determina anche la profondità massima raggiunta dai crawler. Oltre cinque livelli di profondità, la probabilità che una pagina venga crawlata durante una sessione diminuisce notevolmente. Ridurre la profondità media rimane il leva strutturale più diretto per migliorare la copertura di crawl.