Manutenzione WordPress: come teniamo in salute i siti dei nostri clienti

Questo articolo spiega come in PaperPlane gestiamo la manutenzione dei siti WordPress: il contratto annuale che tiene il sito sicuro, aggiornato e monitorato, e i pacchetti orari con cui i clienti possono evolvere il sito nel tempo. E perché la distinzione tra i due non è solo contrattuale, ma di metodo.

Quando un sito WordPress va online, la sensazione naturale è quella di aver concluso un lavoro. Si è investito tempo, si è approvato il design, si sono scritti i contenuti, si è fatto il lancio. Da quel momento il sito è lì, funziona, fa il suo mestiere.

Quello che non si vede, finché non si rompe qualcosa, è che un sito WordPress è un sistema vivo. WordPress rilascia aggiornamenti del core con cadenza regolare. I plugin si aggiornano, cambiano, a volte vengono abbandonati dai loro sviluppatori. I server evolvono: la versione di PHP supportata oggi potrebbe non essere la stessa tra dodici mesi. Le vulnerabilità vengono scoperte e pubblicate, e tra il momento in cui una falla viene resa nota e il momento in cui qualcuno la sfrutta passano ore, non settimane.

Un sito senza manutenzione non è fermo. Sta accumulando debito tecnico in silenzio.

Il contratto annuale: cosa include e come funziona

Il piano di manutenzione che proponiamo ai nostri clienti ha cadenza annuale e copre tutto quello che serve perché un sito WordPress rimanga stabile, sicuro e performante nel tempo: aggiornamenti di WordPress core, plugin e tema, backup periodici calibrati sull’intensità editoriale del sito, monitoraggio dell’uptime, scansioni malware settimanali, hardening della sicurezza e test periodici delle performance.

Non è un servizio che si attiva solo quando qualcosa si rompe. È una presenza costante e silenziosa: la maggior parte degli interventi avviene senza che il cliente se ne accorga, e questo è esattamente l’obiettivo. Il segnale che il lavoro sta funzionando non è una notifica di problema risolto: è l’assenza di problemi.

Il contratto si rinnova ogni anno. Le richieste di assistenza vanno indirizzate a un indirizzo email dedicato: è il canale che attiva il monitoraggio dei tempi di risposta e garantisce che ogni segnalazione venga presa in carico con priorità definite. Richieste urgenti su vulnerabilità di sicurezza seguono un protocollo separato, con tempi di intervento più stretti.

La differenza tra un aggiornamento fatto e uno fatto bene

C’è una concezione diffusa per cui “manutenzione WordPress” significhi cliccare “Aggiorna tutto” dal pannello di amministrazione ogni tanto. Non è sbagliata in senso assoluto, è molto meglio di non fare nulla, ma non è quello che facciamo noi, e la differenza si vede quando qualcosa va storto.

Ogni aggiornamento che gestiamo per i siti dei nostri clienti segue un protocollo preciso. Gli aggiornamenti critici di sicurezza vengono applicati entro 48/72 ore dalla divulgazione della vulnerabilità: non aspettiamo il ciclo settimanale perché alcune falle vengono sfruttate attivamente in pochi giorni. Le major release e gli aggiornamenti ordinari vengono invece pianificati ogni sette giorni lavorativi, con una verifica preventiva di compatibilità prima di procedere.

Prima di procedere, leggiamo i changelog. Non è un passaggio formale: il changelog di un plugin o di WordPress core dice esattamente cosa è cambiato, quali funzionalità sono state modificate, quali bug risolti, quali aree del codice sono state toccate. Questa lettura permette di capire in anticipo dove guardare dopo l’aggiornamento, quali funzionalità verificare con priorità, se ci sono integrazioni che potrebbero risentirne. Aggiornare senza leggere il changelog è come sostituire un pezzo di un motore senza sapere a cosa era collegato.

Dove l’hosting lo permette, gli aggiornamenti più delicati vengono testati in un ambiente di staging, una copia separata del sito, prima di essere portati in produzione. Se un aggiornamento introduce un conflitto non risolvibile rapidamente, si fa rollback alla versione stabile precedente. Non è un fallimento: è parte del protocollo.

Questo vale soprattutto per i siti più complessi. Su VolumeBK, l’e-commerce culturale che unisce libri, dischi, corsi ed eventi con oltre dodicimila referenze a catalogo, un aggiornamento di WooCommerce applicato senza verifica potrebbe interrompere il flusso di acquisto nel mezzo di una settimana di lancio editoriale. La cautela non è timidezza: è rispetto per il contesto in cui opera il sito.

Backup, sicurezza e monitoraggio: tre cose che si notano solo quando mancano

Backup

La frequenza dei backup non è uguale per tutti i siti. Un sito editoriale con nuovi articoli ogni giorno ha esigenze molto diverse da un sito vetrina che cambia contenuti una volta al mese. Calibriamo la periodicità dei salvataggi sull’intensità editoriale del progetto: backup ravvicinati per chi pubblica spesso, frequenza ottimizzata per i siti più statici.

Dove l’hosting offre un sistema di backup nativo, lo configuriamo secondo le best practice del fornitore. Dove manca, implementiamo un protocollo con backup periodici di file e database archiviati su cloud esterno, separato dall’infrastruttura principale. L’obiettivo è che anche in caso di guasto critico all’hosting, un evento raro ma non impossibile, il ripristino sia possibile e rapido.

Sicurezza proattiva

Gli aggiornamenti sono la prima linea di difesa, ma non l’unica. Monitoriamo i tentativi di login falliti per individuare attacchi di tipo brute force: quando rileviamo attività sospette o errori di autenticazione ripetuti, il sistema blocca temporaneamente o permanentemente l’indirizzo IP responsabile. Applichiamo configurazioni di hardening specifiche per ridurre la superficie di attacco del sito: scelte architetturali che rendono più difficile la vita a chi cerca punti di ingresso.

Ogni settimana eseguiamo scansioni malware e verifichiamo l’integrità dei file core di WordPress. Non per trovare problemi gravi ogni settimana, fortunatamente è raro, ma per essere certi che, se qualcosa cambia, lo sappiamo prima del cliente e prima che diventi un’emergenza.

Monitoraggio uptime e performance

Il sito è raggiungibile? Sembra una domanda banale finché la risposta non è “no”. Il monitoraggio dell’uptime ci permette di intervenire immediatamente in caso di downtime, spesso prima che il cliente se ne accorga. Affianchiamo a questo test periodici di PageSpeed e Core Web Vitals, le metriche con cui Google misura l’esperienza degli utenti che abbiamo approfondito in un articolo dedicato, e un’ottimizzazione periodica del database per mantenere la reattività nel tempo.

Il degrado silenzioso che nessuno segnala

Un sito WordPress che non riceve manutenzione non si rompe di colpo, nella maggior parte dei casi. Si degrada gradualmente, in modo quasi invisibile. Le performance calano di qualche decimo di secondo ogni mese. I punteggi SEO scivolano perché le pagine diventano progressivamente più lente. Qualche funzionalità smette di funzionare correttamente su certi browser dopo un aggiornamento del browser stesso, non del sito. Fino a quando un aggiornamento automatico del server, fuori dal nostro controllo, introduce un’incompatibilità con una versione di PHP che il sito non supporta più.

A quel punto quello che sembrava “tutto bene” rivela mesi di debito accumulato, e risolvere tutto insieme costa molto di più che averlo prevenuto nel tempo.

È lo stesso meccanismo di un’auto che non si porta mai dal meccanico. Funziona, finché non funziona più. E quando si ferma, spesso non si tratta solo di cambiare l’olio.

I pacchetti orari: per far crescere il sito, non solo tenerlo in piedi

La manutenzione annuale garantisce che il sito sia sicuro, aggiornato e monitorato. Ma non include le modifiche: una nuova sezione, un aggiornamento grafico, una funzionalità aggiuntiva, una pagina da ristrutturare sulla base di dati di utilizzo. Per questo esistono i pacchetti orari.

Il meccanismo è semplice. Il cliente acquista un pacchetto di ore in anticipo, a un costo orario definito. Le ore non hanno scadenza: si usano quando servono, si scalano progressivamente, e quando si esauriscono si rinnova. Le richieste arrivano via email o WhatsApp, con una descrizione del problema o dell’intervento desiderato.

In qualsiasi momento il cliente può richiedere un report completo: ogni intervento eseguito con descrizione, data e durata, le ore totali acquistate e quelle ancora disponibili. Non c’è bisogno di aspettare una scadenza o un rinnovo per avere il quadro chiaro di cosa è stato fatto e quanto resta. È una forma di trasparenza che consideriamo parte del servizio, non un optional.

Quello che cambia rispetto a un intervento una tantum non è solo il prezzo, anche se avere ore già disponibili è quasi sempre più conveniente di un preventivo aperto in emergenza. Cambia il tipo di conversazione che si può avere.

Con ore disponibili, un cliente che nota qualcosa che non va può scrivere senza pensare “quanto mi costerà questa telefonata?”. Un’idea di miglioramento si può esplorare senza aprire una trattativa. Il rapporto diventa continuativo, e la continuità permette di lavorare in modo più intelligente.

La manutenzione come punto di osservazione, non solo di protezione

Chi segue un sito nel tempo impara a conoscerlo. Sa quali plugin sono stati problematici in passato, sa dove il tema custom ha certe fragilità, sa quali pagine ricevono più traffico e quali vengono ignorate. Questa conoscenza accumulata ha un valore pratico enorme quando si tratta di decidere dove investire le ore disponibili.

È per questo che nei progetti in cui lavoriamo con continuità integriamo la manutenzione con un’attività di analisi: Google Analytics 4, Google Search Console e Microsoft Clarity diventano strumenti di osservazione regolare, non dashboard che si aprono una volta all’anno. I dati raccontano dove le persone si bloccano, quali contenuti funzionano, dove il sito perde opportunità.

Nel caso di VolumeBK, guardando le session recording di Clarity, abbiamo osservato comportamenti precisi degli utenti sui filtri di ricerca: alcuni si aspettavano di aprire un pannello, altri tentavano di chiudere il menu cliccando fuori dall’area senza riuscirci. Piccole frizioni, ripetute, invisibili a chi usa il sito ogni giorno. Quei dati hanno orientato il ripensamento del sistema di filtri nel redesign: linguaggio più chiaro, aree di interazione più esplicite. Non perché qualcuno avesse un’opinione più autorevole, ma perché i dati mostravano dove le persone si bloccavano.

Senza una relazione continuativa con il sito, questo tipo di osservazione non accade. Si aspetta il prossimo grande redesign, che arriva ogni tre o quattro anni, e nel frattempo il sito accumula frizioni che nessuno ha mai deciso di accettare, ma che nessuno ha mai avuto il tempo di correggere.

Un limite reale: cosa la manutenzione non può fare

La trasparenza fa parte del nostro modo di lavorare, quindi lo diciamo esplicitamente: il contratto di manutenzione ha perimetri precisi, e fuori da quei perimetri la nostra responsabilità si ferma.

Non siamo responsabili per malfunzionamenti, instabilità o lentezza del server hosting, che dipendono dall’infrastruttura del provider. Non possiamo garantire il ripristino da perdite dati causate da guasti tecnici dell’hosting o da backup gestiti direttamente dal provider. Non copriamo vulnerabilità zero-day, ovvero falle scoperte e sfruttate prima che esista una patch, né violazioni di sicurezza a livello di server.

Questo non è uno scarico di responsabilità: è la descrizione onesta di dove finisce il software e inizia l’infrastruttura. È anche il motivo per cui la scelta dell’hosting è parte della stessa conversazione sulla manutenzione. Un provider che offre ambienti di staging, backup nativi affidabili e supporto tecnico reattivo cambia in modo concreto quello che si può fare. Per i siti dei nostri clienti raccomandiamo Kinsta proprio per questa ragione: l’infrastruttura solida riduce il perimetro dei rischi che la manutenzione applicativa non può coprire.

Da dove iniziare se il tuo sito non ha mai avuto manutenzione

Primo: scopri in che stato è il sito adesso. Apri Google Search Console e controlla se ci sono errori di copertura o problemi di Core Web Vitals. Verifica da quando non vengono aggiornati WordPress, i plugin e il tema. Se non lo sai, un developer può farlo in pochi minuti.

Secondo: identifica i rischi più urgenti. Plugin con vulnerabilità note, versioni di PHP non più supportate, assenza di backup verificati: questi sono i problemi che vanno risolti subito, prima di qualsiasi altra considerazione.

Terzo: distingui manutenzione e sviluppo. Prima di decidere cosa fare, chiarisci cosa vuoi ottenere. Se il sito è sano ma vuoi migliorarlo, i pacchetti orari sono lo strumento giusto. Se il sito non è mantenuto, il contratto annuale è il punto di partenza.

Quarto: non aspettare l’emergenza. Il momento migliore per attivare un piano di manutenzione è prima che succeda qualcosa. Il secondo momento migliore è oggi.

Se vuoi capire da che parte iniziare

Se hai un sito WordPress e non sei sicuro di come stia davvero, possiamo guardarlo insieme. Il nostro servizio di manutenzione e sicurezza WordPress parte sempre da un’analisi dello stato reale del progetto, non da un preventivo generico.