Sito WordPress hackerato: cosa fare passo dopo passo

Un avviso rosso in Chrome, un reindirizzamento verso un dominio sconosciuto e un pannello di amministrazione in cui tutto sembra come sempre. La procedura d’emergenza per un sito WordPress: cosa non toccare nella prima ora, dove si nasconde davvero l’infezione e come liberarsi dell’avviso di Google.

Giovedì mattina La chiama un cliente e Le dice che al posto del Suo negozio Chrome gli mostra un avviso rosso a schermo intero; Lei apre il sito dal telefono e dopo un secondo e mezzo il browser La sbatte su un dominio che non ha mai visto, mentre sul computer dell’ufficio, dove il pannello di amministrazione è aperto da lunedì, tutto è identico a sempre. Ecco l’aspetto che ha quasi sempre un sito WordPress hackerato: non una home page devastata con la firma dell’aggressore, ma un sito che mostra una faccia al proprietario e un’altra al visitatore, ed è per questo che le prime ore se ne vanno a discutere se il problema esista davvero.

Le domande a cui qui si risponde arrivano quasi sempre in quest’ordine: che cosa si può e che cosa non si deve toccare nella prima ora, quando ancora non si sa quanto in profondità sia arrivato l’aggressore; in quali punti precisi di un’installazione WordPress il codice viene nascosto, perché senza saperlo ripulire significa tirare a indovinare; e come ottenere che Google tolga l’avviso senza rovinarsi il secondo tentativo. In mezzo resta ciò che i proprietari saltano più spesso: il cambio delle credenziali nel momento giusto e nell’ordine giusto.

Tutto quello che va fatto nelle prossime ore è qui e non servirà cercarlo altrove. Fuori dall’articolo resta soltanto ciò che serve dopo, quando il sito è di nuovo in piedi — la strategia di backup, l’hardening dei sistemi e la protezione contro la prossima volta, che è identica su qualsiasi piattaforma —, e per quello più avanti rimandiamo a una guida a parte. Qui si parla di ciò che rende WordPress diverso: l’ecosistema dei plugin, la cartella wp-content, le tabelle del database in cui l’infezione sopravvive alla pulizia dei file e i comandi che promettono più di quanto verifichino davvero. Nella nostra esperienza sono queste quattro cose a decidere se il sito è pulito dopo un giorno o al terzo tentativo.

La prima ora: non cancelli nulla

La prima reazione è quasi sempre una di due: aprire il gestore file dell’hosting, trovarci qualcosa di estraneo e cancellarlo, oppure premere il pulsante che ripristina il backup di ieri. Le chiediamo di non fare né l’una né l’altra cosa, e per una ragione pratica, non burocratica. La fretta si capisce, perché ogni ora con l’avviso rosso costa visitatori, ma è proprio nella fretta che si prendono le due decisioni capaci di allungare un ripristino da otto ore a una settimana, e sono entrambe irreversibili.

Quando i file infetti vengono cancellati sparisce anche l’unico materiale con cui più tardi si stabilisce il punto di ingresso: le date di modifica dei file, il contenuto degli script caricati dall’aggressore e le righe del log degli accessi del server che con quelle date coincidono. Senza punto di ingresso la pulizia è solo rimozione dei sintomi, e il prezzo è misurato: in uno studio di Google e dell’Università della California a Berkeley su 760.935 casi di violazione avvenuti tra luglio 2014 e giugno 2015, il 12% dei siti è stato violato di nuovo entro 30 giorni perché erano stati corretti i sintomi e non la causa (Li et al., WWW 2016).

Perciò il primo lavoro è una copia completa: tutti i file e l’intero database in un colpo solo, prima di toccare un singolo byte, perché il reindirizzamento visibile o la home page rovinata sono raramente tutto quello che sta succedendo sul sito. Secondo i dati di Sucuri, nel 2023 nel 49,21% dei siti infetti è stata trovata almeno una backdoor, e nel corso dell’anno il loro team ne ha rimosse 21.062 (Sucuri, «2023 Hacked Website & Malware Threat Report», giugno 2024). Conservi la copia fuori da quello stesso server, perché è lì che l’aggressore ha ancora accesso.

La telefonata successiva è al provider di hosting, e non per cortesia: sono loro ad avere i log degli accessi, che nel Suo pannello di solito si vedono solo per pochi giorni all’indietro, e su un server condiviso hanno il dovere di controllare se negli account vicini stia succedendo lo stesso. Se sul sito si accettano pagamenti o si inseriscono dati personali, in questo momento va spento oppure messo in modalità manutenzione: ogni visitatore che nella prossima ora digita i dati della carta è un problema a sé che ancora non ha. La modalità manutenzione costa una giornata di fatturato; il momento perso costa una lettera ai clienti.

Se wp-admin non si apre più — su un sito hackerato capita spesso —, la modalità manutenzione dal pannello non riuscirà ad attivarla, e restano due strade: aggiungere nel file .htaccess alla radice del sito una regola che mandi tutti, tranne il Suo indirizzo IP, su un’unica pagina statica con l’avviso di lavori tecnici, oppure chiedere all’hosting, nella stessa telefonata, di sospendere temporaneamente l’account. La seconda opzione sembra brutale, ma funziona anche quando ai file non arriva più.

Il backup di ieri sembra la via di ritorno più rapida e a volte è davvero il passo giusto, ma solo se si sa in che giorno l’aggressore è entrato. Nella nostra esperienza l’infezione viene notata molto più tardi di quando è cominciata — prima il codice sta zitto per un po’, poi comincia a mostrare pagine di spam o reindirizzamenti —, e questo significa che nel backup di ieri la backdoor con ogni probabilità è già dentro. Ripristinarlo nasconde i sintomi per un paio d’ore e riporta il sito esattamente nello stato in cui è stato violato, per questo il ripristino di un sito hackerato lo avviamo di solito nel giro di poche ore e anche di fretta partiamo dalla copia, non dalla cancellazione, perfino quando il cliente chiama e chiede semplicemente di ripulire tutto in fretta.

Come riconoscere un sito WordPress hackerato

Il reindirizzamento che scatta per il visitatore arrivato da un risultato di Google ma non quando l’indirizzo viene digitato nella barra del browser non è un equivoco: è una scelta deliberata dell’aggressore. Nelle norme antispam di Google i reindirizzamenti sono elencati come un tipo a sé di contenuto compromesso, in cui gli hacker inseriscono codice che «reindirizza alcuni utenti a pagine dannose o contenenti spam» (Google Search Central, consultato ad agosto 2026). La parola che inganna il proprietario è «alcuni». La verifica richiede un minuto: apra il sito in una finestra di navigazione in incognito, poi lo cerchi su Google e lo apra da lì, e ripeta entrambe le cose dal telefono.

Il secondo gruppo di segnali sta dal lato dell’amministrazione ed è molto più concreto: wp-admin restituisce all’improvviso un 404, il modulo di accesso dopo la password corretta si limita a ricaricarsi, nell’elenco utenti compare un account amministratore che nessuno del Suo team ha creato, oppure in Impostazioni → Generali l’indirizzo del sito non è più il Suo. Nel database quest’ultimo segnale sono soltanto due righe della tabella wp_options — siteurl e home —, ed è proprio per questo che l’indirizzo che Lei vede nelle impostazioni e quello su cui finisce il visitatore possono non coincidere.

Il terzo gruppo arriva da fuori ed è il più doloroso, perché sullo stato del Suo sito La informa qualcun altro: l’azienda di hosting sospende senza preavviso l’account da cui è partito dello spam, in Search Console compare una segnalazione di problema di sicurezza, oppure accanto al sito nei risultati di ricerca compare l’etichetta «Questo sito potrebbe essere compromesso», che Google mostra quando ritiene che un aggressore abbia modificato pagine esistenti o ne abbia aggiunte di nuove piene di spam (Guida di Ricerca Google, consultata ad agosto 2026). Quell’etichetta Google la mette da sé, non su segnalazione di qualcuno, e compare anche quando a Lei il sito sembra impeccabile.

I nomi qui non sono una questione accademica, perché è con quelli che cercherà la soluzione e valuterà se chi si offre di risolvere capisce il Suo caso: nella propria documentazione Google ne cita tre — il gibberish hack, il Japanese keyword hack e il cloaked keywords and links hack, in cui le pagine create dall’aggressore mostrano un contenuto al motore di ricerca e un altro al visitatore. Il «pharma hack», popolare nel settore, viene dall’azienda di sicurezza Sucuri (2020) e nella documentazione di Google non c’è. La verifica pratica però è la stessa per tutti e tre: digiti nel motore di ricerca una query site: con il Suo dominio e vedrà subito le pagine che nessuno nella Sua azienda ha scritto. Nella variante giapponese sono pagine generate automaticamente, con titoli in giapponese, dentro cartelle dal nome casuale e con il Suo dominio nell’indirizzo.

E adesso la parte sgradevole: una scansione pulita non dimostra che il sito sia pulito, perché lo scanner vede solo quello che il server gli mostra, mentre il codice dell’aggressore riconosce spesso sia gli scanner sia i motori di ricerca, e Google, nella sua guida sulle pagine di parole chiave mascherate, avverte che la violazione viene spesso nascosta proprio perché al proprietario sembri che il problema sia ormai passato. Se la scansione è pulita ma l’hosting si lamenta della posta in uscita, creda all’hosting. È il momento di un audit di sicurezza del sito web con controllo manuale di file e log, perché lo scanner risponde alla domanda se sul sito ci sia qualcosa dell’elenco dei campioni noti, non a quella se dentro il sito ci sia ancora qualcuno.

Dove sta davvero il rischio di WordPress

Nella nostra esperienza, quando la causa salta finalmente fuori, non è quasi mai il core di WordPress. Il rapporto Patchstack «State of WordPress Security in 2026» conta 11.334 vulnerabilità nuove scoperte nell’ecosistema WordPress nel 2025 — il 42% in più rispetto all’anno precedente —, e ciò che in questo momento Le interessa è come si distribuisce quel numero: il 91% riguardava i plugin, il 9% i temi, mentre nel core di WordPress in tutto l’anno ne sono state segnalate soltanto sei, per giunta tutte di priorità bassa. Quasi ogni vulnerabilità nuova, quindi, non sta nel WordPress che Lei ha installato a suo tempo, ma in quello che negli anni gli è stato aggiunto sopra.

Ogni plugin è una base di codice a sé, scritta da un autore a sé, con una disciplina di aggiornamento a sé — e piuttosto spesso già interrotta —, quindi un sito con quaranta plugin non è un sito con un problema di sicurezza, ma un sito con quaranta problemi di sicurezza indipendenti l’uno dall’altro. Nella nostra esperienza il sito di un’azienda tipica se la cava benissimo con dieci o quindici plugin, e il resto di solito è il residuo di incarichi dimenticati da tempo: una galleria che non si mostra più, un modulo sostituito da un altro, uno slider che il design attuale non usa. Quando prendiamo in carico la realizzazione e la manutenzione di un sito WordPress, ridurre il numero di plugin è il primo lavoro, non l’ultimo.

Ed ecco l’errore che si ripete più di ogni altro: il plugin che non serve viene disattivato invece che eliminato. Disattivare dice a WordPress di non caricarlo più, ma i file restano al loro posto sul server, una parte di essi è ancora raggiungibile direttamente via HTTP e allo script dell’aggressore basta conoscerne il percorso. Nel giugno 2021 Wordfence ha documentato una vulnerabilità zero-day sfruttata attivamente nel plugin Fancy Product Designer che, secondo il suo avviso, «in alcune configurazioni è sfruttabile anche se il plugin è stato disattivato», e ha consigliato non di disattivarlo, ma di disinstallarlo del tutto. Se un plugin non Le serve più, il suo posto non è nell’elenco dei plugin in grigio, ma fuori dal server.

Perché tutto questo accada in automatico e senza alcun motivo personale lo spiega la scala: secondo i dati di W3Techs del 5 agosto 2026, WordPress fa funzionare il 41,2% di tutti i siti web. In un ecosistema di quelle dimensioni ogni vulnerabilità di plugin resa pubblica è subito sfruttabile contro un numero enorme di siti costruiti allo stesso modo, quindi all’aggressore conviene automatizzare invece che scegliere il bersaglio: lo script guarda i numeri di versione, non i nomi delle aziende. Nessuno ha scelto proprio il Suo sito, ed è esattamente per questo che un piccolo sito vetrina senza dati dei clienti e senza pagamenti viene violato con la stessa tranquillità di un grande e-commerce.

Dove l’aggressore nasconde il codice in un’installazione WordPress

Il primo posto che apriamo è wp-content/uploads, una cartella in cui per definizione ci sono solo immagini, file PDF e video e in cui non dovrebbe mai eseguirsi alcun file PHP. Se lì, in mezzo alle foto dei prodotti del 2019, dorme un file con estensione .php, non ci è finito per caso: quasi sempre è un uploader con cui l’aggressore porta sul server i file successivi, oppure una webshell che permette di eseguire comandi a nome del Suo server. Che il problema sia reale e non teorico si vede già dal fatto che sia Sucuri sia Wordfence offrono un’impostazione di hardening apposita che con una regola in .htaccess disattiva il motore PHP proprio in quella cartella.

Il secondo posto è wp-content/mu-plugins. I plugin messi lì si attivano da soli, non è possibile disattivarli dal pannello di amministrazione e — cosa che qui conta più di tutto — non compaiono nell’elenco normale dei plugin, quindi il proprietario del sito può passare mesi a guardare un pannello apparentemente pulito; nel luglio 2025 Sucuri ha descritto esattamente un caso del genere, con una backdoor in quella cartella. Accanto a questo controlliamo sempre il .htaccess, sia nella radice sia nelle sottocartelle, perché il reindirizzamento che scatta solo per i visitatori arrivati dal motore di ricerca o solo sui dispositivi mobili è quasi sempre scritto lì — ed è la ragione per cui Lei il proprio sito lo vede perfettamente normale.

Il codice viene scritto anche nelle prime righe di file esistenti e del tutto legittimi, il più delle volte all’inizio di wp-config.php e nel functions.php del tema, e non ha quasi mai l’aria di codice malevolo: è un’unica riga lunga con una chiamata a base64_decode, gzinflate o eval, seguita da centinaia di righe vuote perché nell’editor sembri che il file sia finito. Per questo confrontare i file con un originale pulito vale più che leggerli a occhio: quella riga a occhio non la trova nessuno, perché nessuno scorre un file fino alla novecentesima riga.

E poi c’è il database, dove lo scanner dei file non guarda e dove i punti da controllare sono tre: le righe siteurl e home della tabella wp_options, che l’aggressore riscrive perché le risorse delle Sue pagine vengano caricate da un server estraneo; la tabella wp_users, in cui compare spesso un account amministratore dal nome credibile; e il contenuto degli articoli in wp_posts, dove link nascosti e iframe vengono incastrati in mezzo a vecchi articoli che nessuno apre più. Se i file vengono ripuliti ma l’iniezione resta nel database, l’infezione torna lo stesso giorno. La riga in sé non si esegue — a ogni caricamento la legge e la lancia un piccolo loader nel functions.php del tema o nella cartella mu-plugins —, ed è proprio questa coppia a rimettere a posto i file cancellati più in fretta di quanto Lei riesca a verificare il risultato. Per questo, nel ripristino di un sito hackerato, ripulire i file e il database per noi è un lavoro solo e non due.

Confrontare i file con originali verificati

Il primo strumento che prendiamo in mano, una volta messa al sicuro la copia completa di file e database, è wp core verify-checksums: confronta l’hash di ogni file con i checksum pubblicati da WordPress.org e mostra subito quali file sono stati modificati e quali nell’installazione non sono proprio previsti. Il problema comincia dove finisce la sua portata: il comando controlla solo wp-admin/, wp-includes/ e i file wp-* della radice, mentre l’intera cartella wp-content, quindi plugin, temi e caricamenti, il codice sorgente la salta di proposito (codice sorgente di checksum-command di WP-CLI, consultato il 5 agosto 2026). Un file della radice lo stesso codice lo esclude a parte — wp-config.php —, quindi il file nelle cui prime righe il codice viene scritto più spesso a questo controllo non è visibile. Un risultato pulito del comando non significa un sito pulito.

Per i plugin esiste un comando a parte, wp plugin verify-checksums, ma anche quello confronta i file solo con i checksum del repository di WordPress.org, quindi un plugin commerciale comprato dallo sviluppatore viene semplicemente saltato; per i temi un comando equivalente nella documentazione di WP-CLI non esiste affatto (documentazione di WP-CLI, consultata il 5 agosto 2026). Al controllo automatico non si sottopongono dunque né i temi né i plugin comprati fuori dal repository, e wp core verify-checksums lascia fuori tutto wp-content — cioè la parte di codice in cui sono nate tutte le 11.334 vulnerabilità contate da Patchstack nel 2025, tranne le sei del core. Nei siti che prendiamo in carico è spesso proprio il tema l’unica cosa che nessuno ha mai controllato.

Nella nostra esperienza i checksum sono perciò un punto di partenza, non un metodo: il core e i plugin non li curiamo, li sostituiamo, cioè scarichiamo le stesse versioni dalla fonte originale e riscriviamo le cartelle per intero, non un file alla volta. Della vecchia installazione teniamo wp-content/uploads, e anche quella solo dopo aver verificato che tra le immagini non ci siano file PHP — per la stessa ragione per cui in quella cartella vale la pena disattivare del tutto il motore PHP. Il tema lo ripristiniamo dal controllo di versione, se c’è; se non c’è, prendiamo la copia consegnata dallo sviluppatore e rimettiamo sopra le personalizzazioni una per una, di proposito, perché solo così più tardi si può dire quale riga del sito è nostra e quale no.

Trovare e cancellare la riga cattiva sembra più economico, ed è esattamente per questo l’errore più ripetuto: l’aggressore lascia raramente un solo ingresso, e una sola backdoor non notata rende inutile tutto il resto del lavoro. Il codice può essere spezzato su più file, nascosto dietro una chiamata a base64 o gzinflate, scritto nella tabella delle opzioni del database o infilato in quella stessa cartella mu-plugins che il pannello di amministrazione non mostra. La ricerca per pattern trova quello che Lei già conosce; la sostituzione completa La libera anche da quello che non conosce.

C’è anche del lavoro che in questa fase non facciamo: non ci fidiamo del plugin che promette di «curare» i file infetti con un pulsante, perché lavora con quello stesso elenco di campioni noti e per giunta nello stesso ambiente a cui l’aggressore ha ancora accesso. Non confrontiamo i file a mano nemmeno quando il sito è delle dimensioni di un normale sito vetrina o di un blog, perché un’installazione nuova con i contenuti trasferiti costa meno ore del confronto riga per riga di due directory, e il risultato è verificabile. Il confronto manuale accurato ha senso dove il tema o il plugin è unico e il controllo di versione non c’è; come trattare i backup perché quella scelta esista davvero l’abbiamo descritto nella guida generale al ripristino.

Chiavi, sessioni e password: che cosa fa davvero ciascuna cosa

Le chiavi di autenticazione e salt (security keys and salts) del file wp-config.php non cifrano nulla, per quanto lo sostenga quasi ogni guida: WordPress le usa come base della chiave con cui la funzione wp_generate_auth_cookie() firma con HMAC-SHA256 il cookie di autenticazione, ma il cookie in sé è testo in chiaro con nome utente, scadenza e token di sessione (WordPress Developer Resources, consultato il 5 agosto 2026). Perciò, cambiando quei valori, ogni firma emessa in precedenza diventa non verificabile e il server rifiuta qualsiasi cookie rilasciato fino a quel momento, anche se la sessione formalmente non è ancora scaduta.

La conseguenza pratica è esattamente quella che serve nel momento di una violazione: la documentazione ufficiale di WordPress descrive il cambio delle chiavi come il modo per buttare fuori chiunque possa essere ancora connesso (WordPress.org, «FAQ My site was hacked», aggiornato il 26 luglio 2026), quindi, se l’aggressore ha in mano una sessione valida, quella finisce nello stesso istante. Insieme alle sessioni decadono anche tutti i nonce emessi, perciò i moduli iniziati e gli ordini a metà strada si interrompono: il momento del cambio lo scegliamo di proposito, non a caso in mezzo alla giornata lavorativa.

Il cambio delle chiavi e dei salt non cambia nessuna password. Gli hash delle password WordPress li genera con bcrypt e con un salt casuale diverso per ogni password, che con le costanti di wp-config.php non c’entra nulla (funzione wp_hash_password(); bcrypt per impostazione predefinita da WordPress 6.8), quindi l’aggressore che conosce la password dell’amministratore o ha fatto in tempo a crearsi un account, dopo il cambio delle chiavi si limita a rientrare. Le password si cambiano a parte e tutte, anche quelle che in teoria non conosce nessuno, e nel frattempo va percorso l’elenco degli utenti alla ricerca di account che nessuno del Suo team ha creato.

Con WordPress l’elenco delle credenziali non finisce: nella stessa tornata si cambiano la password del pannello di controllo dell’hosting, le credenziali FTP e SFTP, la password dell’utente del database insieme alla riga corrispondente in wp-config.php, e le chiavi SSH, che non si cambiano come una password ma si rigenerano, cancellando la vecchia chiave pubblica dal file authorized_keys del server. Alla fine si rinnovano tutte le chiavi API salvate sul sito — gateway di pagamento, servizio di invio delle email, integrazioni di spedizione e contabilità —, perché sono quelle che restano intatte più a lungo: nella quotidianità non le vede nessuno su nessuno schermo.

Dia per scontato che l’aggressore abbia una copia completa del database, perché è il passo più economico di tutto l’attacco: tutto quello che c’era dentro — gli indirizzi email dei clienti, lo storico degli ordini, gli hash delle password e le chiavi scritte nelle impostazioni dei plugin — va considerato finito in mani altrui. Se una di quelle password è usata anche da qualche altra parte, anche quel posto è compromesso, e di solito è il momento in cui il discorso passa dal sito alle caselle di posta, al gestionale della contabilità e al conto dei pagamenti del negozio.

L’ordine conta quanto l’elenco: chiavi e password si cambiano dopo che le backdoor sono state tolte, perché altrimenti l’aggressore i valori nuovi li legge lì stesso in wp-config.php oppure intercetta semplicemente l’accesso successivo. È proprio questa sequenza — prima la copia completa, poi la causa, poi la pulizia e solo alla fine le credenziali — il punto in cui un ripristino avviato in proprio più spesso si ferma o si ingarbuglia, e per questo la fase ce la prendiamo noi e alla fine consegniamo un rapporto scritto su che cosa è stato cambiato, quando e perché.

Come far sparire l’avviso di Google e che cosa fare dopo

Il report «Problemi di sicurezza» di Google Search Console è l’unico posto in cui si vede che cosa esattamente Google ha trovato sul Suo sito: lì sono indicati il tipo di minaccia e un campione delle pagine colpite, e da quello dipende anche ciò che il visitatore vede in questo momento. Il tipo di minaccia non cambia quello che vede il visitatore: Chrome non differenzia più il titolo dell’avviso a seconda che siano stati trovati phishing, malware o software indesiderato, ma in tutti i casi mostra lo stesso avviso a schermo intero — in italiano «Sito pericoloso» —, che la persona sul sito semplicemente non ce la fa entrare, mentre l’etichetta «Questo sito potrebbe essere compromesso» già citata nei risultati di ricerca è solo una scritta accanto al link, che si può oltrepassare con un clic (pagina della Guida di Google Chrome sui siti pericolosi, consultata ad agosto 2026). I titoli più vecchi, diversi a seconda del tipo di minaccia — per esempio «Deceptive site ahead» —, Chrome non li usa più, anche se si trovano ancora in una parte della documentazione di Google. Il primo blocca, il secondo avverte, e questo cambia quanto tempo Lei ha davvero.

Prima di premere «Richiedi esame» bisogna assicurarsi che il sito sia davvero pulito, non solo che sembri pulito nel Suo browser. Google, nella sua guida sul cloaked keywords hack, avverte esplicitamente che gli aggressori cercano di dare l’impressione che la pagina sia già stata cancellata o già sistemata, perciò ogni ex pagina di spam va controllata con lo strumento di controllo URL, che mostra la vista di Googlebot e non la Sua. Il secondo passo, quello che si salta più spesso, è l’elenco dei proprietari: nel Japanese keyword hack l’aggressore si aggiunge come proprietario verificato di Search Console (documentazione di Google su web.dev) e, finché non viene tolto da quell’elenco, sullo stato del sito ne sa esattamente quanto Lei.

Il pulsante da cercare è «Richiedi esame» nel report sui problemi di sicurezza, non la «richiesta di riconsiderazione», che Google riserva alle azioni manuali; e nel testo della richiesta vale la pena scrivere tre cose: che cosa è stato trovato, da dove è entrato l’aggressore e che cosa concretamente è stato fatto per chiudere il varco. Una scadenza non la promettiamo, perché non la promette nemmeno Google: la sua pagina di documentazione sull’ingegneria sociale dice che «la verifica può richiedere diversi giorni», mentre la pagina di assistenza di Search Console sui problemi di sicurezza scrive «diversi giorni o settimane» (entrambe consultate ad agosto 2026). Se qualcuno Le nomina 24 o 72 ore precise, sta ripetendo un numero che in nessuna fonte di Google esiste.

La fretta in questo passaggio costa più dell’attesa. Nello stesso studio di Google e dell’Università della California a Berkeley l’80% dei proprietari ha ottenuto che il sito venisse dichiarato pulito già al primo tentativo, mentre al restante 20% sono serviti più tentativi, e il tempo mediano passato a pettinare il codice lasciato dall’aggressore è stato di una settimana intera. I dati sono del 2014-2015 e vanno letti così, ma l’aritmetica non è cambiata: una richiesta respinta significa che l’avviso resta per un altro ciclo, e la seconda volta Lei non è più uno che presenta la richiesta per la prima volta.

Quando l’avviso è stato tolto il lavoro non è ancora finito, perché nell’indice restano le pagine create dall’aggressore, e quelle non vanno reindirizzate alla home page: devono restituire un 404 o un 410 perché Google le tolga del tutto, mentre lo strumento di rimozione di Search Console si limita a nasconderle per un periodo. Le posizioni non tornano girando un interruttore: le pagine vanno reindicizzate, e questo avviene al ritmo di Google, non al Suo. Come usare in questa fase i file di log e i backup perché la prossima volta il punto di partenza sia migliore l’abbiamo descritto in una guida a parte sul ripristino dei siti hackerati.

Quando smettere di fare da soli e quanto costa

Una parte di quanto descritto qui un proprietario esperto la fa da sé, e lo diciamo senza giri di parole anche a chi ci telefona con Search Console aperta e il plugin colpevole già individuato. Se l’infezione è una home page rovinata, se nei file di log si vede quale plugin l’ha fatta entrare, se nell’elenco utenti non ci sono amministratori estranei e se esiste un backup di ieri che qualche volta ha davvero ripristinato in un ambiente di prova, allora otto ore pagate Le compreranno un sonno più tranquillo, non un risultato più rapido.

Ci sono quattro situazioni in cui consigliamo di fermarsi, e la prima è la reinfezione dopo la pulizia: se il sito viene violato una seconda volta non è una questione di sfortuna, ma la prova che il punto di ingresso è ancora aperto, e una terza pulizia nello stesso ambiente costerà esattamente quanto le prime due. La seconda è qualsiasi ombra di sospetto sui dati dei clienti o dei pagamenti, perché lì accanto al lavoro tecnico compaiono anche obblighi verso l’autorità di controllo e termini che la buona volontà non allunga. La terza è un sito con cui l’azienda guadagna tutti i giorni, e la quarta la semplice mancanza di tempo: ripulire non è intellettualmente difficile, ma è lungo, monotono e non perdona un solo file saltato.

Il nostro ripristino di siti web hackerati costa 90 € l’ora, IVA esclusa, con un minimo di otto ore di lavoro pagate in anticipo. Di solito cominciamo entro poche ore dalla richiesta, e l’intero processo dall’inizio alla consegna richiede in genere 8–72 ore; la differenza tra otto e settantadue ore sta quasi sempre in quanto in profondità l’aggressore ha fatto in tempo a sistemarsi e in quanto è vecchio l’ultimo backup pulito. Il minimo non è un numero di marketing: la copia completa, la ricerca della causa nei file di log, la pulizia e la verifica raramente stanno in meno tempo.

La procedura è la stessa descritta sopra, solo senza il Suo fine settimana di mezzo. Prima di toccare qualsiasi cosa facciamo una copia completa dei file e del database, perché l’incidente resti indagabile, e solo allora il sito viene isolato; dopodiché viene ripulito da malware e backdoor, il database viene controllato, credenziali e chiavi vengono cambiate, la causa dell’intrusione viene trovata e chiusa, la richiesta di esame viene inviata a Google e il monitoraggio viene configurato, e alla fine Lei riceve un rapporto scritto su quello che è successo e su quello che è stato cambiato. Se il sito in questo momento non funziona o non è sicuro di quello che vede, può richiedere un controllo urgente del sito e Le diremo se qui c’è davvero qualcosa per cui valga la pena pagare.

In molti casi però la risposta vera non è il ripristino, ma quello che viene dopo: se il sito ha accumulato venti plugin e per metà di essi nessuno ricorda più il motivo, allora il problema sta nella manutenzione, e si risolve con la realizzazione e manutenzione WordPress, non con un altro ciclo di pulizia fra sei mesi. L’ora più economica di tutta questa storia è quella spesa prima: cancellare da wp-content/plugins il plugin inutilizzato invece di disattivarlo, e un backup che qualcuno abbia davvero ripristinato una volta in un ambiente di prova, insieme costano meno di una sola nostra giornata di lavoro.