Quando un sito si comporta in modo strano, la tentazione è andare per tentativi: disattivo un plugin, cambio un’impostazione, riprovo. Esiste però un modo molto più rapido per capire cosa succede: leggere i log. Sono i registri in cui il server annota, riga per riga, ogni visita ricevuta e ogni errore incontrato. Sembrano illeggibili al primo sguardo, ma con qualche indicazione diventano lo strumento di diagnosi più utile che hai.
Cosa sono i log e quali ti interessano
Per un sito web i registri importanti sono due:
- Log di accesso (access log): una riga per ogni richiesta ricevuta. Chi ha chiesto cosa, quando, con quale esito.
- Log degli errori (error log): gli errori del server web e, spesso, quelli di PHP. Qui trovi il motivo di un errore 500 o di una pagina bianca.
A questi si aggiunge il registro di debug delle applicazioni, come il file debug.log di WordPress o i log di PrestaShop e Magento, che raccolgono gli errori dal punto di vista del CMS.
Dove trovarli
Nel pannello DirectAdmin, che apri dall’area clienti senza password aggiuntive, c’è una sezione dedicata alle statistiche e ai log del sito, dove puoi consultare per ogni dominio gli ultimi accessi e gli ultimi errori. La posizione esatta delle voci dipende dal tema del pannello: se non la trovi, cerca “log” nella barra di ricerca del pannello oppure chiedici con un ticket. Per orientarti nel pannello trovi anche la panoramica di DirectAdmin.
Come leggere una riga del log di accesso
Una riga tipica è fatta così (i dati sono di esempio):
203.0.113.45 - - [08/Oct/2026:10:15:32 +0200] "GET /contatti/ HTTP/2" 200 18342 "https://www.google.com/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) ..."Da sinistra a destra:
| Parte | Significato |
|---|---|
203.0.113.45 |
indirizzo IP da cui arriva la richiesta |
[08/Oct/2026:10:15:32 +0200] |
data, ora e fuso orario |
"GET /contatti/ HTTP/2" |
metodo (GET per leggere, POST per inviare dati), pagina richiesta, protocollo |
200 |
codice di risposta: 200 ok, 301 reindirizzamento, 404 non trovato, 500 errore |
18342 |
dimensione della risposta in byte |
"https://www.google.com/" |
referer: la pagina da cui il visitatore è arrivato |
"Mozilla/5.0 ..." |
user agent: il browser o il bot che ha fatto la richiesta |
Il significato dei codici è spiegato nella guida agli errori HTTP.
Cosa puoi scoprire dal log di accesso
Pagine rotte
Cerca le righe con codice 404: se compaiono spesso per pagine vere del tuo sito (non per indirizzi strani come /wp-login.php su un sito che non è WordPress), hai link da correggere o reindirizzamenti da creare.
Bot e tentativi di attacco
Vedrai molte richieste che non sono di persone: motori di ricerca, crawler di intelligenza artificiale, scanner che provano password o cercano file vulnerabili. È normale. Da noi gran parte di questo traffico viene fermato da Security Intelligence e dal firewall di cPGuard; per i bot utili, come quelli dei motori di ricerca, la strada giusta è servirli dalla cache invece di bloccarli (ne parliamo in bot buoni e bot cattivi).
Picchi di traffico
Se il sito rallenta a una certa ora, guarda quante richieste arrivano in quel momento e da chi. Spesso il “traffico” è un singolo bot che scorre migliaia di combinazioni di filtri di un catalogo.
Moduli e login presi di mira
Tante richieste POST verso la pagina di login o verso un modulo di contatto, da IP diversi, indicano un tentativo automatico. Vale la pena rafforzare il login (guida: proteggere il login di WordPress).
Cosa puoi scoprire dal log degli errori
Qui le righe sono più leggibili, perché contengono un messaggio. Alcuni esempi che incontrerai:
PHP Fatal error: Allowed memory size of ... bytes exhausted: lo script ha superato la memoria consentita (vedi la guida su memory_limit);PHP Fatal error: Uncaught Error: Call to undefined function ...: codice che richiama una funzione inesistente, spesso per incompatibilità con la versione di PHP o fra plugin;PHP Parse error: syntax error: un errore di scrittura nel codice, tipico dopo una modifica manuale;- messaggi sul file
.htaccess: una direttiva non valida può far cadere tutto il sito con un errore 500.
Il messaggio contiene quasi sempre il percorso del file: .../wp-content/plugins/nome-plugin/... ti dice subito quale plugin è coinvolto.
Non spaventarti per gli avvisi di tipo PHP Warning, Notice o Deprecated: indicano codice migliorabile, ma di solito non bloccano il sito. Quello che conta, quando il sito è giù, sono i Fatal error.
Un metodo per non perdersi
- Riproduci il problema e annota l’ora esatta.
- Apri il log degli errori e cerca le righe di quel minuto.
- Leggi l’ultima riga “Fatal” prima dell’orario: di solito è la causa.
- Collega l’errore a un cambiamento: un aggiornamento, un plugin nuovo, una modifica al codice.
Dai log ai report
Leggere i log a mano va bene per un problema puntuale. Per capire come i motori di ricerca vedono il tuo sito nel tempo esiste SEO Log Intelligence, che analizza i log al posto tuo; per un’analisi generale del sito c’è AIweblab Scan e Report, con un report scritto dall’intelligenza artificiale.
Una nota sulla privacy
I log contengono indirizzi IP, che sono dati personali. Se li scarichi per analizzarli, conservali in modo sicuro e non condividerli più del necessario. Quando ce ne mandi un estratto in un ticket, bastano le righe che riguardano il problema.
Se un errore nel log non ti è chiaro, apri un ticket dall’area clienti e incolla la riga: spesso ci basta quella per indicarti la soluzione.