WordPress mostra “Errore nello stabilire una connessione al database”: cosa controllare

Raccogliere gli indizi prima di modificare il sito

Apri homepage, una pagina interna e accesso amministrativo. Segna quali indirizzi restituiscono l’errore e quali funzionano. Ripeti una volta da una sessione privata: una pagina conservata nella cache può apparire regolare mentre il sito non riesce più a leggere il database. Evita di interpretare una sola schermata come diagnosi completa.

Prepara una cronologia: ultimo accesso riuscito, prima segnalazione, eventuale migrazione, cambio password, aggiornamento o intervento dell’hosting. Salva il testo esatto del messaggio e l’orario con il fuso. Queste informazioni permettono al tecnico di cercare l’evento nei registri, anziché provare modifiche successive senza sapere quale abbia effetto.

Verificare il servizio con il fornitore di hosting

Chiedi se il servizio database è disponibile e se l’account ha raggiunto limiti di spazio o risorse. La documentazione WordPress sugli errori comuni indica tra le possibili cause anche problemi del server e quote del database. Se più siti sullo stesso ambiente hanno smesso di funzionare insieme, comunica questa coincidenza all’assistenza.

Un messaggio utile può essere: “Dalle 10:20 il dominio mostra questo errore sia sul sito sia in amministrazione; ieri funzionava e non risultano modifiche applicative”. Aggiungi l’identificativo del servizio e chiedi una verifica dei registri nell’intervallo interessato. Non inserire password in ticket pubblici o screenshot. Fatti indicare un canale riservato per gli eventuali accessi.

Controllare quale database sta cercando WordPress

Il file wp-config.php contiene i parametri di collegamento: nome del database, utente, password e host. Il manutentore deve confrontarli con quelli effettivi dell’ambiente, preservando una copia del file prima di correggerlo. L’host non è sempre localhost: va verificato con il fornitore.

Dopo un trasferimento può essere rimasto un riferimento al vecchio server; dopo un cambio password può essere stata aggiornata solo una delle due configurazioni. Controlla anche che si stia esaminando l’installazione attiva, non una copia dimenticata. Se il problema è iniziato dopo un intervento più ampio, consulta anche la guida agli errori dopo un aggiornamento WordPress.

Distinguere connessione, autorizzazioni e integrità dei dati

Una configurazione corretta non esclude un problema dei permessi dell’utente database o del collegamento tra server web e server dati. Chi interviene deve verificare queste ipotesi con gli strumenti dell’hosting. Installare un plugin nella speranza di riparare il collegamento non è un passaggio diagnostico utile.

La riparazione delle tabelle è un’altra operazione: va valutata quando emergono segnali concreti di danneggiamento, non dedotta dal solo messaggio iniziale. Prima serve una copia del database disponibile, anche se incompleta, e una valutazione del tecnico. Una procedura di riparazione lasciata pubblicamente accessibile o un file di prova contenente credenziali creano ulteriori problemi e vanno rimossi al termine dell’intervento.

Preservare ordini e richieste prima del ripristino

Prima di sostituire un database, stabilisci quanto è recente la copia disponibile e quali attività sono avvenute dopo. Un negozio può avere pagamenti ricevuti, ordini salvati parzialmente o messaggi arrivati a servizi esterni. Il ritorno alla copia del giorno precedente non riconcilia automaticamente queste operazioni.

Organizza quindi un elenco dei dati da verificare: ordini, prenotazioni, utenti, moduli e modifiche editoriali. Recupera le conferme attraverso i sistemi autorizzati e confrontale dopo il ripristino, senza ripetere addebiti o invii. La guida ai backup del sito spiega come controllare contenuto e recuperabilità delle copie. Se il database è integro, correggere il collegamento può evitare un ripristino non necessario.

Un esempio ipotetico: errore dopo una migrazione

Immaginiamo un piccolo catalogo WordPress trasferito a un nuovo hosting. Le immagini sono state copiate e il dominio punta al nuovo server, ma tutte le pagine dinamiche mostrano l’errore. Il tecnico verifica che il database esista, controlla l’utente associato e scopre che il file di configurazione contiene ancora il vecchio host.

In questo scenario corregge il parametro dopo aver conservato la configurazione iniziale, poi prova lettura e salvataggio dei contenuti. Non importa nuovamente una copia più vecchia del database. È un esempio di metodo, non la spiegazione universale dell’errore: se invece il servizio fosse indisponibile, lo stesso cambio non risolverebbe il guasto.

Confermare il recupero e documentare la causa

Quando il sito torna visibile, controlla un invio dal modulo, un accesso e un salvataggio amministrativo. Per un negozio concorda anche una prova del percorso di acquisto e verifica gli ordini dell’intervallo problematico. Fai controllare i registri per capire se gli errori si sono effettivamente fermati.

• Pagina pubblica e amministrazione accessibili.
• Lettura e scrittura dei dati funzionanti.
• Richieste e ordini recenti riconciliati.
• File temporanei e accessi di prova rimossi.
• Causa, modifica e nuova copia di sicurezza documentate.

Conserva un breve resoconto insieme al piano di manutenzione del sito. Serve a ridurre i tempi di diagnosi se l’anomalia ricompare.

Domande frequenti

Questo errore significa che il sito è stato cancellato?

No. Significa che WordPress non riesce a stabilire il collegamento necessario. L’esistenza e l’integrità dei dati devono essere controllate separatamente.

Basta reinstallare WordPress?

Una reinstallazione non corregge automaticamente credenziali, permessi o indisponibilità del database. Prima va individuata la causa, preservando file e dati.

Chi devo contattare per primo?

Coinvolgi hosting e manutentore con lo stesso riepilogo. Il primo controlla il servizio; il secondo collega la verifica alla configurazione e alle funzioni del sito.