Come ripulire un sito WordPress senza romperlo

Ripulire un sito WordPress non è una lista di cose da cancellare. È un ordine, e quasi tutti i danni che ho visto fare durante una pulizia vengono dall’aver fatto le cose giuste nella sequenza sbagliata: si comincia dalla libreria media perché è la voce più grossa, e ci si accorge tre settimane dopo che mancano le immagini in venti articoli.

Questa guida copre la pulizia straordinaria: il sito che si è appesantito in tre anni, quello ereditato da qualcun altro, quello che ha accumulato quattro page builder e nessuno ricorda più quale sia in uso. Per i controlli ricorrenti — cosa guardare ogni settimana, ogni mese, ogni trimestre — c’è la guida alla manutenzione WordPress: qui si parla dell’intervento una tantum, quello che si fa una volta e si spera di non dover rifare.

Prima di cancellare qualsiasi cosa

Sembra la premessa noiosa e invece è metà del lavoro, perché quasi niente di quello che stai per fare è annullabile dal pannello di WordPress. Non c’è un cestino per una tabella eliminata, e la libreria media non ha una cronologia.

Servono tre cose, in quest’ordine:

• Un backup completo e verificato, file e database, scaricato anche in locale. Non il backup automatico di ieri di cui ti fidi: uno che hai visto arrivare a destinazione, con una dimensione plausibile. Se non ne hai uno, il primo passo è impostare un backup automatico su storage esterno e lasciarlo girare almeno una volta.
• Un ambiente di staging, se il sito produce qualcosa. Non serve per tutta la pulizia, ma serve per i due passaggi che possono rompere il frontend: media e tabelle del database.
• Un blocco note. Sembra banale: non lo è. Ogni cosa che elimini va scritta, con la data. Quando fra due mesi qualcosa non funziona, la domanda sarà “cosa abbiamo tolto?”, e la risposta “non me lo ricordo” costa più di tutta la pulizia.

Una regola che vale per l’intera guida: non fare due categorie di pulizia nello stesso giorno. Se elimini plugin e media insieme e il sito si rompe, hai due sospetti e nessun modo rapido di distinguerli.

Fai l’inventario prima della pulizia

Il passaggio che quasi nessuno fa, ed è quello che decide se la pulizia sarà utile o solo faticosa. Prima di togliere, misura: quasi sempre scoprirai che la cosa che pensavi pesasse non pesa, e che il peso vero sta dove non stavi guardando.

Se hai accesso SSH, quattro comandi bastano. Il primo dice dove sta lo spazio:

du -sh wp-content/* | sort -h

Gli altri tre usano WP-CLI e fotografano cosa c’è installato e quanto pesa il database:

wp plugin list --fields=name,status,update,version
wp theme list --fields=name,status,version
wp db size --tables --human-readable --format=table

Senza SSH si arriva quasi allo stesso risultato dal pannello dell’hosting (uso disco per cartella, phpMyAdmin ordinato per dimensione della tabella) e da Plugin > Installati con il filtro Inattivi. Ci vuole qualche minuto in più e nient’altro.

Quello che cerchi in questa fase sono cinque numeri: quanto pesano uploads, plugins e themes; quante sono le tabelle più grandi del database e come si chiamano; quanti plugin risultano inattivi; quanti temi ci sono oltre a quello in uso; e se in wp-content ci sono cartelle che non c’entrano niente — le vecchie copie -old, le cartelle di un tema che non usi più, gli archivi di un backup fatto a mano nel 2023.

Scrivi i cinque numeri. Ti serviranno alla fine per sapere se la pulizia è servita a qualcosa, e per non raccontarti che è servita più di quanto è servita.

L’ordine giusto: dal reversibile all’irreversibile

Questa tabella è l’ossatura del resto della guida. Le sei fasi vanno affrontate in quest’ordine — non perché la prima liberi più spazio, ma perché se qualcosa va storto nelle prime tre torni indietro in cinque minuti, e nelle ultime tre no.

Se hai poco tempo, fai 1, 2 e 3 e fermati. Sono l’ottanta per cento del beneficio reale e quasi zero del rischio.

1. Plugin disattivati e temi inutilizzati

È il punto da cui si comincia perché è quello con il rapporto migliore fra beneficio e rischio: si reinstalla tutto in due minuti, e nel frattempo togli dal server codice che non stai aggiornando.

Disattivare non è disinstallare, ed è la confusione che rende questo passaggio più importante di quanto sembri: i file di un plugin disattivato restano sul disco e restano raggiungibili via HTTP. Se contengono una vulnerabilità, quella vulnerabilità è ancora lì — e nessuno la sta patchando, perché gli aggiornamenti di un plugin disattivato di solito non li applica nessuno. Il tema è ripreso nella checklist di sicurezza WordPress, dove è uno dei controlli ad alta priorità.

Come procedere. Disinstalla dal pannello (non cancellando la cartella via FTP: la disinstallazione dal pannello lascia eseguire la routine di rimozione del plugin, che spesso pulisce anche le sue opzioni). Uno alla volta, con un caricamento di pagina in mezzo. Sui temi, tieni sempre un tema di default come rete di sicurezza: serve il giorno in cui il tuo si rompe e devi capire se il problema è il tema o altro.

Il caso che merita attenzione è il plugin attivo che non ti serve più. Va tolto, ma prima va capito cosa portava con sé: un plugin di form si porta via i messaggi ricevuti, uno di SEO si porta via i meta title se non li hai migrati. Su come decidere cosa vale la pena tenere ho scritto i criteri nella guida alla sicurezza dei plugin WordPress.

2. Revisioni, transient e opzioni in autoload

Qui si entra nel database, ed è la fase che di solito produce il numero più vistoso: su un sito con qualche anno di vita, le revisioni dei post da sole possono valere più righe dei post stessi.

Le revisioni. WordPress salva una copia dell’articolo a ogni salvataggio, per sempre. Utile mentre scrivi, inutile su un pezzo pubblicato tre anni fa. Si cancellano le vecchie e si mette un limite in wp-config.php, così il problema non si ripresenta:

define( 'WP_POST_REVISIONS', 5 );

Cinque è un numero ragionevole per la maggior parte dei siti: tiene una cronologia utile senza accumulare all’infinito. Le altre costanti che si possono mettere in quel file sono nella documentazione ufficiale di wp-config.php.

I transient scaduti. Sono cache temporanee che WordPress salva in wp_options con una data di scadenza. In teoria si cancellano da sole; in pratica, se un plugin le crea e non le pulisce, restano lì per anni. Si eliminano senza pensarci: sono per definizione rigenerabili.

Le opzioni in autoload. Questa è la voce che quasi nessuna guida nomina ed è quella che ha l’effetto più diretto sulle prestazioni. Le opzioni con autoload = yes vengono caricate a ogni singola richiesta, anche quando non servono a niente. Un plugin disinstallato male può lasciare in autoload qualche megabyte di dati che il tuo sito continua a leggere a ogni caricamento di pagina, per sempre.

wp option list --autoload=on --format=table --fields=option_name,size_bytes \
  | sort -k2 -n -r | head -20

Guarda le prime righe: se riconosci il nome di un plugin che non hai più, quella è roba da togliere. Se non riconosci il nome, non toccarla — vedi il punto 5.

3. I file che non appartengono a WordPress

Questa è la fase che nessuno considera “pulizia” e che invece è la più importante dal punto di vista della sicurezza, perché quasi sempre in una webroot vissuta ci sono file che non dovrebbero essere raggiungibili dal web.

Cosa cercare, in ordine di gravità:

• Dump del database (.sql, .sql.gz) lasciati nella root dopo una migrazione. Sono il database del sito, scaricabile da chiunque ne indovini il nome — e i nomi sono sempre gli stessi.
• Archivi di backup (.zip, .tar.gz) nella webroot, per lo stesso motivo.
• Cartelle di staging o di vecchie versioni: /old/, /vecchio/, /sito2/, /test/. Contengono un’installazione WordPress ferma a due anni fa, cioè con tutte le vulnerabilità di due anni fa, sullo stesso server del sito vero.
• File di installazione di plugin o temi caricati via FTP e mai rimossi.
• Log cresciuti a dismisura: debug.log, log di plugin di sicurezza, log di errori PHP. Vanno svuotati, non cancellati — e se sono enormi, la domanda vera è cosa li stia riempiendo.

Come procedere in sicurezza: non cancellare, sposta. Sposta fuori dalla webroot (o in una cartella non raggiungibile via HTTP), verifica che il sito funzioni, aspetta qualche settimana, poi elimina. Un file spostato per errore si rimette dov’era; un file cancellato per errore no.

Se durante questo giro trovi file PHP che non riconosci dentro uploads, fermati: quello non è disordine, è quasi sempre il segno di una compromissione, e la procedura è un’altra. La checklist di sicurezza spiega come impedire che uploads esegua PHP, che è la contromisura da mettere comunque.

4. La libreria media: la fase in cui si rompono i siti

Se salti questa sezione e ricordi una cosa sola, che sia questa: i plugin che trovano i “media non utilizzati” sbagliano, e sbagliano in modo sistematico.

Non è un difetto di un prodotto specifico, è un limite del problema. Per sapere se un’immagine è usata bisognerebbe conoscere ogni posto in cui un’immagine può essere referenziata, e in un WordPress reale sono almeno sei: il contenuto del post, i campi personalizzati, il JSON di un page builder, le opzioni del tema, i CSS come immagine di sfondo, e i modelli delle email transazionali. Un plugin che guarda il contenuto dei post e i metadati standard è già più accurato della media, e continua a non vedere gli altri quattro.

Il risultato tipico è un elenco di “immagini inutilizzate” che contiene il logo, le immagini di sfondo delle sezioni e metà delle foto dei prodotti. Cancellate in blocco, il danno si vede solo quando qualcuno visita quelle pagine — cioè giorni dopo, quando ricollegare la causa all’effetto è già difficile.

Il metodo che funziona, ed è più lento di proposito:

• Fai generare l’elenco dei candidati da uno strumento, ma trattalo come un’ipotesi, non come un verdetto.
• Prendi i nomi dei file e cercali nel database, non solo nei post: wp db search "nomefile.jpg" cerca in tutte le tabelle, comprese quelle dei campi personalizzati e dei page builder.
• Sposta invece di cancellare. Rinomina la cartella, o spostane il contenuto in un archivio esterno, tenendo intatta la struttura per anno e mese.
• Lascia passare almeno un mese. Se il sito ha traffico stagionale, di più. Poi cancella davvero.

Una nota sulle miniature: gran parte del peso di uploads non sono le immagini che hai caricato, sono le copie che WordPress e il tema generano a ogni upload — spesso otto o dieci formati per immagine, molti dei quali nessun template usa. Si può intervenire, ma non cancellandole: vedi la sezione su cosa non toccare.

5. Le tabelle orfane del database

Un plugin disinstallato lascia quasi sempre le sue tabelle. Sono le righe più grosse che hai visto nell’inventario e sono spesso davvero inutili — ma “spesso” non è “sempre”, e qui non c’è cestino.

Prima di eliminare una tabella devi sapere di chi era. Tre modi, dal più rapido al più affidabile:

• Il prefisso dopo wp_ di solito è il nome del plugin (wp_yoast_…, wp_wc_…). Se corrisponde a un plugin che hai ancora, è viva, non si tocca.
• Cerca il nome della tabella nei file dei plugin attivi: grep -rl "nome_tabella" wp-content/plugins/. Nessun risultato è un buon segno, ma non una prova — alcuni plugin compongono i nomi a runtime.
• Guarda la data dell’ultima riga inserita. Una tabella il cui contenuto più recente è del 2022 non sta servendo a nessuno.

Come procedere: esporta la singola tabella prima di eliminarla, tienila da parte, e fallo su staging se hai staging. Se non riesci ad attribuire una tabella a nessun plugin e non ne capisci il contenuto, lasciala dov’è: dieci megabyte inerti non ti costano niente, una tabella eliminata che serviva a un plugin attivo ti costa un errore fatale.

6. I contenuti: quando cancellare è la scelta sbagliata

Arrivati qui la tentazione è di fare ordine anche nei contenuti: le vecchie news, le pagine di servizi che non offri più, le categorie con un post dentro. È il punto in cui una pulizia tecnica diventa una decisione SEO, e va trattata come tale.

La regola è semplice: non si cancella una pagina che riceve visite o link. Prima di eliminare qualsiasi contenuto, guarda in Search Console se ha impression e clic negli ultimi dodici mesi, e controlla se altre pagine del sito la linkano. Se la risposta è sì anche una sola volta, cancellare significa buttare via qualcosa che stavi già ricevendo gratis. Vale anche per le categorie, e lì l’effetto è più largo di quanto sembri: cosa succede davvero quando accorpi o elimini una categoria dipende dalla struttura dei permalink, e può cambiare l’indirizzo di tutti gli articoli che contiene. E dopo ogni cancellazione o accorpamento controlla i posti che elencano i contenuti: una mappa del sito generata dai contenuti si aggiorna da sola, una scritta a mano è il primo posto in cui restano i link morti.

Le alternative, in ordine di preferenza:

• Aggiornare, se la pagina risponde ancora a una domanda che qualcuno si fa.
• Consolidare in una pagina più completa e mettere un redirect 301 dalla vecchia alla nuova. È l’operazione che dà i risultati migliori, perché somma due segnali invece di dividerli.
• Redirect 301 verso la pagina più vicina per argomento — e solo verso quella: mandare tutto in homepage è la scorciatoia che trasforma una pagina utile in un vicolo cieco.
• Cancellare davvero, con 410 o 404, solo se la pagina non ha traffico, non ha link e non ha un equivalente. È il caso raro, non quello standard — ed è anche la posizione di Google, che nella sua guida ai core update scrive che eliminare contenuti è l’ultima risorsa. Le domande per capire quando una pagina non è più utile a nessuno sono le stesse che usa per valutarle.

Su categorie e tag vale un ragionamento parallelo: un archivio con un post dentro non aiuta nessuno, ma il suo URL può essere indicizzato. I criteri per decidere cosa tenere indicizzato e cosa no sono nella checklist SEO on-page per WordPress.

Un avvertimento che vale da solo il paragrafo: eliminare un utente non è un’operazione neutra. WordPress ti chiede se riassegnare i suoi contenuti a un altro account. Se scegli “elimina tutti i contenuti”, spariscono gli articoli, non solo l’utente — ed è un modo particolarmente silenzioso di perdere anni di lavoro.

Cosa non cancellare, anche se sembra inutile

Metà delle guide alla pulizia consiglia almeno una di queste cose. Nessuna va fatta.

• readme.html e license.txt. Il consiglio classico è eliminarli “perché rivelano la versione di WordPress”. Tornano a ogni aggiornamento del core, quindi è una pulizia che va rifatta per sempre; e la versione si deduce comunque da una decina di altri segnali. È sicurezza per oscurità, cioè la sensazione della sicurezza senza la sicurezza.
• Le miniature già generate. Cancellarle a mano rompe gli attributi srcset delle pagine esistenti, e il browser resta senza il formato che stava chiedendo. Se vuoi ridurre i formati, la sequenza è al contrario: prima smetti di generarli, poi rigeneri le miniature dei formati che restano.
• Le cartelle per anno e mese dentro uploads. Riorganizzarle sembra ordine e invece invalida ogni URL assoluto salvato nel database, che sono la maggior parte.
• Una tabella che non riconosci di un plugin che è attivo. Vedi sopra: nel dubbio resta.
• Il file .htaccess. Su nginx non fa niente ed è comprensibile volerlo togliere, ma se il sito è su Apache — o ci finirà dopo un trasloco — quel file contiene le regole dei permalink, e senza torna tutto 404. Se stai cambiando server, l’ordine giusto delle operazioni è in come migrare WordPress senza downtime.
• Il tema di default. Un solo tema inutilizzato va tenuto apposta: è quello su cui passi per capire se un problema viene dal tuo tema o da altro.

Dopo la pulizia: cosa verificare

Il giro di controllo dura dieci minuti e va fatto lo stesso giorno, non “quando capita”.

• La homepage, un articolo, una pagina di archivio e la pagina che converte: aperte in navigazione anonima, con le immagini che caricano.
• Il form di contatto, compilato davvero, con l’email che arriva in casella.
• Il log degli errori PHP: se dopo la pulizia compaiono warning nuovi, qualcosa cercava qualcosa che non c’è più.
• Una scansione esterna del sito alla ricerca di 404 e immagini mancanti. È l’unico controllo che vede le pagine che tu non apri mai.
• Se hai un e-commerce: un ordine di prova completo, dal carrello alla conferma.
• Svuota la cache prima di dare qualsiasi giudizio, altrimenti stai guardando copie di prima.

Ultimo passo, che chiude il cerchio: ora che il sito è pulito, aggiornalo. Un core e dei plugin aggiornati su un’installazione senza zavorra hanno molte meno probabilità di rompere qualcosa — la procedura è in aggiornamento WordPress: cosa fare prima e dopo.

Quanto spazio recuperi davvero (e perché conta poco)

Riprendi i cinque numeri dell’inventario e confrontali. Su un sito con qualche anno di vita, una pulizia fatta bene libera tipicamente qualche centinaio di megabyte, a volte qualche giga se la libreria media era fuori controllo.

Ed è qui che serve essere onesti: quel numero non è il motivo per cui hai fatto questo lavoro. Lo spazio disco costa poco, e liberarne due giga non velocizza un sito — la pagina che l’utente carica non diventa più leggera perché sul server ci sono meno file. Se il sito è lento, le cause sono altre, e sono sei, in un ordine preciso.

Quello che hai guadagnato davvero è di un altro tipo, e non si misura in megabyte:

• Superficie d’attacco più piccola. Ogni plugin e ogni file eseguibile in meno è codice che non può essere sfruttato e che non devi aggiornare.
• Meno lavoro ricorrente. Dodici plugin invece di ventotto significa un controllo settimanale che sta davvero in dieci minuti.
• Backup più rapidi e ripristini più veloci, che è la differenza fra tornare online in venti minuti o in sei ore.
• Un sito che sai spiegare. Se sai perché c’è ogni cosa che c’è, i problemi futuri li diagnostichi in un pomeriggio invece che in una settimana.

C’è però un effetto sulle prestazioni che è reale, ed è quello delle opzioni in autoload della fase 2: quelle vengono lette a ogni richiesta, quindi toglierle si sente sul tempo di generazione della pagina. È l’unica voce di questa guida che sposta un numero di performance.

Domande frequenti

Da qui in avanti

Se dovessi ridurre tutta la guida a una riga: sposta, aspetta, poi cancella. Vale per i file, per i media e per le tabelle, e trasforma quasi ogni errore di questa procedura da irreversibile a fastidioso.

La pulizia straordinaria però è una toppa: rimette in ordine quello che si è accumulato, non impedisce che si accumuli di nuovo. La differenza la fa la routine — poche cose, con una cadenza fissa, spiegate nella checklist di manutenzione WordPress. E se preferisci che di questo se ne occupi qualcun altro, con backup verificati e aggiornamenti testati, puoi vedere come lavoro nella pagina su aggiornamenti e manutenzione.