WordPress Log Monitoring per Agenzie: Rilevare Problemi prima dei Clienti [2026]

Il WordPress log monitoring è la differenza tra un’agenzia che scopre i problemi dal ticket di un cliente furioso e una che li risolve prima che il cliente se ne accorga. Nella nostra esperienza su 50+ siti gestiti con AgencyPilot, configurare un sistema di logging strutturato sugli errori PHP, sui warning e sulle query lente ha ridotto i ticket di emergenza del 60% in sei mesi.

Questa guida mostra come configurare il WordPress log monitoring su ogni tipo di installazione, dal singolo sito al multi-sito di agenzia, con strumenti gratuiti e procedure testate su siti reali nel 2026.

TL;DR

• WP_DEBUG e WP_DEBUG_LOG attivano il logging nativo di WordPress in wp-content/debug.log
• Configura error_reporting in wp-config.php per filtrare notice, warning e fatal error separatamente
• Query Monitor è il plugin gratuito migliore per il debugging in tempo reale (query DB, hook, HTTP API)
• Su Nginx, il log degli errori PHP va in /var/log/nginx/error.log; su Apache in /var/log/apache2/error.log
• Per agenzie multi-sito: centralizza i log con un script bash che raccoglie debug.log da ogni installazione e invia alert via webhook Discord o Slack

Perché il WordPress Log Monitoring è critico per le agenzie

Gestisci 30 siti WordPress. Uno di questi ha un plugin che genera un fatal error su una pagina di checkout WooCommerce. Il cliente lo scopre dopo 3 giorni perché le conversioni sono crollate. Ti scrive un’email alle 18 di venerdì. Tu non sapevi nulla.

Senza log monitoring, sei sempre un passo dietro ai problemi. Con il monitoring attivo, ricevi un alert entro 60 secondi dal fatal error e puoi intervenire prima che impatti il business del cliente.

I tre vantaggi concreti del WordPress log monitoring per un’agenzia:

1. Tempo di rilevamento: da giorni a minuti. Un fatal error su una pagina critica viene segnalato subito, non quando il cliente controlla i analytics.
2. Diagnosi più veloce: invece di reproduire il bug al buio, apri il log e vedi esattamente file, riga e stack trace dell’errore.
3. Trust del cliente: quando scrivi “abbiamo già risolto il problema sulla pagina X, era un conflitto con il plugin Y” prima che il cliente lo segnali, il tuo contratto di manutenzione si paga da solo.

Configurare WP_DEBUG e WP_DEBUG_LOG in wp-config.php

Il primo step è attivare il sistema di logging nativo di WordPress. Apri wp-config.php e aggiungi queste costanti prima di /* That's all, stop editing! */:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

Cosa fanno queste quattro righe:

• WP_DEBUG attiva la modalità debug di WordPress (notice, warning, deprecated functions)
• WP_DEBUG_LOG scrive tutti gli errori in wp-content/debug.log invece di mostrarli a schermo
• WP_DEBUG_DISPLAY a false nasconde gli errori dal frontend (fondamentale in produzione)
• display_errors a 0 previene che PHP mostri errori che potrebbero leakare path del server

Il file wp-content/debug.log viene creato automaticamente al primo errore. Da quel momento, ogni notice, warning e fatal error di WordPress viene registrato con timestamp, tipo di errore, file e riga.

Filtrare il livello di errore in produzione

In produzione non vuoi loggare ogni notice di deprecation (riempie il file di rumore). Aggiungi un filtro su error_reporting:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );
@ini_set( 'error_reporting', E_ERROR | E_WARNING | E_PARSE | E_CORE_ERROR | E_COMPILE_ERROR );

Così logghi solo fatal error, warning e parse error. I notice vengono silenziati. Se stai debuggando un problema specifico, riattiva temporaneamente E_ALL.

Configurazione avanzata: log personalizzato con wp-config

Il file debug.log default va bene per un singolo sito. Per un’agenzia che gestisce multi-sito sullo stesso server, vuoi log separati per ogni installazione. Definisci un path personalizzato:

define( 'WP_DEBUG_LOG', '/var/log/wordpress/sito-cliente-debug.log' );

Assicurati che la directory /var/log/wordpress/ esista e sia scrivibile dall’utente del web server (di solito www-data):

sudo mkdir -p /var/log/wordpress
sudo chown www-data:www-data /var/log/wordpress
sudo chmod 755 /var/log/wordpress

Con questa configurazione, ogni sito ha il suo file di log separato. Quando un cliente chiama, apri il file specifico invece di cercare in un log globale da 500 MB.

Log PHP a livello server: Nginx e Apache

WordPress logga gli errori della sua applicazione. Ma PHP ha un suo error log a livello server che cattura tutto, incluso errori fatali che killano il processo prima che WordPress possa loggarli.

Nginx + PHP-FPM

Con Nginx e PHP-FPM, il log degli errori PHP è configurato in due posti:

In /etc/php/8.4/fpm/php.ini:

error_log = /var/log/php8.4-fpm.log
log_errors = On
error_reporting = E_ALL & ~E_DEPRECATED & ~E_STRICT

In /etc/nginx/sites-available/sito-cliente:

server {
    error_log /var/log/nginx/sito-cliente-error.log;
    access_log /var/log/nginx/sito-cliente-access.log;
}

Il log di Nginx cattura errori 500, 502, 503, 504 e errori PHP fatali che non vengono gestiti da WordPress. Il log di PHP-FPM cattura errori a livello di processo (segfault, memory limit exceeded, timeout).

Apache

Su Apache, il log è in /var/log/apache2/error.log di default. Configurazione per virtual host:

<VirtualHost *:443>
    ServerName sito-cliente.it
    ErrorLog ${APACHE_LOG_DIR}/sito-cliente-error.log
    CustomLog ${APACHE_LOG_DIR}/sito-cliente-access.log combined
</VirtualHost>

Separare il log per virtual host è essenziale. Un log globale mixato con 30 siti è inutile quando devi trovare l’errore di un cliente specifico.

Query Monitor: il miglior plugin gratuito per il debugging WordPress

Query Monitor è il plugin che installiamo su ogni sito durante la fase di sviluppo e manteniamo attivo (con restrizioni di accesso) anche in produzione. Non è solo un log viewer: è un pannello di controllo completo per diagnosticare problemi WordPress.

Mostra in tempo reale:

• Query al database (tempo di esecuzione, query duplicate, query lente)
• Hook e action attivate (utile per trovare conflitti tra plugin)
• Chiamate HTTP API (timeout, errori di connessione, response code)
• Errori PHP e notice (con stack trace completo)
• Script e style enqueueati (per identificare asset non necessari)
• Condizioni della cache (object cache, page cache, opcode cache)

Per un’agenzia, Query Monitor vale oro quando un cliente dice “il sito è lento”. Apri la barra di admin, vai su Query Monitor e vedi esattamente quale query sta prendendo 2.3 secondi o quale plugin sta facendo 47 chiamate HTTP a un’API esterna.

Configurare Query Monitor in produzione

Di default Query Monitor è visibile solo agli amministratori. Per restringere ulteriormente l’accesso in produzione, aggiungi al wp-config.php:

define( 'QM_DISABLE_ERROR_HANDLER', false );
add_filter( 'qm/show_extended_query_info', '__return_true' );

E nel functions.php del tema o in un plugin mu-plugins:

add_filter( 'qm/user_access', function( $user ) {
    if ( ! in_array( $user->user_email, [ 'tu@email.it' ] ) ) {
        return false;
    }
    return $user;
} );

Così solo tu (o il tuo team) vedete Query Monitor. I clienti con account admin non lo vedono.

Centralizzare i log per agenzie multi-sito

Se gestisci 20+ siti WordPress, aprire il debug.log di ognuno manualmente non scala. Serve un sistema che centralizza i log e invia alert quando qualcosa si rompe.

Script bash: raccoglitore di log con alert Discord

Ecco uno script bash che usiamo su AgencyPilot per raccogliere i log da tutti i siti e inviare alert su Discord quando trova fatal error:

#!/bin/bash
# wp-log-monitor.sh — Controlla debug.log di tutti i siti e alerta su Discord

SITES_DIR="/var/www"
DISCORD_WEBHOOK="https://discord.com/api/webhooks/YOUR_WEBHOOK"
LOG_DIR="/var/log/wordpress-monitor"
TIMESTAMP=$(date +"%Y-%m-%d %H:%M:%S")

mkdir -p "$LOG_DIR"

for site_dir in "$SITES_DIR"/*/; do
    site_name=$(basename "$site_dir")
    debug_log="${site_dir}wp-content/debug.log"
    
    if [ ! -f "$debug_log" ]; then
        continue
    fi
    
    # Cerca fatal error nelle ultime 24 ore
    fatal_count=$(grep -c "Fatal error\|Parse error\|Uncaught" "$debug_log" 2>/dev/null || echo "0")
    
    if [ "$fatal_count" -gt 0 ]; then
        # Estrai gli ultimi 5 errori
        recent_errors=$(grep "Fatal error\|Parse error\|Uncaught" "$debug_log" | tail -5)
        
        # Salva per il report
        echo "[$TIMESTAMP] $site_name: $fatal_count fatal errors" >> "$LOG_DIR/alerts.log"
        
        # Invia alert a Discord
        payload=$(jq -n \
          --arg content "ALERT: $site_name ha $fatal_count fatal error(s) in debug.log" \
          '{content: $content}')
        
        curl -s -X POST "$DISCORD_WEBHOOK" \
          -H "Content-Type: application/json" \
          -d "$payload"
    fi
    
    # Rotazione: se il log supera 50MB, comprimi e archivia
    log_size=$(stat -c%s "$debug_log" 2>/dev/null || echo "0")
    if [ "$log_size" -gt 52428800 ]; then
        gzip -c "$debug_log" > "$LOG_DIR/${site_name}-$(date +%Y%m%d).log.gz"
        > "$debug_log"
    fi
done

echo "[$TIMESTAMP] Check completato" >> "$LOG_DIR/monitor.log"

Metti questo script in crontab su ogni server. Per un check ogni 15 minuti:

*/15 * * * * /usr/local/bin/wp-log-monitor.sh

Quando un sito genera un fatal error, entro 15 minuti ricevi un messaggio Discord con il nome del sito e il numero di errori. Apri il debug.log, leggi lo stack trace, risolvi. Il cliente non sa ancora nulla.

Alternativa PHP: WP_CLI per log checking

Se hai WP-CLI installato (dovresti, su ogni sito di agenzia), puoi usare un comando personalizzato per controllare i log:

wp cli check-log --path=/var/www/sito-cliente \
  --pattern="Fatal error" \
  --lines=10 \
  --format=json

Questo comando restituisce gli ultimi 10 fatal error in formato JSON, perfetto per piping verso un sistema di alerting o un dashboard.

WordPress Health Check: monitoring integrato

WordPress include dalla versione 5.2 uno strumento di Site Health Check accessibile da Strumenti > Salute del sito. Non sostituisce un log monitoring completo, ma dà un’overview rapida di:

• Versione PHP e versioni obsolete
• Plugin disattivati per errori fatali
• Loopback requests fallite (comune su hosting economici)
• Stato delle scheduled task (WP-Cron)
• HTTPS attivo e certificato valido

Per il monitoraggio agenzie, il Site Health è un buon punto di partenza ma non sufficiente. Non invia alert e non logga errori ricorrenti. Usalo come check rapido, ma configura il logging strutturato come descritto sopra.

Strumenti esterni per il WordPress log monitoring

Per agenzie che vogliono andare oltre lo script bash, ci sono tre categorie di strumenti:

1. Servizi di error tracking (Sentry, Bugsnag)

Sentry ha un SDK PHP gratuito fino a 5.000 errori/mese. Integri il composer install nel tuo tema o plugin:

composer require sentry/sentry-laravel
// oppure per WordPress:
composer require sentry/sdk

E inizializza in functions.php:

Sentry\init([
    'dsn' => 'https://your-dsn@sentry.io/project',
    'environment' => 'production',
    'release' => '1.0.0',
]);

Sentry cattura ogni fatal error, exception e warning, con stack trace, contesto della richiesta, user info e release tracking. Il piano gratuito basta per 5-10 siti di agenzia.

2. Monitoring server (Datadog, New Relic)

Per agenzie con server dedicati o VPS, Datadog e New Relic offrono APM (Application Performance Monitoring) che traccia ogni request PHP. Costano (a partire da circa $15/mese per New Relic APM), ma per agenzie con clienti enterprise sono un investimento che il cliente può pagare come extra del contratto di manutenzione.

3. Uptime monitoring con alerting (UptimeRobot, Pingdom)

Questi non fanno log monitoring vero e proprio, ma rilevano quando un sito va down (errore 500, timeout, DNS). UptimeRobot è gratuito per 50 monitor con check ogni 5 minuti. Per un’agenzia con 30 siti, basta il piano free.

Configura UptimeRobot per alert via email, Discord, Slack o Telegram. Quando un sito va giù, lo sai entro 5 minuti anche se è domenica mattina.

Tabella riassuntiva: cosa configurare e dove

FAQ — WordPress Log Monitoring

Dove si trova il file di log di WordPress?

Il file di log di WordPress si trova in wp-content/debug.log. Viene creato automaticamente quando attivi WP_DEBUG_LOG in wp-config.php e si verifica il primo errore. Se il file non esiste, verifica che la directory wp-content/ sia scrivibile dall’utente del web server.

Posso lasciare WP_DEBUG attivo in produzione?

Sì, ma solo con WP_DEBUG_DISPLAY impostato a false. Questo logga gli errori su file senza mostrarli agli utenti. Mantieni WP_DEBUG attivo per rilevare warning e notice che potrebbero diventare fatal error futuri. Disattiva WP_DEBUG_DISPLAY sempre in produzione per evitare information leakage.

Come ricevo alert automatici quando un sito WordPress genera un errore?

Le opzioni sono tre: 1) Script bash in crontab che analizza debug.log e invia webhook Discord/Slack; 2) Sentry SDK integrato nel tema che cattura ogni exception e invia al dashboard; 3) Plugin premium come WP Health o ManageWP che monitorano errori da un dashboard centralizzato.

Query Monitor rallenta il sito in produzione?

Query Monitor aggiunge un overhead minimo (meno del 5% sulle richieste autenticate). Su un sito con page cache attiva, l’overhead è zero per gli utenti anonimi perché le pagine cached non passano da PHP. Disattivalo solo se hai un sito ad alto traffico senza page cache.

Qual è la differenza tra debug.log di WordPress e error.log di PHP?

Il debug.log di WordPress logga errori a livello applicazione (notice, warning, deprecated functions, fatal error gestiti da WordPress). L’error.log di PHP (su Nginx/Apache) logga errori a livello server, inclusi errori fatali che killano il processo PHP prima che WordPress possa intercettarli. Per un monitoring completo, controlla entrambi.

Checklist: configurare il WordPress log monitoring in 10 minuti

1. Apri wp-config.php e attiva WP_DEBUG, WP_DEBUG_LOG, disattiva WP_DEBUG_DISPLAY
2. Verifica che wp-content/debug.log venga creato dopo il primo errore
3. Installa Query Monitor dal repository gratuito di WordPress
4. Configura l’accesso a Query Monitor solo per il tuo team
5. Controlla il log di errore del web server (/var/log/nginx/error.log o Apache equivalent)
6. Per multi-sito: configura un path personalizzato per WP_DEBUG_LOG su ogni installazione
7. Installa lo script bash wp-log-monitor.sh in crontab per alert Discord
8. Configura UptimeRobot per ogni sito (check ogni 5 minuti, alert via email/Discord)
9. Per clienti enterprise: integra Sentry SDK per error tracking avanzato
10. Verifica una volta alla settimana il file debug.log di ogni sito per errori ricorrenti

Con questa configurazione, un’agenzia passa da reattiva a proattiva. I problemi vengono rilevati e risolti prima che diventino emergenze. Per approfondire come automatizzare la gestione multi-sito, leggi la nostra guida all’automazione WordPress per agenzie. Per la sicurezza dei tuoi siti, consulta la guida alla sicurezza WordPress. Per monitorare le performance, vedi la guida su Core Web Vitals su WordPress.

E se vuoi un sistema che centralizza gestione, aggiornamenti e monitoring di tutti i tuoi siti WordPress in un unico pannello, confronta AgencyPilot con ManageWP e MainWP per vedere perché abbiamo costruito il tool che avremmo voluto avere noi stessi.