Analisi dei log del webserver: tips and tricks

Continuiamo a parlare di scansione e scansionabilità, affrontando un argomento altrettanto tecnico: l’analisi dei log del webserver (topic che abbiamo approfondito all’ultimo SeriousMonkey).

I file dei “log” sono estremamente utili – sebbene tristemente poco utilizzati – perché ricchi di preziosi insight relativi a come il motore di ricerca scansiona un sito in un particolare periodo di tempo. Non si tratta di congetture, astrazioni o opinioni personali: i log assicurano dati concreti, reali, mostrando esattamente ciò che sta accadendo nelle retrovie del nostro sito. Ecco perché è essenziale analizzare i log del server, al fine di rendere ancor più efficace la vostra strategia SEO.

Analizzare i log significa prendere in considerazione le richieste di accesso effettuate al webserver che ospita il nostro sito, ottenendo molti preziosi insight.

Cos’è l’analisi dei Log?

L’analisi dei Log consiste nell’analizzare le richieste di accesso che vengono effettuate al webserver che ospita il nostro sito.

analisi webserver

Per effettuare l’analisi è quindi necessario ottenere uno o più file di Log, file che contengono l’elenco delle richieste di accesso al sito. Per ogni richiesta vengono solitamente riportate le seguenti informazioni:

  • La data e l’ora della richiesta
  • L’URL richiesto
  • Lo User Agent
  • L’indirizzo IP dello user agent
  • Lo Status Code
  • La grandezza della pagina richiesta
  • Il tempo di risposta del server
  • La pagina dalla quale lo user agent proviene

access log

Essenziale avere familiarità con il concetto di Crawl Budget e con i fattori che lo definiscono: il Crawl Rate Limit e la Crawl Demand.

Concetti propedeutici

Se ci seguite con assiduità, ricorderete un articolo di un po’ di tempo fa dedicato al Crawl Budget, ossia, l’insieme delle risorse che Google dedica alla scansione. In buona sostanza, ottimizzare il crawl budget vuol dire fare in modo che Google utilizzi le sue risorse per scansionare le pagine più importanti per il nostro business. L’entità del Crawl Budget dipende essenzialmente da due fattori: il Crawl Rate Limit e la Crawl Demand.

Il Crawl Rate Limit è il numero massimo di connessioni simultanee che Google può effettuare per scansionare il sito. Esso può essere influenzato in due modi: dalle performance e impostazioni del server e dalle impostazioni di SearchConsole con le quali si può decidere di ridurlo ma non, ovviamente, di incrementarlo.

La Crawl Demand è la domanda di scansione ed indica quanto un sito è meritevole di essere scansionato. Essa dipende da due variabili principali, la popolarità del sito (in termini di link ricevuti) e la qualità dei contenuti.

L’analisi dei log è sostanzialmente finalizzata ad ottimizzare il crawl rate limit e la crawl demand, è finalizzata quindi alla crawl budget optimization.

Il processo di analisi: user agent

L’analisi degli User Agent ci consente di:

  • Capire se il sito viene scansionato da Bot non utili o dannosi;
  • Capire se tutti i bot di Google (o almeno quelli che ci interessano) stanno scansionando il sito.

Impedendo l’accesso a bot inutili o dannosi si alleggerisce il lavoro del server che può quindi accogliere maggiori richieste da parte dei bot di Google. Se ad esempio il nostro sito non si rivolge né alla Cina né alla Russia risulterà certamente utile bloccare Baiduspider e YandexBot.

L’analisi degli URL è fondamentale per rilevare dispersione di Crawl Budget su pagine inutili, pagine orfane o generazione infinita di URL.

Il processo di analisi: URL

L’analisi degli URL ci consente di capire se:

  • Googlebot richiede più spesso gli URL più importanti del sito;
  • Googlebot sta richiedendo URL inutili;
  • ci sono pagine lente;
  • ci sono pagine troppo grandi;
  • sul sito esistono meccanismi di generazione infinita di URL;
  • Google sta scansionando pagine orfane;
  • ci sono URL non scansionati.

Può accadere che Googlebot scansioni poco le pagine che sono più importanti per il nostro business. Perché questo accade? Prima di effettuare qualunque altro tipo di intervento occorre verificare se esistono ostacoli tecnici che impediscono a Goooglebot di raggiungere agevolmente determinate pagine. Se tali ostacoli non esistono probabilmente le pagine in questione hanno una crawl demand non adeguata alla loro importanza e quello che dobbiamo fare è cercare di aumentarla agendo sul contenuto, sul linking interno e sulla link popularity delle pagine stesse.

Potrebbe poi accadere che Googlebot scansioni pagine inutili. Un caso tipico è quello dei fenomeni di duplicazione gestiti con il noindex o con il canonical. Sappiamo bene che il noindex e il canonical ci consentono di evitare problematiche in SERP dovute a duplicazioni ma non ci consentono di evitare che Googlebot scansioni pagine duplicate; se tali pagine sono tante Googlebot sta sprecando tanto crawl budget ed è bene correre ai ripari. La soluzione più rapida ed efficace consiste certamente nel bloccare l’accesso alle duplicazioni da Robots.txt ma non sempre è conveniente. Le pagine duplicate potrebbero infatti ricevere link dall’esterno e bloccandole da Robots.txt si perderebbero i benefici di questi link. Occorre quindi valutare caso per caso, fermo restando che la soluzione migliore sarebbe quella di intervenire lato sviluppo al fine di evitare che le pagine duplicate si generino.

Googlebot potrebbe anche perdersi all’interno di meccanismi di generazioni infinita di URL, come spesso accade quando si imbatte nelle pagine di filtro di e-commerce di grandi dimensioni. Il sistema di filtri di un e-commerce può arrivare a generare milioni di URL, tutti sostanzialmente inutili ai fini SEO.

Consigliamo di non far indicizzare le pagine filtro, per evitare che i bot si perdano e sprechino Crawl Budget scansionando migliaia – o milioni – di URL privi di valore.

filtri ecommerce

Il mio parere personale è che non bisognerebbe mai far indicizzare le pagine di filtro; se esiste l’esigenza di puntare al posizionamento di particolari keyword si possono trovare soluzioni alternative, ne esistono diverse tutte molto valide. L’unico modo per evitare che Googlebot si perda tra milioni di URL privi di valore consiste nel bloccare l’accesso da Robots.tx. Anche in questo caso però la soluzione migliore sarebbe un’altra: sviluppare il sistema di filtri in modo che non generi URL scansionabili.

Ecco cos’è successo a un nostro cliente, sito e-commerce di grandi dimensioni:

pagine filtro

Una singola pagina di listing è arrivata a generare quasi due milioni di pagine filtro, che Googlebot ha scansionato in un solo giorno. Secondo voi Google ha usato bene il suo crawl budget?

Può accadere che alcune pagine scansionate da Google non vengano rilevate dal nostro Screaming Frog, potrebbero cioè esistere pagine non linkate all’interno del sito. La presenza di pagine orfane potrebbe essere normale. Potrebbe ad esempio accadere che per un sito e-commerce si decida di non linkare le pagine dei prodotti momentaneamente non disponibili, per poi tornare a linkarle quando i prodotti saranno nuovamente in stock. In casi come questo è normalissimo che esistano pagine orfane ma può anche accadere che la presenza di pagine orfane non abbia, almeno a prima vista, alcuna spiegazione logica. In questi casi occorre quantomeno indagare per capire come mai tali pagine non sono state inserite all’interno della struttura di link del sito. Al contrario, potrebbero esistere pagine che pur essendo correttamente linkate all’interno del sito non vengono scansionate mai da Google. In questi casi possiamo escludere problematiche legate alla crawl demand: se Googlebot non scansiona mai un URL esiste certamente un ostacolo di natura tecnica.

È anche possibile individuare gli URL più pesanti e quelli per i quali il server impiega più tempo a rispondere. Velocizzando i tempi di risposta si ottimizza il budget di scansione che Google ha destinato al nostro sito.

Il processo di analisi: directories

L’analisi delle directory ci consente di:

  • Capire se Googlebot scansiona directory che non dovrebbe scansionare;
  • Verificare se Googlebot scansiona di più le directory maggiormente importanti per noi;
  • Valutare se Googlebot attribuisce maggiore importanza ad una country/lingua.

directory

Quest’ultimo punto è particolarmente importante perché ci consente anche di capire se esistono meccanismi di redirezione automatica basati sulla geolocalizzazione che ostacolano l’attività di scansione di Googlebot: non dimenticate mai che Googlebot svolge la sua attività quasi sempre con i IP statunitensi.

L’analisi dei log può aiutarvi anche a verificare che gli status code impostati sulle vostre pagine siano corretti.

Il processo di analisi: status code

L’analisi degli status code ci consente di capire diverse cose. Innanzitutto: Googlebot riceve gli stessi Status code ricevuti dagli utenti? È importantissimo che Google sia trattato esattamente come un utente, se è trattato diversamente è necessaria un’analisi approfondita finalizzata a comprendere cause ed eventuali danni di una situazione che possiamo senza dubbio definire anomala.

Errori 404

Gli errori 404 sono un problema da un punto di vista SEO? Spero che la risposta si nota a tutti: assolutamente no. Il problema potrebbe però esistere se le pagine 404 sono tante e Googlebot continua a richiederle insistentemente, a scapito di pagine più importanti. Diamo per scontato che non si tratti di link rotti all’interno del sito (ce ne saremmo accorti ancor prima di effettuare l’analisi dei log) e partiamo dal presupposto che si tratti di URL non più linkati, magari da molto tempo. Se siamo certi che queste pagine non verranno mai rimesse on line possiamo sostituire lo status code 404 con lo status code 410 il quale, in teoria, dovrebbe garantire un processo di deindicizzazione più rapido.

Redirect 301

Cosa succede se dai log risultano milioni di status code 301? Una conclusione affrettata potrebbe portarci a dire “hanno fatto una migrazione e l’hanno gestita bene, bravi!”. Una conclusione più attenta ci porterebbe invece a dire “ecco l’ennesima migrazione gestita in modo superficiale”. Spesso i SEO considerano i redirect come la panacea di tutti mali e si dimenticano che ogni volta che si imposta un redirect si costringe Googlebot ad inviare due richieste al server, una relativa al vecchio url e una relativa al nuovo. Immaginate di avere un sito con due milioni di pagine e di dover fare una migrazione; il sito in questione riceve visite solo da un milione di pagine mentre l’altro milione è composto da pagine che non portano visite, non sono linkate dall’esterno e non sono previste sul nuovo sito. Come vi comportate? Se la risposta è “redirigo tutto verso la home” state facendo un grosso errore di valutazione.

Il processo di analisi: l’IP

Analizzando gli indirizzi IP dei bot di Google è possibile verificare se:

  • Google scansiona il sito anche con IP non statunitensi;
  • se si tratta realmente dei Google o è un bot che utilizza lo User Agent di Google.

Strumenti utili per la log file analysis

Uno degli strumenti più utilizzati e più semplici è Screaming Frog Log File Analyser. Esistono tanti altri strumenti simili, sia lato server che lato client, più o meno performanti in base alle dimensioni del sito e al numero di richieste che riceve. Si tratta generalmente di software a pagamento ma attenzione, nessuno di essi è realmente necessario. Se siete armati pazienza e buona volontà potete aprire i file di log con Excel e fare la vostra analisi dei log “a mano”. Per un elenco dei migliori software a pagamento consultate questa pagina.

Paolo Amorosi SEO Coordinator di Pro Web Consulting