Come leggere il log del web server

Introduzione

In questa guida vorrei spiegare come recuperare, leggere ed interpretare il log del web server con Excel. Se preferisci usare software server-side puoi provare GOACCESS.

Prima di tutto però vediamo perché dovremmo dedicare tempo a questo file. Analizzare i dati presenti nel log del web server è fondamentale per capire come gli spider dei motori di ricerca navigano un sito web, ovvero la frequenza di scansione, il volume di scansione e la profondità di scansione.

• Frequenza di scansione: la frequenza indica quante volte una risorsa viene richiesta dallo spider.
• Volume di scansione: il volume rappresenta il numero di pagine del sito web richieste dallo spider.
• Profondità di scansione: il numero di livelli di navigazione del sito web raggiunti dallo spider

I log sono utilizzati per analisi SEO ma anche per altri scopi, per esempio la web analytics, ma questa guida vuole concentrarsi sugli aspetti utili all’ottimizzazione per i motori di ricerca.

A cose serve il log del web server

Il log del web server è un file dove vengono registrate, appunto dal web server, tutte le richieste effettuate da client esterni (utenti e bot) verso le risorse ospitate (pagine web, immagini, javascript, ecc). Leggere il log del web server è un’attività snobbata e sottovalutata da molti addetti ai lavori. Personalmente credo sia una delle cose più importanti da fare quando si fa SEO.

Possiamo fare tutte le supposizioni di questo mondo, ma nulla ci darà dati pratici come un log.

Osservando i comportamenti degli spider è possibile capire:

• se la navigazione del sito web è ottimale oppure se ci sono pagine difficilmente raggiungibili,
• quanto tempo impiega lo spider a rilevare i nuovi contenuti pubblicati,
• l’interesse degli spider dei motori di ricerca verso le pagine del sito web,
• quantificare il Crawl Budget che Google assegna al nostro sito web.

Nel log troviamo gli accessi di tutti gli User-Agent che hanno richiesto risorse ma è particolarmente interessante filtrare solo gli spider di Google, denominati Googlebot.

Googlebot potrebbe essere più interessato a certi siti e meno ad altri, potrebbe controllare più spesso una pagina invece di un’altra. I suoi comportamenti variano da sito a sito e da pagina a pagina. Ci sono molti fattori che incidono sulla frequenza, volume e profondità di scansione, vediamone alcuni:

• L’originalità dei contenuti: Googlebot tende a scansionare di meno siti con contenuti copiati o duplicati.
• La frequenza di pubblicazione: la frequenza con cui si pubblicano nuovi contenuti sul sito o si aggiornano quelli esistenti impatta sulla frequanza di scansione di Googlebot.
• Errori 4xx e 5xx: quando Googlebot individua errori di navigazione di solito in un primo momento esegue una serie di richieste successive per verificare l’eventuale ripristino. In caso negativo riduce il crawl rate.
• La velocità del web server: un sito veloce riesce ad inviare maggiori risorse a Googlebot rispetto ad uno lento. Googlebot non perde mai tempo, se un server non è abbastanza rapido passa al successivo.
• Il valore delle nostre pagine: il PageRank è il fattore principale che determina la profondità delle scansioni di Googlebot, ma non è il solo fattore.
• Link on-page: una pagina che contiene molti link in uscita, a tema e di qualità, viene controllata da Googlebot abbastanza spesso.
• La grandezza del sito web: il numero di pagine pubblicate sul sito è un fattore che induce lo spider a scansionare il sito web più a fondo.
• Livelli: il numero di livelli di navigazione su cui è organizzato il sito incide sulla profondità di scansione. In genere Google non ama siti con troppi livelli.
• link interni: la struttura dei link interni impatta sulla distribuzione del PageRank e quindi sulle priorità di scansione di Googlebot.
• Il crawl budget: ovvero la quantità massima di banda che Google ha deciso di dedicare al sito.

Dove recuperare il log del web server

I log dei vari web server possono essere trovati di default in queste cartelle:

• Apache: /var/log/apache2/access.log – link
• Nginx: /var/log/nginx/access.log – link
• Microsoft IIS: C:\Windows\System32\LogFiles – link

Ogni web server ha le sue opzioni per configurare il file di log, quindi è possibile che i tuoi log siano archiviati in cartelle diverse e abbiano nomi diversi da access.log.

I servizi di hosting low-cost o hosting condivisi difficilmente permettono di accedere ai log del server, Aruba ad esempio vende separatamente il servizio di statistiche. Con hosting virtuali, dedicati e in cloud, avendo a disposizione il sistema operativo, è possibile accedere ai file di log.

Esempio di stringa estratta dal log

Il file di log del web server tipicamente appare come un elenco di righe di questo tipo:

212.209.212.xx - [29/Jul/2010:00:35:33 -0500] "GET /contatti/ HTTP/1.1" 200 11631 "https://www.evemilano.com/" "Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0)"

Nota: differenti web server producono log che possono variare leggermente l’uno dall’altro.

Come aprire il file di log

Sebbene esistano molti software sia free che a pagamento come ad esempio Apache Logs Viewer, per leggere il file di log basta Excel.

Conosci Screaming Frog? Gli stessi sviluppatori hanno creato e reso pubblico un tool per leggere i file di log del web server.

Gli elementi del log del web server

IP address: “212.209.212.xx”. Questo dato è l’indirizzo IP della macchina che ha contattato il web server. Per risolvere l’indirizzo IP ed avere un’idea di che tipologia di macchina si tratti, puoi usare un reverse-DNS oppure usare il comando TRACEROUTE.
User name: “- -“. Il nome utente è rilevante solo in casi in cui la risorsa interrogata sia protetta da password.
Timestamp: “[29/Jul/2010:00:35:33 -0500]”. La voce Timestamp rappresenta l’orario in cui è stata richiesta la risorsa al web server.
Access request: “GET /contatti/ HTTP/1.1”. Questa stringa rappresenta la risorsa richiesta al web server.

• In questo caso la richiesta è di tipo “GET” (significa “mostrami la pagina”) per il file /contatti/ usando il protocollo “HTTP/1.0”.
• Una richiesta di tipo “HEAD” legge soltanto l’intestazione HTTP del documento (document header) ed equivale a “pingare” la risorsa per verificare che sia ancora li e che non sia cambiata.
• Una richiesta di tipo “POST” è utilizzata per inviare dati al web server.

Result status code: “200”. I codici di stato sono definiti dall’ITEF (RFC 2616) e da alcune RFC con codici di stato addizionali e non standardizzati. Microsoft IIS può usare altri sotto codici decimali non standard per specificare più dettagli aggiuntivi. In questo caso lo status code 200 indica che la risorsa richiesta esiste.

La prima cifra del codice di stato specifica una delle cinque categorie di risposta:

• 1xx Informational: richiesta ricevuta, continua l’elaborazione,
• 2xx Success: l’azione è stata ricevuta con successo, compresa ed accettata,
• 3xx Redirezione: il client deve eseguire ulteriori azioni per soddisfare la richiesta,
• 4xx Client Error: la richiesta è sintatticamente scorretta o non può essere soddisfatta,
• 5xx Server Error: il server ha fallito nel soddisfare una richiesta apparentemente valida.

Bytes transferred: “11631”. Numero di byte trasferiti. Nel caso trovassi valori inferiori al peso dei file richiesti significa che la richiesta non è stata completata e sono stati forniti al client dati parziali. Alcuni User-Agent possono scaricare un file un pezzo alla volta, ogni pezzo scaricato viene identificato con una linea dedicata nel log del web server, quindi una serie di “hits” il cui totale equivale alla dimensione del file significa che il download è avvenuto con successo. Se le dimensioni del file invece non coincidono col totale scaricato in più momenti dallo stesso user-agent può significare che ci sono problemi di connessione.

Referrer URL: “https://www.evemilano.com/”. Questo valore rappresenta la pagina referrer. Non tutti gli user-agent supportano questa informazione. Questa è la pagina che il visitatore ha visitato prima di atterrare sul tuo sito. Solitamente questo significa che quella pagina ha un link verso il tuo sito, oppure a volte è semplicemente la pagina che l’utente visitava prima di raggiungere il tuo sito. Questa informazione è molto utile per identificare quali siti guidano traffico verso le nostre pagine (referrals).

User-Agent: “Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0)”. Valore identificativo dell'”User-Agent”. L’User-Agent rappresenta il software che sta richiedendo la risorsa sul tuo sito. Solitamente è un browser, ma potrebbe anche essere un bot dei motori di ricerca, un link checker, un client FTP oppure un browser offline.

L’User-Agent della spider di Google (Googlebot) è:

Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)

Come unire molti file log in uno solo

Conosco un metodo rapido su SO di Bill… In Windows:

• esegui il Prompt dei comandi: Start > CMD.
• naviga nella cartella dove hai scaricato tutti i log successivi, ad esempio digitanto nel prompt cd c:/temp/log
• inserisci il commando for /R %f in (*.log.*) do type “%f” >> c:\temp\output.log

Lanciando il comando dalla cartella che contiene tutti i file di log verrà generato un nuovo file che li contiene tutti. Analizzare i dati ora sarà molto più semplice.

Leggere il log in tempo reale sulla SHELL

Nel caso avessi accesso diretto al tuo web server puoi leggere il log in tempo reale sulla SHELL. Per verifiche rapide a volte questo metodo mi torna utile, di seguito ti spiego che comandi utilizzare.

Il comando tail serve a monitorare i cambiamenti in un file, in tempo reale. Come risultato stampa il delta a schermo.

Prova questo comando per vedere tutto quello che succede nel web server:

tail -f /var/log/apache/access.log

Aggiungi il comando grep per filtrare solo il traffico di Googlebot:
Prova questo comando per vedere tutto quello che succede nel web server:

tail -f /var/log/apache/access.log | grep 'Googlebot'

Con questo comando invece semplifichiamo la visualizzazione mostrando solo URL della richiesta eseguita da Googlebot, e status code.

grep 'Googlebot' /var/log/apache/access.log | awk '{print $8, $10}'

PS: gioca con i due valori di print, ad esempio per il log Nginx devo usare {print $7, $9}, 7 per l’URL e 9 per lo status code (dipende da come è formattato il tuo file di log).

Video

Considerazioni

Ora che sei capace di scaricare il log del web server, aprirlo con Excel e comprendere i dati, non resta che fare le considerazioni del caso. Ti lascio qualche spunto.

• Quali sono le pagine più visitate da Googlebot?
• Quali pagine non sono visitate da Googlebot?
• Quali relazioni ci sono tra le pagine più visitate da Googlebot?
• Quali relazioni ci sono tra le pagine meno visitate da Googlebot?
• Con che frequenza Googlebot torna sul sito?
• Quanto impiega Googlebot a ricevere le pagine dal web server?
• Come reagisce Googlebot ad un cambiamento importante sul sito web?
• Ci sono bot aggressivi da bloccare via Robots.txt?