La guida riguarda siti WordPress con hosting autonomo. Le modifiche richiedono accessi adeguati e un ritorno sicuro allo stato precedente. Se non conosci file, database e hosting, coordina la diagnosi con il fornitore.
Registra le osservazioni
Annota URL, messaggio esatto, primo orario con fuso e ultima modifica. Confronta home, altra pagina e accesso. Registra i tentativi: una singola richiesta fallita non dimostra che tutto il sito sia offline.
Backup e ripristino precedente
Prima di intervenire conserva file e database, quando possibile, e i backup precedenti. Controlla date e recuperabilità. Una copia danneggiata o infetta può servire all’indagine: proteggila separatamente e non considerarla pulita.
Cambia un elemento per volta e ripeti la stessa richiesta. Preferisci staging per test estesi di plugin, temi e configurazione. Disattivare non significa cancellare: negozio, moduli e sicurezza possono risentirne. Documenta stato iniziale e ritorno.
Diagnosi mirata
01
Confronta browser e rete
Prova una finestra privata, altro dispositivo e altra connessione. Se fallisce una sola vista, verifica cache ed estensioni del browser. DNS, TLS e WordPress richiedono controlli distinti.
02
Riconosci il sintomo
HTTP 500 indica un errore di elaborazione sul server. 502, 503 e 504 possono coinvolgere servizi intermedi o risorse. Per errori database verifica disponibilità con l’host senza cambiare credenziali a intuito.
03
Esamina le ultime modifiche
La vicinanza temporale non è una prova. Se l’amministrazione funziona, prova il plugin sospetto in modo controllato. Evita altri aggiornamenti collettivi e usa una copia per i conflitti estesi.
04
Se non funziona neppure l’accesso
Cerca il link di recupero nell’email amministratore e spam. Recovery Mode sospende componenti per la tua sessione, senza riparazione pubblica automatica. Fatti assistere per interventi sui file senza accesso sicuro.
05
Verifica hosting e cache
Chiedi log PHP e server all’ora esatta e controlli di spazio, dominio, DNS e certificato. Svuotare cache può rimuovere una vecchia pagina d’errore, non riparare PHP o database.
Valuta il ripristino
Un backup non sostituisce l’analisi della causa. Verificalo prima isolatamente se possibile. Ripristinare può perdere ordini, richieste e contenuti recenti. Concorda l’ambito; dopo un attacco non reimportare file correnti senza controlli.
Verifica dopo la correzione
Controlla URL iniziale, home, altre pagine e accesso. Prova moduli e negozio in ambiente adeguato senza ordini reali involontari. Dopo la correzione svuota solo le cache interessate. Documenta causa e risultato.
Quando chiedere assistenza
Interrompi le modifiche se la causa resta incerta, manca un ritorno affidabile o sono coinvolte funzioni critiche. Indizi di malware richiedono verifica di sicurezza. Non pubblicare log completi, password, chiavi o link di recupero.
Concorda ambito e costi →Manutenzione dopo la riparazione
Core WordPress, plugin e temi vengono aggiornati ogni settimana, evitando che le attività quotidiane facciano rimandare gli aggiornamenti necessari. Mensili, giornalieri o orari: l’intervallo dipende dal piano. I backup sono conservati su server nell’UE.
Riparazioni e pulizia di siti già compromessi sono servizi separati. Le licenze a pagamento sono escluse.