Manutenzione WordPress: il costo reale nel tempo, tra dipendenze e debito tecnico

La manutenzione WordPress viene di solito venduta come un pacchetto: aggiornamenti, backup, un controllo di sicurezza al mese. Raccontata così sembra un costo fisso e uguale per tutti. Non lo è. Il tempo e il rischio di tenere in vita un sito WordPress dipendono quasi interamente da quante dipendenze ha e da quanto sono legate tra loro. È quello il vero costo da capire prima di firmare un contratto, o prima di costruire il sito.

Il grafo delle dipendenze

Un sito WordPress in produzione dipende da: versione di PHP e delle sue estensioni, versione di MySQL o MariaDB, core di WordPress, tema (e spesso tema padre), page builder e suoi add-on, ogni plugin e le librerie che ognuno porta con sé. Ciascuno ha il suo ciclo di rilascio e i suoi requisiti minimi.

Il problema nasce quando questi pezzi dipendono l'uno dall'altro:

• il page builder richiede una versione minima di PHP, ma un vecchio plugin non funziona con quella versione;
• un add-on del builder si aggiorna prima del builder stesso e rompe il layout;
• un plugin di e-commerce cambia uno hook e tre estensioni smettono di funzionare;
• l'hosting dismette una versione di PHP e il tema, non più aggiornato, va in errore.

Ogni aggiornamento diventa un problema di compatibilità da risolvere in ordine. È quello che intendo quando dico che in molti siti WordPress tutto è troppo legato a tutto.

Il debito tecnico che si accumula

Rimandare gli aggiornamenti non elimina il costo, lo sposta in avanti e lo fa crescere. Un sito fermo da due anni non si aggiorna: si migra. Salti di versione multipli su PHP, sul builder e sui plugin significano cambiamenti incompatibili accumulati, codice deprecato, personalizzazioni che non si applicano più.

Le forme più comuni di debito tecnico che trovo:

• personalizzazioni dentro il tema padre, perse al primo aggiornamento;
• codice incollato in functions.php da tutorial, senza controllo di versione;
• plugin disattivati ma non rimossi, ancora presenti sul server e ancora sfruttabili;
• dati legati al builder (shortcode e meta proprietari) che rendono ogni cambio di tema un rifacimento;
• nessun ambiente di prova, per cui ogni intervento si fa direttamente in produzione.

Cosa deve includere una manutenzione seria

Più che un elenco di servizi, conta la procedura.

Ambiente di staging

Una copia del sito, sincronizzata, su cui gli aggiornamenti si applicano e si provano prima della produzione. Senza staging, «aggiornare» significa sperare.

Aggiornamenti per priorità

Le correzioni di sicurezza si applicano subito, appena pubblicate: è lì che si gioca la finestra di esposizione. Gli aggiornamenti funzionali si raggruppano, si provano e si rilasciano con calma, leggendo i changelog dei componenti critici.

Controllo di versione

Tema e plugin su misura in un repository Git, con il deploy dal repository e non via FTP. Ogni modifica ha un autore e si può annullare.

Backup verificati

Backup automatici di file e database, conservati fuori dal server, e soprattutto ripristini provati. Un backup che nessuno ha mai ripristinato è un'ipotesi.

Monitoraggio

Disponibilità, certificato, integrità dei file del core, nuovi amministratori, errori PHP nei log, e i Core Web Vitals reali da Search Console. L'obiettivo è accorgersi prima che se ne accorgano gli utenti.

Riduzione delle dipendenze

È la parte che quasi nessun pacchetto include ed è quella che abbassa il costo nel tempo: togliere plugin inutili, sostituire con poche righe di codice ciò che fa un plugin pesante, portare fuori dal tema i dati che non gli appartengono. Ne parlo in Tema e plugin WordPress su misura o pronti.

Come valutare un'offerta

Le domande che farei a chi propone una manutenzione:

1. Gli aggiornamenti si provano su staging prima della produzione?
2. In quanto tempo vengono applicate le correzioni di sicurezza critiche?
3. I backup vengono ripristinati per prova? Dove sono conservati?
4. Cosa succede se un aggiornamento rompe il sito: chi interviene e con quale priorità?
5. Viene fatto un lavoro periodico di riduzione delle dipendenze, o solo aggiornamenti?
6. Ricevo un resoconto con cosa è stato aggiornato e cosa è stato trovato?

Se la risposta alla prima domanda è no, l'offerta costa poco perché il rischio è tuo.

Come la vedo io

Amo WordPress, ma onestamente la manutenzione di molti siti WordPress è diventata sproporzionata rispetto a ciò che fanno. Ore spese ad aggiornare componenti che nessuno ha scelto davvero, a verificare compatibilità tra pezzi che non dovrebbero dipendere l'uno dall'altro, a rincorrere vulnerabilità di plugin installati anni fa per una funzione mai usata.

Su progetti come Altura Vela, dove curo il sito WordPress insieme al gestionale che ho sviluppato in Nuxt, vedo bene la differenza: il WordPress chiede attenzione costante, il gestionale cresce con un codice che conosco riga per riga. Per questo, quando un sito non ha bisogno di un pannello dinamico, propongo di passare a un'architettura statica: la manutenzione migliore è quella che non serve.

Detto questo, quando un cliente sceglie WordPress lo seguo con la stessa cura di qualunque altro progetto. La differenza la fa la disciplina: un elenco dei componenti con il motivo per cui ciascuno è installato, un calendario di revisione delle dipendenze, la regola che nessun plugin entra senza una valutazione. Sono abitudini semplici, e trasformano la manutenzione da corsa agli aggiornamenti a lavoro pianificato.

Perché affidarlo a me

Programmo dal 1999, ho consegnato più di 300 progetti e lavoro come sviluppatore esterno con circa 30 agenzie, da Roma e da remoto. Faccio manutenzione WordPress con staging, controllo di versione e una procedura, e ogni volta che posso tolgo una dipendenza invece di aggiungerne una.

Se vuoi capire quanto ti costa davvero il tuo sito e come alleggerirlo, scrivimi: in una chiacchierata di circa 20 minuti guardiamo insieme cosa c'è sotto. Il servizio è in Manutenzione WordPress.