Manutenzione WordPress: checklist per frequenza e piano di manutenzione

La manutenzione di un sito WordPress viene quasi sempre raccontata come un rituale mensile: un giorno fisso, una lista di dieci voci, spunta e via. È una semplificazione comoda e sbagliata, e si vede il giorno in cui il sito si rompe — perché quasi tutto quello che rompe davvero un sito succede fra un controllo mensile e l’altro.

La manutenzione non ha una frequenza: ne ha quattro. Ci sono cose che devono girare da sole senza che tu le veda, cose da guardare ogni settimana in dieci minuti, cose da controllare una volta al mese con calma, e cose che si fanno tre o quattro volte l’anno e che quasi nessuno fa mai. Questa guida le mette in fila in quest’ordine, perché è l’ordine in cui contano.

Una precisazione dovuta: una versione precedente di questo articolo conteneva alcune indicazioni che oggi non darei, dalla deframmentazione del database a un link esterno che non ha mai funzionato. Le correzioni sono dichiarate nel punto in cui capitano, invece di essere sistemate in silenzio — se hai seguito la versione vecchia, hai diritto di sapere cosa è cambiato e perché.

Cosa succede a un sito che nessuno mantiene

Un sito abbandonato non smette di funzionare di colpo. Si degrada, e lo fa in modo silenzioso: è questa la parte che rende la manutenzione difficile da vendere a sé stessi. Il giorno in cui il problema diventa visibile, di solito, è già il giorno del danno.

La sicurezza è la voce con il peggior rapporto fra probabilità e conseguenza. Qui va detta una cosa che si legge spesso al contrario: WordPress è la piattaforma più colpita perché è la più diffusa, non perché sia la più fragile. E il punto di ingresso quasi mai è il core, che è mantenuto bene e aggiornato in fretta: sono i plugin e i temi, cioè codice di terze parti che hai installato tu e che aggiorni tu. Detto altrimenti, la superficie d’attacco del tuo sito è una tua decisione, non una proprietà di WordPress.

Le prestazioni si consumano per accumulo. Nessun singolo cambiamento rallenta un sito: lo rallentano venti cambiamenti da nulla in diciotto mesi. Un plugin in più, una libreria che carica un font, immagini caricate a piena risoluzione, una tabella che cresce. Un sito che partiva veloce e oggi non lo è più non ha un problema: ne ha una dozzina piccoli, ed è esattamente la situazione che un controllo mensile intercetta e un intervento straordinario no.

Su questo punto vale la pena correggere una frase che circola molto, e che c’era anche qui: i Core Web Vitals non sono «tra i fattori di ranking più importanti». Google li ha sempre descritti come un segnale di rifinitura, quello che separa due risultati altrimenti equivalenti. Restano una cosa da misurare — ma per l’utente che aspetta, non per un posto in classifica. E se stai ancora guardando il FID, stai guardando una metrica che non esiste più: da marzo 2024 è stata sostituita da INP, che misura la reattività dell’intera sessione e non solo del primo clic.

Il resto sono soldi. Un form di contatto che ha smesso di inviare email dopo un aggiornamento non produce un errore visibile: produce silenzio, e il silenzio somiglia moltissimo a «questo mese non ci ha scritto nessuno». È il guasto più costoso di tutti proprio perché non si annuncia.

Le quattro frequenze della manutenzione WordPress

Prima di entrare nel dettaglio, la mappa. Ogni riga di questa tabella corrisponde a una sezione della guida, e la logica che le tiene insieme è una sola: più una cosa è veloce a rompersi, meno deve dipendere da te che te ne ricordi.

Se hai poco tempo e devi scegliere da dove partire, parti dalla prima riga. È l’unica che continua a proteggerti anche nei mesi in cui non apri il pannello.

Sempre attivo: quello che non deve dipendere da te

Questa sezione si configura una volta e poi si verifica ogni tanto. Sono le quattro cose che devono continuare a funzionare anche il mese in cui sei in ferie, hai cambiato lavoro o ti sei semplicemente dimenticato del sito.

Backup automatici, esterni e verificati

Cosa si controlla. Che esista un backup recente di file e database, che sia fuori dal server che stai proteggendo, e che qualcuno se ne accorga se un giorno smette di partire.

Come si verifica. Apri lo storage di destinazione — non il pannello del plugin, lo storage — e guarda la data dell’ultimo file e la sua dimensione. Il pannello ti dice cosa il plugin crede di aver fatto; lo storage ti dice cosa è arrivato davvero. Un archivio di 12 KB dove ce ne aspettavi 400 è un backup fallito che si è dichiarato riuscito.

Come si corregge. Tre requisiti non negoziabili: destinazione esterna (S3, Backblaze, uno spazio che non sia lo stesso disco del sito), una retention che tenga più di una copia, e una notifica in caso di fallimento. Se il backup vive sullo stesso server del sito, in caso di compromissione o di guasto perdi le due cose insieme. La procedura completa con script, cron e ripristino è in come automatizzare il backup su S3 e ripristinarlo con WP-CLI.

Fatto quando hai visto l’ultimo archivio nello storage con la data di oggi o di ieri, e sai a quale indirizzo email arriverebbe l’avviso di errore.

Monitoraggio uptime e scadenza del certificato

Cosa si controlla. Che qualcuno ti avvisi quando il sito è irraggiungibile, e prima che scada il certificato TLS.

Come si verifica. Un servizio di monitoraggio esterno che interroga il sito ogni pochi minuti da fuori. Deve essere esterno per definizione: un controllo che gira sullo stesso server non può dirti che il server è giù.

Come si corregge. Configura almeno due controlli: uno sulla homepage e uno su una pagina che richiede PHP e database (una pagina di archivio, o il carrello se hai WooCommerce). Il primo intercetta il server giù, il secondo intercetta il caso più frequente e più insidioso — server su, PHP in errore, homepage servita dalla cache. Un sito può restare «online» per ore mentre in realtà sta mostrando solo pagine congelate.

Fatto quando hai ricevuto almeno un avviso di prova e sai dove arriva.

Aggiornamenti automatici: quali attivare e quali no

Cosa si controlla. Che gli aggiornamenti di sicurezza del core si applichino da soli, e che quelli rischiosi restino manuali.

Come si verifica. WordPress applica da solo le release minori (da 6.5.1 a 6.5.2) da oltre dieci anni, e dalla 5.5 può farlo anche per singoli plugin e temi. Attenzione a un dettaglio che cambia la risposta: sui siti installati da WordPress 5.6 in poi anche le major sono automatiche per impostazione predefinita, mentre sui siti più vecchi no — cosa si aggiorna da solo e cosa no dipende quindi da quando è nato il sito. In Bacheca > Aggiornamenti vedi lo stato per ciascuno; la documentazione ufficiale sugli aggiornamenti spiega come cambiare il comportamento predefinito.

Come si corregge. La regola che uso: automatico per le release minori del core, automatico per i plugin che non toccano né il frontend né i pagamenti, manuale per tutto il resto. Un aggiornamento automatico di un plugin di caching o di un page builder può cambiare l’aspetto del sito alle tre di notte senza che nessuno lo veda per giorni. La differenza fra release minori e major, e cosa fare prima e dopo, è il tema di aggiornamento WordPress: cosa fare prima e dopo.

Fatto quando sai elencare a memoria quali plugin si aggiornano da soli e perché proprio quelli.

Scansione di sicurezza e firewall

Cosa si controlla. Che ci sia una scansione periodica dell’integrità dei file e un filtro davanti al login.

Come si verifica. La scansione deve confrontare i file con le versioni ufficiali e segnalare le differenze. Un sito compromesso continua a funzionare benissimo: il codice iniettato serve a chi lo inietta, e rompere il sito sarebbe controproducente. L’unico modo per accorgersene prima che lo faccia Google è confrontare i file.

Come si corregge. Un plugin di sicurezza, uno solo — installarne tre non triplica la protezione, moltiplica i conflitti. La configurazione completa è nella checklist di sicurezza WordPress, e la protezione specifica degli accessi in come difendersi da DDoS e brute force.

Fatto quando l’ultima scansione risulta completata e senza differenze non spiegate.

Ogni settimana: dieci minuti, non di più

Il controllo settimanale esiste per una ragione precisa: ridurre la finestra fra il momento in cui qualcosa si rompe e il momento in cui te ne accorgi. Se lo fai in mezz’ora, lo salterai. Deve stare in dieci minuti, e per starci deve essere sempre lo stesso giro.

Aggiornamenti di plugin e temi

Cosa si controlla. Cosa è uscito questa settimana e cosa vale la pena installare adesso.

Come si verifica. Non tutti gli aggiornamenti sono uguali. Apri il changelog: se contiene una correzione di sicurezza, si applica oggi, anche se è venerdì. Se è una funzionalità nuova, può aspettare il momento buono. La distinzione fra i due casi è l’unica cosa che rende sostenibile un ciclo settimanale.

Come si corregge. Uno alla volta, con un caricamento di pagina in mezzo. Aggiornarne dodici insieme fa risparmiare due minuti e ti costa un’ora quando qualcosa si rompe, perché non sai quale dei dodici è stato. Su un sito con traffico vero, prima su staging. Se un plugin ti chiede attenzione a ogni singola release, la domanda giusta non è come aggiornarlo meglio: è se ti serve ancora — i criteri per deciderlo sono in sicurezza dei plugin WordPress.

Fatto quando la schermata degli aggiornamenti è vuota o contiene solo voci che hai deciso consapevolmente di rimandare.

Il log degli errori PHP

Cosa si controlla. Se il sito sta producendo errori che nessuno vede.

Come si verifica. Guarda il file di log degli errori (dal pannello dell’hosting o via SSH) e cerca cosa si ripete. Un warning che compare quattromila volte in una settimana non è un warning: è una funzionalità rotta che sta sopravvivendo per caso, e prima o poi smetterà di farlo. Per capire quale plugin lo genera, Query Monitor attribuisce ogni errore e ogni query lenta al componente che l’ha prodotta.

Nota, perché è un errore che ho fatto io. In una versione precedente di questa pagina il link a Query Monitor era scritto male e non portava da nessuna parte: l’indirizzo corretto è quello qui sopra, sul repository ufficiale. Nello stesso blog, l’articolo sul confronto fra plugin di caching lo linkava correttamente. Due pagine dello stesso sito, lo stesso strumento, un link buono e uno rotto — è il tipo di incoerenza che si trova solo mettendo in fila gli articoli invece di leggerli uno alla volta.

Come si corregge. Risali al plugin, aggiorna o sostituisci. Se il log non esiste, attivalo: WP_DEBUG_LOG a true e WP_DEBUG_DISPLAY a false, così gli errori finiscono nel file e non sotto gli occhi dei visitatori.

Fatto quando il log non contiene errori nuovi rispetto alla settimana scorsa.

I form e le funzionalità che portano contatti

Cosa si controlla. Che i moduli inviino, che le email arrivino, e che il checkout arrivi in fondo.

Come si verifica. Compilando il form come lo compilerebbe un visitatore, con un indirizzo vero, e controllando che il messaggio arrivi e non finisca nello spam. Il messaggio di conferma a schermo non prova niente: quello compare anche quando l’invio SMTP fallisce.

Come si corregge. Se le email non arrivano il problema è quasi sempre l’autenticazione del dominio mittente, non il plugin del form. Se il sito vende, il giro va allargato al carrello e a un ordine di prova: le pagine di checkout non sono cacheabili e si rompono in modi che il resto del sito non mostra — il tema è ripreso in integrare un plugin con WooCommerce. E se usi un servizio di newsletter, verifica il nome che compare in fattura prima di cercarlo: Sendinblue si chiama Brevo dal 2023, e nella versione precedente di questa guida era ancora citato con il vecchio nome.

Fatto quando hai ricevuto in casella la tua email di prova.

Commenti, spam e nuovi utenti

Cosa si controlla. La coda di moderazione e, soprattutto, l’elenco degli utenti registrati.

Come si verifica. Lo spam nei commenti è fastidio. Un utente nuovo che non hai creato tu è un’altra cosa: è il segnale più leggibile di una compromissione in corso, e costa cinque secondi guardarlo. Controlla anche che nessun account esistente abbia cambiato ruolo.

Come si corregge. Se trovi un amministratore che non riconosci, non limitarti a cancellarlo: qualcuno è entrato, e cancellare l’account non chiude la porta da cui è passato. Da lì si va alla procedura di bonifica, non alla manutenzione ordinaria.

Fatto quando ogni account con permessi di scrittura ha un nome e un cognome che sai associare a una persona.

Ogni mese: il controllo vero

Questa è la parte che nella versione precedente era l’intera guida, ed è ancora il cuore del lavoro. Richiede fra i quarantacinque e i novanta minuti e vale la pena farla con il sito aperto in una finestra e i dati in un’altra.

Prestazioni e Core Web Vitals

Cosa si controlla. Se il sito è più lento del mese scorso — non se è «veloce» in assoluto.

Come si verifica. Misura sempre le stesse tre pagine (homepage, un articolo, la pagina che converte) con PageSpeed Insights, e annota i numeri. Il punteggio di un mese isolato non dice quasi nulla; la serie storica dice tutto. Se hai già dati sul campo in Search Console, quelli valgono più di qualsiasi test di laboratorio, perché arrivano dai browser dei tuoi visitatori.

Come si corregge. Un peggioramento improvviso ha quasi sempre una causa singola e recente: un plugin installato, un’immagine caricata a piena risoluzione, un servizio esterno aggiunto. Le sei cause reali, in ordine di frequenza, sono in sito WordPress lento: cause e soluzioni; gli interventi su immagini e risorse statiche in lazy loading, caching e minificazione; e se il collo di bottiglia è nella latenza di rete, in HTTP/3.

Fatto quando hai tre numeri scritti da qualche parte accanto a quelli del mese scorso.

La cache serve ancora quello che credi

Cosa si controlla. Che la configurazione di caching che hai messo mesi fa sia ancora attiva e stia ancora facendo effetto.

Come si verifica. Carica una pagina in navigazione anonima e guarda gli header della risposta: devi vedere un hit. Poi ripeti forzando il bypass della cache. Se i due tempi sono identici, la cache non sta servendo niente — succede più spesso di quanto si creda, soprattutto dopo un aggiornamento del plugin che ha resettato una configurazione.

Come si corregge. C’è una trappola che vale la pena conoscere se sei su nginx: alcuni plugin di caching scrivono le proprie regole in un file che nginx non include. Il pannello dichiara la minificazione attiva, il file esiste, e non ha effetto su nulla. Su nginx le regole vanno nella configurazione del server, non in un file che il plugin deposita nella cartella del sito. È un caso in cui fidarsi del pannello significa credere per mesi di avere un’ottimizzazione che non c’è. Il confronto fra i due plugin più usati, con i test, è in W3 Total Cache vs WP Rocket.

Fatto quando hai visto con i tuoi occhi la differenza di tempo fra risposta cacheata e non cacheata.

Database: cosa pulire e cosa lasciare stare

Cosa si controlla. Le tabelle che crescono senza motivo e i residui dei plugin disinstallati.

Come si verifica. Ordina le tabelle per dimensione. Le sospette abituali sono tre: wp_options gonfiata da transient scaduti e da opzioni con autoload attivo che vengono caricate a ogni richiesta; wp_postmeta, che accumula metadati di plugin che non ci sono più; e le tabelle personalizzate lasciate indietro da plugin disinstallati.

Qui va corretto un consiglio che c’era in questa pagina. La versione precedente diceva di «ottimizzare le tabelle MySQL per ridurre la frammentazione». Era un residuo dell’epoca di MyISAM. Su InnoDB, che è il motore di qualunque installazione WordPress moderna, OPTIMIZE TABLE non deframmenta niente: ricostruisce l’intera tabella da capo, occupa il doppio dello spazio mentre lo fa e non produce un guadagno misurabile in un uso normale. Su una tabella grande, in produzione, è un’operazione che può fare più danni del problema che credeva di risolvere. Il vero peso non è la frammentazione: sono le righe che non servono più.

Come si corregge. Limita le revisioni dei post, cancella i transient scaduti, rimuovi i metadati orfani. Sempre con un backup fresco a portata di mano e mai su un sito che sta ricevendo traffico: una pulizia sbagliata del database non si annulla con un clic. Se il sito non è mai stato ripulito e non sai da dove cominciare, la procedura completa — con l’ordine giusto delle operazioni — è in come ripulire un sito WordPress senza romperlo.

Fatto quando conosci le tre tabelle più grandi del tuo database e sai perché sono così.

Link rotti, 404 e redirect

Cosa si controlla. I link interni che puntano a pagine che non esistono più e i 404 che stanno ricevendo traffico vero.

Come si verifica. Con una scansione esterna del sito, non con un plugin residente. Il plugin più consigliato per questo lavoro è storicamente anche uno dei più pesanti: controlla i link in background, a ciclo continuo, e su un hosting condiviso è una delle cause più comuni di rallentamenti che sembrano inspiegabili. Un crawler che gira sul tuo computer una volta al mese fa lo stesso lavoro senza costare niente al server.

Come si corregge. I link interni si sistemano modificando il link. I 404 con traffico si sistemano con un redirect 301 verso la pagina che oggi risponde a quella domanda — e solo verso quella: mandare tutti i 404 in homepage è la scorciatoia che trasforma un errore onesto in una pagina inutile per chi ci arriva. Nello stesso giro conviene guardare anche i link interni che ci sono, non solo quelli rotti: contare da quante pagine è collegato ogni articolo richiede dieci minuti e dice quali contenuti il sito sta lasciando indietro.

Fatto quando la scansione non restituisce link interni rotti e ogni 404 con visite ha una destinazione.

SEO tecnica e Search Console

Cosa si controlla. Che le pagine che vuoi indicizzate lo siano, e che quelle nuove ci arrivino.

Come si verifica. In Search Console, il rapporto sull’indicizzazione delle pagine. La domanda da farsi non è quante pagine sono indicizzate, ma quali no e perché. «Rilevata, non indicizzata» e «Scansionata, non indicizzata» hanno cause diverse, e nella grande maggioranza dei casi la causa è la stessa: nessuna pagina del sito linka quella pagina. Nello stesso giro vale la pena guardare, una volta a trimestre, cosa vedono i sistemi di AI del tuo sito: quali crawler stai lasciando entrare, e cosa dice di te il file llms.txt che il plugin SEO genera da solo.

Come si corregge. Con i link interni, prima che con qualunque altra cosa. È il controllo che dà il ritorno più alto per il tempo speso, ed è anche il più trascurato — te lo dice qualcuno che se n’è accorto facendo l’audit del proprio blog. Se le pagine senza link sono molte, prima di lavorarle una per una conviene dare a ogni pagina almeno un percorso con una sitemap HTML, e poi passare ai link nel testo. I quindici controlli on-page sono in checklist SEO on-page per WordPress, e la parte sui dati strutturati, che vanno rivalidati dopo ogni aggiornamento importante del tema, in Schema.org in WordPress.

Fatto quando sai dire, per ogni pagina non indicizzata, se è una scelta tua o un problema.

Media, utenti e ruoli

Cosa si controlla. Lo spazio occupato dalla libreria media e chi ha ancora le chiavi di casa.

Come si verifica. Per i media, la dimensione della cartella uploads confrontata con il mese scorso. Per gli utenti, l’elenco filtrato per ruolo: amministratori ed editor prima di tutti.

Come si corregge. Sui media, prudenza: gli strumenti che cercano i file «non utilizzati» sbagliano regolarmente, perché non vedono le immagini usate dentro shortcode, campi personalizzati o page builder. Cancellare in blocco ciò che uno di questi strumenti dichiara inutile è uno dei modi più efficienti per bucare mezzo sito. Sugli utenti nessuna prudenza: il collaboratore che ha finito il progetto sei mesi fa non deve avere ancora un accesso da amministratore.

Fatto quando ogni account con ruolo elevato corrisponde a qualcuno che sta lavorando al sito adesso.

Ogni trimestre: la manutenzione che quasi nessuno fa

Sono quattro operazioni che non hanno mai urgenza e che è per questo che vengono rimandate per anni. Sono anche quelle che, quando saltano, saltano tutte insieme.

La versione di PHP

Cosa si controlla. Che la versione di PHP su cui gira il sito riceva ancora patch di sicurezza.

Come si verifica. In Strumenti > Salute del sito > Informazioni trovi la versione in uso. Confrontala con l’elenco ufficiale delle versioni supportate, che è l’unico riferimento che non invecchia — per questo qui non trovi un numero: qualsiasi numero scrivessi oggi sarebbe sbagliato fra un anno.

Come si corregge. Si cambia dal pannello dell’hosting, ed è una delle poche operazioni in cui vale davvero la pena passare da staging: un plugin abbandonato che usa una funzione rimossa produce una schermata bianca, non un avviso. La regola pratica è l’ultima versione supportata dal tuo stack che riceve ancora patch, non il minimo indispensabile per far partire WordPress. Se il sito è su un ambiente che gestisci tu, il contesto è in installare e configurare WordPress su hosting o VPS.

Fatto quando la versione in uso compare fra quelle con supporto attivo.

La prova di ripristino

Cosa si controlla. Che dal backup si possa davvero tornare a un sito funzionante.

Come si verifica. Ripristinando. Non c’è un altro modo, e questo è il punto: un backup che non è mai stato ripristinato non è un backup, è un file di cui ti fidi. La prova si fa su un ambiente separato — locale o staging — con l’archivio più recente, cronometrando quanto ci vuole.

Come si corregge. Le sorprese tipiche sono tre: il dump del database si interrompe a metà, mancano i file caricati dopo una certa data, oppure il ripristino funziona ma nessuno sa quanto dura — e scoprire che servono sei ore mentre il sito è giù è un’informazione che arriva nel momento peggiore possibile. La procedura con WP-CLI è in backup su S3 e ripristino; se la prova ti serve per un cambio di server, l’ordine giusto delle operazioni è in migrare WordPress senza downtime.

Fatto quando sai in quanti minuti torni online, perché l’hai misurato.

Audit dei plugin installati

Cosa si controlla. Quanti plugin ci sono, quanti servono davvero e quali non vengono più mantenuti.

Come si verifica. Per ciascuno: data dell’ultimo aggiornamento, compatibilità dichiarata con la versione corrente di WordPress, e se esiste ancora sul repository. Un plugin fermo da due anni non è «stabile»: è abbandonato, e un plugin abbandonato con molte installazioni è esattamente il bersaglio che si compra per distribuire codice malevolo agli utenti che si fidano — è il meccanismo raccontato in supply chain attack su WordPress.

Come si corregge. Disinstallando. Il plugin più sicuro è quello che non hai. Attenzione a una differenza che costa: disattivare non è disinstallare — il codice di un plugin disattivato resta sul disco e resta raggiungibile. Se ne hai accumulati parecchi, conviene farlo dentro una pulizia ordinata invece che uno alla volta quando ci pensi.

Fatto quando ogni plugin attivo ha un motivo che sai spiegare in una frase.

Leggere i changelog delle release

Cosa si controlla. Cosa è cambiato in WordPress dall’ultima volta che ci hai guardato.

Come si verifica. Le major release escono tre volte l’anno circa, e ognuna cambia qualcosa che prima o poi ti riguarda: l’editor, le prestazioni, i formati immagine supportati, la gestione dei template. L’ultima è WordPress 7.1 di agosto 2026, e ho scritto cosa cambia davvero e se conviene aggiornare subito. Se hai saltato qualche giro, tutte le versioni di WordPress, release per release sono in una tabella sola, con la data e cosa è cambiato in ciascuna.

Come si corregge. Non c’è niente da correggere: è la voce di manutenzione che serve a non trovarsi indietro di tre anni tutti insieme. Il costo di leggere un changelog ogni trimestre è venti minuti; il costo di saltare nove release è un aggiornamento che non osi più fare.

Fatto quando sai quale versione stai usando e cosa introdurrà la prossima.

Una volta l’anno: scadenze e decisioni

Il controllo annuale non è tecnico, è di gestione. Serve a evitare le due categorie di problemi che nessun plugin può intercettare: le scadenze amministrative e le decisioni rimandate.

• Dominio e certificato. Verifica la data di scadenza del dominio e a quale indirizzo email arrivano gli avvisi del registrar. Un dominio scaduto perché la notifica andava a una casella dismessa è un incidente più comune di quanto sembri, e mette offline tutto — sito e posta insieme. Il rinnovo automatico va bene solo se la carta collegata è ancora valida.
• L’hosting è ancora la taglia giusta? Guarda un anno di dati: traffico, picchi, tempo di risposta. Un sito cresciuto ha bisogno di più macchina; un sito che non è cresciuto sta magari pagando per risorse che non usa. È l’unico momento dell’anno in cui questa domanda si può fare con dei numeri davanti.
• Accessibilità. Un controllo l’anno sui contrasti, sulla navigazione da tastiera e sull’ordine di lettura intercetta quasi tutto quello che si è rotto nel frattempo: accessibilità WordPress per il quadro d’insieme, accessibilità da tastiera per la parte che si rompe più spesso dopo un cambio di tema.
• Il tema è ancora sostenibile? Se ogni aggiornamento richiede di risistemare qualcosa a mano, il problema non è l’aggiornamento: è che le personalizzazioni non stanno in un child theme, o che il tema fa cose che dovrebbe fare un plugin.Vale la pena chiederselo una volta l’anno, non nel mezzo di un’emergenza.
• Un evento, quest’anno? È la decisione rimandata per definizione, perché non ha una scadenza che ti avvisa. I biglietti e i voli per WordCamp Europe si prenotano con mesi di anticipo, e le edizioni si annunciano con un anno di margine: se non entra nella pianificazione annuale, non entra da nessun’altra parte.

Cos’è un WordPress care plan (e quando conviene davvero)

Un care plan — in italiano, un piano di manutenzione — è un accordo ricorrente in cui qualcuno si prende la responsabilità di tutto quello che hai letto fin qui, con una cadenza definita e un rendiconto di cosa è stato fatto. Non è un abbonamento a un plugin e non è assistenza a chiamata: è la differenza fra pagare qualcuno perché il sito stia bene e pagarlo perché il sito è rotto.

La confusione più comune riguarda proprio questo. L’assistenza a consumo interviene dopo, e il conto arriva nel momento peggiore: quando il sito è giù, quando serve fare in fretta, e quando spesso il danno è già stato fatto — un backup che non c’era, un ripristino mai provato, un aggiornamento saltato per due anni. Un piano di manutenzione sposta lo stesso lavoro prima, dove costa meno.

Cosa deve contenere

Un piano che vale i suoi soldi copre almeno queste cose, ed è ragionevole chiedere che siano scritte:

• Backup esterni con retention dichiarata, e almeno una prova di ripristino all’anno — non «backup inclusi», ma dove finiscono, per quanto tempo restano e chi li ha ripristinati l’ultima volta.
• Aggiornamenti testati, con ambiente di staging per i major e un modo per tornare indietro.
• Monitoraggio uptime con avviso a una persona reale, e un tempo di risposta dichiarato.
• Controlli di sicurezza e una procedura scritta per il caso peggiore, decisa prima che serva.
• Un report che dica cosa è stato fatto. Senza report, un piano di manutenzione e un piano di manutenzione mai eseguito hanno lo stesso aspetto.
• Un limite chiaro fra ciò che è compreso e ciò che è lavoro a parte. Le nuove funzionalità non sono manutenzione, e un piano che promette «tutto» sta promettendo male.

Da cosa dipende il costo

Il prezzo non dipende dal numero di pagine, che è la variabile che quasi tutti citano per prima e che non c’entra quasi niente. Dipende da quattro cose: quanto costa un’ora di sito fermo (un sito vetrina e un e-commerce non sono lo stesso rischio), quanta roba personalizzata c’è (ogni plugin custom è codice che nessun altro aggiorna al posto tuo), chi controlla il server, e quanto in fretta serve una risposta quando qualcosa si rompe. Due siti identici a vedersi possono avere piani molto diversi solo per la quarta voce.

Farla in casa o affidarla

Farla in casa ha senso a due condizioni: che ci sia una persona con il tempo e le competenze, e che quella persona non sia l’unica a saperlo fare. La manutenzione interna fallisce quasi sempre allo stesso modo — non per incapacità, ma perché la persona che se ne occupava cambia ruolo e nessuno eredita il compito. Se il sito è uno strumento di lavoro, la domanda giusta non è «so farlo?», ma «cosa succede al sito nei tre mesi in cui non ci penso?».

Se preferisci che se ne occupi qualcun altro, è esattamente quello che faccio con i miei clienti: aggiornamenti testati, backup verificati, monitoraggio e interventi quando serve. I dettagli sono nella pagina del servizio di aggiornamenti e manutenzione WordPress.

Gli strumenti: pochi, e scelti con un criterio

Gli elenchi di strumenti invecchiano più in fretta delle procedure: i nomi cambiano, i prodotti vengono acquisiti, i piani gratuiti spariscono. Per questo qui trovi le categorie e cosa deve fare uno strumento per meritarsi un posto, non una classifica.

Una regola che vale più di qualsiasi elenco: ogni strumento che installi diventa a sua volta qualcosa da mantenere. Un plugin di sicurezza, uno di backup e uno di diagnostica sono giustificati. Il quarto va motivato.

La manutenzione WordPress in una tabella

Da stampare, o da copiare dove tieni le cose da fare.

Domande frequenti sulla manutenzione WordPress

Da qui in avanti

Se dovessi tenere una sola riga di questa guida, terrei la prima della tabella: quello che protegge il sito nei mesi in cui non ci pensi è solo ciò che gira senza di te. Backup esterni, monitoraggio e aggiornamenti minori automatici si configurano in un pomeriggio e continuano a lavorare da soli. Tutto il resto è disciplina, e la disciplina regge meglio se il giro settimanale sta davvero in dieci minuti.

Se il sito è uno strumento di lavoro e preferisci che di questo se ne occupi qualcun altro — con aggiornamenti testati, backup verificati e un report di cosa è stato fatto — puoi vedere come lavoro nella pagina su aggiornamenti e manutenzione, oppure scrivermi e raccontarmi com’è messo il tuo.