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
Separa sito pubblico, pannello e negozio
Confronta URL rappresentativi con dispositivo, accesso e condizioni equivalenti. Una cache pubblica veloce non descrive editor o carrello. Ripeti le misure e conserva una base iniziale.
02
Distingui risposta e visualizzazione
L’attesa del primo byte differisce da immagini tardive o script bloccanti. Esamina la cascata di rete e PageSpeed Insights. Distingui laboratorio e dati reali disponibili.
03
Adatta immagini e script
Controlla immagini iniziali, risoluzione, compressione e spazio riservato. Non ritardare l’immagine principale con lazy loading. Analizza script esterni; conserva solo miglioramenti dimostrati senza problemi funzionali.
04
Configura cache e funzioni
Verifica le cache esistenti prima di aggiungerne altre. Plugin simili complicano la diagnosi. Carrello, pagamento, account e contenuti personali richiedono eccezioni. Controlla sessioni, prezzi e moduli.
05
Esamina applicazione e hosting
Conta il lavoro del plugin, non solo il numero. Cerca query lente, collegamenti esterni e attività simultanee. Profila in staging; non cancellare tabelle né disattivare attività senza evidenze.
Core Web Vitals: obiettivi delle visite reali
LCP riguarda il contenuto visibile principale, INP la risposta alle interazioni e CLS gli spostamenti visivi. Gli obiettivi valgono al 75° percentile delle visite reali, separando mobile e desktop. Un test di laboratorio non sostituisce questi dati.
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.