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
Isola la richiesta fallita
Confronta home, altra pagina, accesso e azione esatta: salvataggio, caricamento o invio. Prima di ripetere moduli o ordini verifica se sono già stati elaborati.
02
Leggi il log corretto
Il codice 500 non rivela la causa. Fornisci URL, orario, fuso e identificativo richiesta se presente. File PHP, memoria e direttive invalide indicano piste diverse. Se mancano voci, verifica log e servizi intermedi.
03
Controlla plugin, tema e PHP
Confronta l’inizio con aggiornamenti, codice e cambi PHP. Prova il componente sospetto su una copia. Aumentare memoria non spiega il consumo crescente; verifica causa e limiti.
04
Preserva le regole server
Una direttiva .htaccess errata può causare problemi Apache; Nginx puro non legge quel file. Sostituirlo alla cieca può eliminare protezioni e reindirizzamenti. Controlla la regola precisa con l’host.
05
Esamina permessi e risorse
Proprietari, permessi, spazio e gestione PHP devono adattarsi all’hosting. Impostare ovunque 777 non è una riparazione. Dopo la correzione ripeti la richiesta e verifica le altre funzioni.
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.