Errori WordPress Comuni: Guida Troubleshooting Sistematica
Gli errori WordPress comuni capitano prima o poi a chiunque gestisca un sito: la schermata bianca che non dice nulla, l'error establishing a database connection che blocca tutto, il loop di login che non ti fa entrare nell'admin. Il problema non è l'errore in sé — è non sapere da dove cominciare. La maggior parte delle guide elenca 50, 70 errori diversi senza darti un metodo, e finisci per copiare soluzioni a caso rischiando di peggiorare la situazione.
Questa guida funziona diversamente: prima un framework diagnostico per isolare qualsiasi problema, poi le soluzioni ai 9 errori più frequenti (con percorso logico per ciascuno), poi una quick reference per i casi minori. Alla fine non avrai solo risolto l'errore di oggi — avrai imparato come affrontare qualsiasi problema WordPress futuro.
Come Affrontare un Errore WordPress con Metodo
Prima di toccare qualsiasi file, serve un approccio. Chi si lancia direttamente sulla soluzione trovata online spesso peggiora la situazione o perde tempo su sintomi invece che sulla causa. Il troubleshooting efficace segue un ordine preciso.
Primo passo: backup prima di qualsiasi intervento
Qualunque cosa tu stia per fare — rinominare una cartella, modificare wp-config.php, sostituire un file — fai prima un backup. Anche parziale. Anche solo della cartella che stai per toccare.
Non serve un sistema di backup elaborato: copia i file via FTP su un disco locale, oppure usa il file manager del tuo hosting. Il punto è avere un punto di ripristino nel caso qualcosa vada storto durante l'intervento. Un errore WordPress è recuperabile; perdere dati per un intervento improvvisato non sempre lo è.
Isola il problema: plugin, tema o core?
Il 90% degli errori WordPress ha una causa in uno di questi tre posti: un plugin, il tema attivo, o i file core. Isolare quale dei tre significa non dover indovinare.
La logica per isolare è questa: disattiva a metà, non tutto insieme. Se disattivi tutti i plugin contemporaneamente e il sito si riprende, sai che il colpevole è un plugin — ma non sai quale. Se ne disattivi metà e l'errore persiste, il problema è nell'altra metà. Procedi per divisione binaria finché non trovi il responsabile.
Per temi e plugin non accessibili dall'admin (il caso più comune quando c'è un errore grave), la disattivazione avviene via FTP o file manager — lo vedremo nella sezione dedicata.
Abilitare il debug mode per leggere gli errori reali
La schermata bianca o l'errore generico che vedi nel browser nasconde un messaggio PHP molto più preciso. Per leggerlo, aggiungi queste tre righe in wp-config.php prima della riga "That's all, stop editing!":
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);Con questa configurazione, WordPress non mostra gli errori a schermo (cosa che espone informazioni sensibili ai visitatori), ma li scrive nel file wp-content/debug.log. Leggi quel file via FTP per capire esattamente cosa sta andando storto — nome del file, numero di riga, tipo di errore. Ricordati di disabilitare il debug mode una volta risolto il problema.
Schermata Bianca (WSOD): Cause e Soluzioni
La schermata bianca wordpress — White Screen of Death (WSOD) — è uno degli errori più comuni e più disorientanti: il sito restituisce una pagina completamente bianca, senza messaggi di errore. I dati del database sono quasi sempre al sicuro; il problema è nell'esecuzione del codice PHP.
Le cause più frequenti del White Screen of Death
Il WSOD ha tre cause principali, ordinate per frequenza: memoria PHP esaurita, conflitto con un plugin o il tema attivo, file corrotti (spesso il functions.php del tema o un file core).
Un quarto caso meno noto: un aggiornamento interrotto lascia un file .maintenance nella directory principale. WordPress entra in modalità manutenzione ma non ne esce, mostrando una schermata bianca o un messaggio generico. Controlla via FTP se esiste quel file ed eliminalo.
Aumentare il memory limit da wp-config.php
Se la causa è la memoria esaurita, la soluzione rapida è aggiungere questa riga in wp-config.php, prima di "That's all, stop editing!":
define('WP_MEMORY_LIMIT', '256M');Se il sito usa l'admin in modo intenso (editor di pagine pesante, importazioni), aggiungi anche:
define('WP_MAX_MEMORY_LIMIT', '512M');Nota importante: questi valori funzionano solo se il limite PHP del server è uguale o superiore. Se il tuo hosting impone un limite inferiore a livello php.ini, contatta il supporto dell'hosting o modifica direttamente il php.ini — lo vediamo nella sezione dedicata al Memory Limit.
Disattivare plugin o tema per isolare il conflitto
Se aumentare la memoria non risolve, procedi per eliminazione. Via FTP o file manager, accedi alla cartella wp-content/plugins e rinominala (es. plugins_off). Se il sito torna visibile, il problema è in un plugin: rinomina la cartella al nome originale e disattiva i plugin uno alla volta finché riproduce l'errore.
Per il tema: accedi a wp-content/themes e rinomina la cartella del tema attivo. WordPress torna automaticamente al tema predefinito. Se l'errore scompare, il problema è nel tema — controlla il functions.php per errori di sintassi recenti.
Errore 500 Internal Server Error: Diagnosi e Fix
L'errore 500 WordPress è un errore lato server: qualcosa impedisce al server di elaborare la richiesta, ma il server non sa (o non può) dirti cosa. A differenza del WSOD, qui hai almeno un codice di errore con cui lavorare.
Le cause più comuni, in ordine di probabilità: file .htaccess corrotto, limite memoria PHP superato, plugin o tema incompatibile, permessi file errati, timeout dello script PHP.
File .htaccess corrotto: come rigenerarlo
Il .htaccess è il file di configurazione Apache che gestisce i permalink, i redirect e molte regole di accesso. Un'istruzione sbagliata al suo interno causa immediatamente un errore 500.
Il test è semplice: accedi via FTP alla root del sito, rinomina il file .htaccess in .htaccess_backup e ricarica il sito. Se l'errore scompare, il problema era lì. Per rigenerare un .htaccess pulito: vai in WordPress su Impostazioni → Permalink e clicca "Salva modifiche" senza cambiare nulla. WordPress riscrive il file con le regole corrette.
Limite memoria PHP e permessi file errati
Se il .htaccess è integro, controlla la memoria PHP con lo stesso metodo descritto nella sezione WSOD (aggiungendo il limite in wp-config.php o php.ini). Il processo è identico.
Per i permessi file, i valori corretti per WordPress sono: 644 per i file, 755 per le cartelle, 600 o 644 per wp-config.php. Permessi troppo aperti (es. 777) o troppo restrittivi causano entrambi problemi. Puoi verificarli e correggerli dal file manager del tuo hosting o via FTP con un client come FileZilla.
Plugin o tema incompatibile come causa nascosta
Se memoria e .htaccess sono a posto, il sospettato più probabile diventa un plugin aggiornato di recente o il tema attivo. Segui lo stesso processo di isolamento: rinomina la cartella plugins, controlla se l'errore 500 scompare, poi procedi per esclusione.
Un segnale specifico: se l'errore 500 compare solo nell'area admin e non nel frontend (o viceversa), il problema è quasi certamente in un plugin che si carica solo in quella parte del sito.
Error Establishing a Database Connection: Cosa Fare
L'errore connessione database wordpress è tra i più allarmanti visivamente, ma ha quasi sempre una causa semplice: credenziali errate o server MySQL temporaneamente non raggiungibile.
Verificare le credenziali in wp-config.php
Il file wp-config.php contiene quattro valori critici per la connessione al database:
define('DB_NAME', 'nome_database');
define('DB_USER', 'utente_database');
define('DB_PASSWORD', 'password_database');
define('DB_HOST', 'localhost');Apri il file via FTP e confronta questi valori con quelli presenti nel pannello del tuo hosting (di solito in cPanel → MySQL Database). Un carattere sbagliato in DB_PASSWORD o un nome errato in DB_NAME causa esattamente questo errore. Il valore di DB_HOST è quasi sempre localhost, ma alcuni hosting cloud usano un indirizzo diverso — controlla la documentazione del tuo provider.
Controllare se MySQL è attivo sul server
Se le credenziali sono corrette, il problema potrebbe essere che il server MySQL è momentaneamente inattivo. Controlla lo stato dei servizi nel pannello del tuo hosting. Se il server è down, contatta il supporto: è un problema lato server che non puoi risolvere dalla tua parte.
Un test utile: crea un file PHP temporaneo nella root del sito con questo contenuto e aprilo dal browser per verificare se riesce a connettersi al database con le credenziali di wp-config.php. Se la connessione fallisce anche da quel file, il problema è definitivamente lato server o nelle credenziali.
Database corrotto: accedere al repair senza wp-admin
In rari casi, le tabelle del database si corrompono (dopo un crash del server, un aggiornamento interrotto o un problema di scrittura su disco). WordPress ha una funzione di repair integrata: aggiungi questa riga in wp-config.php temporaneamente:
define('WP_ALLOW_REPAIR', true);Poi accedi a https://tuosito.com/wp-admin/maint/repair.php. Questo avvia il repair delle tabelle senza bisogno di accedere all'admin. Rimuovi la riga da wp-config.php dopo aver completato il repair — quella URL non deve restare accessibile.
Il repair integrato di WordPress copre i casi base. Se il database è gravemente corrotto o hai perso tabelle, serve un intervento più approfondito tramite phpMyAdmin o un database administrator. Questo esula dallo scope di questa guida e viene trattato separatamente.
Memory Limit Exhausted: Come Aumentare la Memoria PHP
Il messaggio "Allowed memory size of X bytes exhausted" è un errore critico PHP: lo script ha superato il limite di memoria assegnato e WordPress si ferma. Di default, WordPress prova a lavorare con 40MB (64MB per WooCommerce), che spesso non basta per installazioni con molti plugin attivi.
Modificare wp-config.php per alzare il limite
Il metodo più diretto è aggiungere o modificare questa riga in wp-config.php:
define('WP_MEMORY_LIMIT', '256M');256MB è il valore consigliato per la maggior parte dei siti. Se usi WooCommerce o plugin pesanti di page builder, considera 512MB. Aggiungi anche WP_MAX_MEMORY_LIMIT per la memoria riservata alle operazioni admin:
define('WP_MAX_MEMORY_LIMIT', '512M');Alternativa: php.ini e .htaccess
Se wp-config.php non è sufficiente (il server sovrascrive il valore), hai due alternative. La prima è modificare il file php.ini nella root del sito (se il tuo hosting lo permette):
memory_limit = 256MLa seconda è aggiungere questa riga nel file .htaccess:
php_value memory_limit 256MNon tutti gli hosting supportano queste configurazioni da file (dipende dal tipo di server: Apache, Nginx, LiteSpeed). Se nessuno di questi metodi funziona, contatta il supporto del tuo hosting e chiedi esplicitamente di aumentare il PHP memory limit per il tuo account.
Quando il problema non è il limite ma un plugin con memory leak
Se hai già il limite a 256M o 512M e continui a ricevere l'errore, smettila di alzare il valore: probabilmente un plugin ha un memory leak. Sta consumando memoria in modo progressivo senza rilasciarla.
Come individuarlo: disattiva i plugin uno alla volta e monitora il consumo di memoria con uno strumento come Query Monitor (gratuito, dal repository WordPress.org). Query Monitor mostra quanta memoria usa ogni componente a ogni caricamento — il plugin problematico si rivela subito con valori fuori scala rispetto agli altri.
WordPress Login Loop: Perché Accade e Come Uscirne
Il login loop WordPress si manifesta così: inserisci username e password, la pagina sembra elaborare, ma invece di entrare nell'admin vieni reindirizzato di nuovo alla schermata di login — all'infinito. Non è un errore bloccante nel senso classico, ma ti taglia fuori dall'admin.
Cookie di sessione corrotti: come pulirli
Il caso più comune è semplice: i cookie di sessione del browser sono corrotti o scaduti. Prima di intervenire sui file del sito, prova questo: apri una finestra in modalità navigazione privata e ripeti il login. Se funziona, il problema erano i cookie del browser — svuota cache e cookie per il tuo dominio e il problema è risolto.
Se anche la navigazione privata non funziona, il problema è nel sito, non nel browser.
Reimpostare i salts di sicurezza in wp-config.php
WordPress usa una serie di "salts" crittografici in wp-config.php per rendere sicure le sessioni degli utenti. Se questi valori cambiano mentre sei loggato (ad esempio dopo un aggiornamento o una modifica al file), tutte le sessioni attive diventano invalide e il sito non riesce a riconoscere la nuova sessione che tenta di creare.
La soluzione: genera nuovi salts dal generatore ufficiale su api.wordpress.org/secret-key/1.1/salt/, apri wp-config.php via FTP, e sostituisci le otto righe che cominciano con define('AUTH_KEY'..., define('SECURE_AUTH_KEY'... e così via. Salva il file — tutti i login verranno invalidati e dovrai rientrare con le tue credenziali.
Problema con SSL e redirect loop sul login
Un caso specifico e comune con siti HTTPS: WordPress è configurato per usare HTTP per le pagine admin, ma il server forza HTTPS su tutto, o viceversa. Questo crea un conflitto che si manifesta proprio sulla pagina di login.
La correzione: aggiungi o controlla in wp-config.php questa riga:
define('FORCE_SSL_ADMIN', true);Verifica anche che i valori di siteurl e home nel database (tabella wp_options) usino entrambi https:// e non http://. Una discrepanza tra i due causa esattamente questo tipo di loop sul login.
Plugin o Tema Crashato: Disattivare Senza Accesso Admin
Hai installato o aggiornato un plugin, e ora il sito è irraggiungibile o l'admin non risponde. Accedere a /wp-admin non funziona. Come disattivi il plugin responsabile senza poter entrare nell'admin?
Via FTP: rinominare la cartella plugins
Il metodo più rapido per il conflitto plugin wordpress: connettiti al server via FTP, naviga in wp-content/plugins/ e rinomina l'intera cartella (es. plugins_disabled). WordPress non trova più i plugin e li considera tutti inattivi — se il sito si riprende, il colpevole è uno di loro.
Per trovare quale: rinomina la cartella al nome originale plugins, poi entra nella cartella e rinomina la cartella del singolo plugin sospettato (es. il più recentemente installato o aggiornato). Se il sito torna operativo, hai trovato il responsabile.
Lo stesso principio vale per il tema: naviga in wp-content/themes/ e rinomina la cartella del tema attivo. WordPress userà automaticamente un tema predefinito. Se il sito si riprende, il problema era nel tema.
Via file manager dell'hosting (alternativa al FTP)
Se non hai un client FTP configurato, il file manager integrato nel pannello del tuo hosting (cPanel, Plesk, DirectAdmin) fa esattamente la stessa cosa. Accedi al pannello, trova il file manager, naviga in public_html/wp-content/plugins/ (o il percorso del tuo sito) e rinomina la cartella del plugin problematico con il tasto destro.
Questa alternativa è particolarmente utile per chi gestisce siti di clienti da remoto senza accesso FTP diretto.
Via phpMyAdmin: disattivare singolo plugin dalla tabella wp_options
Il terzo metodo, più preciso, funziona quando sai già quale plugin è il responsabile e vuoi disattivarlo senza toccare gli altri. Accedi a phpMyAdmin dal pannello del tuo hosting, seleziona il database WordPress, apri la tabella wp_options e cerca la riga con option_name = 'active_plugins'.
Il campo option_value contiene un array PHP serializzato con l'elenco dei plugin attivi. Modifica il valore e rimuovi la voce del plugin che vuoi disattivare — la stringa deve rimanere un PHP serializzato valido, quindi fai attenzione ai conteggi dei caratteri. Se non sei sicuro, usa il metodo FTP che è più sicuro.
File WordPress Corrotti: Come Sostituirli via FTP
I file core di WordPress possono corrompersi per vari motivi: un aggiornamento andato storto a metà, un intervento manuale errato, un attacco che ha modificato file critici. Il segnale tipico è un errore che compare su tutto il sito, o comportamenti anomali in funzionalità base come l'upload dei media o il salvataggio dei post.
Identificare quali file sono stati corrotti
Prima di sostituire file a caso, identifica cosa è effettivamente corrotto. Se hai abilitato il debug log (come descritto nella prima sezione), trovi lì il percorso esatto del file problematico. In alternativa, confronta il timestamp di modifica dei file sul server con la data dell'ultimo aggiornamento WordPress — file modificati in modo anomalo dopo quella data sono sospetti.
Per una verifica più sistematica, il plugin Wordfence Security include una funzione di scansione integrità file che confronta ogni file core con la versione originale sul repository WordPress.org e ti segnala qualsiasi differenza.
Scaricare WordPress pulito e sostituire i file core
Vai su wordpress.org/download e scarica la versione di WordPress che stai usando (deve corrispondere alla versione attuale del tuo sito — controlla in Dashboard → Aggiornamenti). Estrai lo zip sul tuo computer.
Via FTP, carica i file delle cartelle /wp-admin e /wp-includes sul server, sovrascrivendo i file esistenti. Non toccare la cartella /wp-content — contiene i tuoi tema, plugin e upload. Dei file nella root, carica solo quelli che sospetti siano corrotti (es. wp-login.php, wp-settings.php) — mai sovrascrivere wp-config.php che contiene le tue credenziali del database.
Quando la corruzione riguarda temi o plugin di terze parti
Se i file corrotti sono in un tema o in un plugin (non nei file core), il processo è analogo: scarica una copia pulita del tema o plugin dalla fonte originale (repository WordPress.org o sito dello sviluppatore), e sostituisci i file via FTP. Per i plugin premium, accedi al tuo account sul sito dello sviluppatore per scaricare l'ultima versione.
In caso di sospetta compromissione da malware (file modificati da un attaccante), la sostituzione dei file core da sola non è sufficiente: potrebbero esserci backdoor in wp-content. In quel caso, lo scenario richiede un'analisi più approfondita che va oltre la semplice sostituzione file.
Redirect Loop (ERR_TOO_MANY_REDIRECTS): Cause e Soluzione
Il browser mostra ERR_TOO_MANY_REDIRECTS: il sito rimanda a un URL che rimanda di nuovo al precedente, in un ciclo infinito. A differenza del login loop (che riguarda solo l'accesso admin), qui il sito è completamente irraggiungibile — né frontend né backend.
Configurazione URL WordPress errata in wp-config.php o database
La causa più frequente: i valori di siteurl e home non sono coerenti tra loro, o tra il database e il file wp-config.php. Puoi forzare questi valori direttamente in wp-config.php aggiungendo:
define('WP_HOME', 'https://tuosito.com');
define('WP_SITEURL', 'https://tuosito.com');Questi valori in wp-config.php sovrascrivono quelli del database. Se il loop scompare, aggiorna anche i valori nel database tramite phpMyAdmin (tabella wp_options, righe siteurl e home) e poi rimuovi le righe da wp-config.php.
Conflitto tra HTTPS e impostazioni WordPress
Caso molto comune con siti migrati da HTTP a HTTPS: WordPress è configurato con URL http:// nel database, ma il server forza tutto su https:// tramite regole nel .htaccess o configurazione Nginx. Il risultato è un redirect circolare tra le due versioni.
La soluzione completa richiede due passaggi: aggiornare siteurl e home in wp_options con URL https://, e verificare che il file .htaccess non contenga redirect da https verso http (o viceversa) che si annullano a vicenda. Se usi Cloudflare, controlla che la modalità SSL in Cloudflare sia impostata su "Full" o "Full (strict)" e non su "Flexible" — la modalità Flexible causa esattamente questo tipo di loop su siti con HTTPS già attivo.
Plugin di caching o SEO che genera redirect circolari
Plugin di caching, SEO e redirect manager possono aggiungere regole di reindirizzamento che entrano in conflitto con le impostazioni base di WordPress. Il debug: rinomina il .htaccess in .htaccess_backup e crea un nuovo file .htaccess con solo le regole base WordPress:
# BEGIN WordPress
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
# END WordPressSe il loop scompare, il problema era in una regola nel vecchio .htaccess. Vai poi in Impostazioni → Permalink e salva per rigenerare il file con le regole corrette dei plugin attivi.
Altri Errori Frequenti: Quick Reference
| Errore | Causa più comune | Soluzione rapida |
|---|---|---|
| 404 dopo cambio permalink | .htaccess non aggiornato |
Impostazioni → Permalink → Salva modifiche (senza cambiare nulla) |
| Errore critico PHP / Fatal error | Sintassi PHP errata in un file (plugin, tema, functions.php) |
Leggi il messaggio di errore (o il debug.log), identifica il file e la riga, correggi o disattiva il componente |
| Sito bloccato in modalità manutenzione | File .maintenance rimasto dopo aggiornamento interrotto |
Via FTP, elimina il file .maintenance dalla root del sito |
| Errore upload file troppo grande | Limite upload_max_filesize PHP troppo basso |
Modifica php.ini o .htaccess: php_value upload_max_filesize 64M e php_value post_max_size 64M |
| Errore durante upload immagini (HTTP error) | Permessi errati su wp-content/uploads/ |
Imposta permessi 755 sulla cartella wp-content/uploads/ via FTP o file manager |
| Mixed content / Warning HTTPS | URL immagini o script ancora in http:// dopo migrazione HTTPS |
Usa il plugin Better Search Replace per aggiornare tutti gli URL nel database da http a https |
| Errore di connessione SMTP / email non inviate | WordPress usa la funzione mail() di PHP disabilitata dall'hosting | Installa un plugin SMTP come WP Mail SMTP e configura un server mail dedicato |
Log degli Errori WordPress: Come Trovarli e Leggerli
I log degli errori sono lo strumento più utile per diagnosticare qualsiasi problema WordPress — eppure molti utenti non sanno dove trovarli. Capire come leggerli trasforma il troubleshooting da tentativi casuali a diagnosi precisa.
Abilitare WP_DEBUG_LOG e trovare il file debug.log
Come descritto nella sezione sulla metodologia, aggiungere le tre costanti WP_DEBUG, WP_DEBUG_LOG e WP_DEBUG_DISPLAY in wp-config.php fa sì che WordPress scriva tutti gli errori in wp-content/debug.log senza mostrarli a schermo. Il file viene creato automaticamente alla prima scrittura. Accedilo via FTP o file manager. Ogni riga del log segue questo formato:
[18-Feb-2026 10:23:45 UTC] PHP Fatal error: Call to undefined function xyz() in /var/www/html/wp-content/plugins/nome-plugin/nome-file.php on line 142Hai tutto ciò che ti serve: data e ora, tipo di errore (Fatal, Warning, Notice), la funzione o il file che ha causato il problema, e il numero di riga esatto. Con questa informazione, identificare il plugin responsabile richiede pochi secondi.
Ricorda di disabilitare il debug mode dopo la risoluzione — in produzione, WP_DEBUG deve essere false.
Log PHP del server: dove trovarli in cPanel e Plesk
Il debug.log di WordPress mostra gli errori PHP generati nell'esecuzione di WordPress. I log PHP del server sono complementari e mostrano errori più bassi (configurazione del server, errori a livello di modulo PHP) che WordPress non intercetta.
In cPanel: trovi i log PHP in Log di Errori o in File Manager → logs/. In alternativa, la cartella ~/logs/ nella home del tuo account contiene spesso i file error_log.
In Plesk: vai in Siti Web → tuosito.com → Log. Puoi filtrare per tipo (error, access) e scaricare i file.
Se non trovi i log, contatta il supporto del tuo hosting — sono sempre disponibili a livello server, ma l'accesso può essere limitato in base al tipo di piano.
Come interpretare i messaggi di errore più comuni
I tre tipi di errore PHP che incontri più spesso nei log WordPress:
Fatal error: errore bloccante che interrompe l'esecuzione. Il sito non si carica. Causa tipica: funzione non definita, classe non trovata, sintassi errata. Va risolto subito.
Warning: errore non bloccante che indica un problema ma non ferma l'esecuzione. Il sito funziona ma qualcosa non va come dovrebbe — spesso un plugin che usa una funzione deprecata. Va risolto ma non è urgente.
Notice: avviso informativo su pratiche di codice non ottimali. In produzione, le notice sono quasi sempre irrilevanti per il funzionamento del sito. Se ne hai molte, considera di aggiornarle, ma non rappresentano un problema immediato.
Quando Contattare il Supporto (e Come Farlo Bene)
Saper riconoscere quando un problema supera le proprie competenze — o quando i rischi di intervenire da soli sono troppo alti — è parte integrante del troubleshooting professionale. Non è una sconfitta: è la scelta giusta.
Segnali che indicano di contattare il supporto:
- Hai seguito tutti i passi pertinenti in questa guida e l'errore persiste
- Il sito mostra segnali di compromissione (file modificati senza motivo, redirect a siti esterni, contenuto spam non aggiunto da te)
- Hai perso accesso al database o i dati sembrano mancanti
- Il problema è chiaramente lato server (MySQL down, errori di configurazione server che non puoi modificare)
- L'errore compare dopo un'operazione che non puoi invertire (migrazione, cambio hosting, aggiornamento PHP)
Come prepararti prima di contattare il supporto — che sia l'hosting, l'autore di un plugin o un professionista — fa la differenza tra una risoluzione rapida e ore di scambi email inutili. Raccogli queste informazioni prima di scrivere:
- Versione WordPress in uso (Dashboard → Aggiornamenti)
- Versione PHP del server (Strumenti → Salute del sito → Info)
- Lista plugin attivi (nome e versione)
- Tema attivo e versione
- Messaggio di errore esatto (o screenshot)
- Contenuto rilevante del debug.log o dei log del server
- Cosa hai già provato (aiuta a non ripetere passaggi)
Un ticket di supporto con queste informazioni ottiene una risposta utile nella prima risposta, non dopo cinque scambi per raccogliere i dati che avresti potuto fornire subito.
Conclusione
La metodologia conta più di qualsiasi lista: backup prima di agire, isola il problema per divisione (plugin, tema, core), leggi i log per avere dati reali invece di ipotesi. I 9 errori trattati — WSOD, errore 500, database connection, memory limit, login loop, plugin crashato, file corrotti, redirect loop, e i casi nella quick reference — coprono la grande maggioranza dei problemi reali che un sito WordPress incontra.
Con questo framework, puoi affrontare anche errori non in questa lista: il processo diagnostico è lo stesso. E quando il problema supera quello che puoi gestire in autonomia, i log degli errori sono il punto di partenza per chiunque ti aiuterà a risolverlo. Per chi vuole invece agire in modo preventivo, impostare un sistema di monitoraggio WordPress — uptime, errori e performance in tempo reale — è il complemento naturale a questo framework di troubleshooting.