Un sito aziendale smette di inviare i messaggi del modulo contatti. Il proprietario lo scopre quando un cliente telefona, dopo aver provato più volte a chiedere informazioni. Contatta chi ha realizzato il sito, ma scopre che il preventivo iniziale comprendeva soltanto lo sviluppo: controlli periodici e assistenza erano esclusi.

Una situazione di questo tipo si può prevenire con un accordo di manutenzione chiaro. Non basta leggere «aggiornamenti, backup e supporto» in un’offerta: bisogna sapere chi fa cosa, con quale frequenza, come vengono verificati gli interventi e che cosa accade quando qualcosa non funziona.

Questa guida non è un modello di contratto legale. È una lista ragionata di domande che un’impresa dovrebbe porre prima di affidare la manutenzione del proprio sito a un fornitore.

Manutenzione e sviluppo: due lavori diversi

Realizzare un sito significa progettare e consegnare un prodotto digitale. Mantenerlo significa assicurarsi che la sua configurazione e le sue funzioni continuino a rispondere agli obiettivi stabiliti, intervenendo quando cambiano software, contenuti, infrastruttura o condizioni di sicurezza.

La manutenzione può comprendere una parte preventiva (verifiche, aggiornamenti, controlli dei backup), una correttiva (analisi di malfunzionamenti e ripristino) e una evolutiva (nuove pagine, funzioni, integrazioni). Queste attività richiedono competenze, tempi e costi differenti. È ragionevole che non siano tutte comprese in un canone indistinto.

Un contratto professionale chiarisce quali categorie siano incluse e quali invece necessitino di un preventivo specifico. Per esempio, correggere il recapito del form può essere assistenza correttiva; aggiungere un sistema di prenotazione potrebbe essere un nuovo sviluppo.

Prima distinzione: sito WordPress o sito statico?

Non tutti i siti richiedono gli stessi interventi. WordPress gestisce un CMS, temi, plugin, ruoli e spesso un database. La documentazione ufficiale raccomanda di mantenere aggiornati core, temi ed estensioni, limitando i componenti inutilizzati e pianificando il recupero in caso di incidente.

Un sito statico realizzato, per esempio, con Astro può non avere un database o plugin WordPress da aggiornare. Non significa però che sia «senza manutenzione». Restano la gestione del dominio, l’hosting, eventuali dipendenze software del processo di build, certificati, form, API esterne, accessi e contenuti da aggiornare.

La differenza è nel profilo degli interventi, non nella necessità di mantenere il sito affidabile. Una clausola uguale per ogni tecnologia rischia di addebitare servizi non necessari oppure di trascurare dipendenze importanti.

Backup: chiedere come si ripristina, non solo se esiste

Un backup è utile soltanto se contiene ciò che serve ed è possibile ripristinarlo. Per un WordPress tipico possono servire sia i file sia il database. Per un progetto statico la situazione può comprendere codice sorgente, asset, configurazioni e dati conservati in servizi esterni. La documentazione WordPress sottolinea la necessità di pianificare copia e recupero dei componenti appropriati.

Sei domande concrete da inserire nell’accordo

  1. Che cosa viene copiato? Sito, file, database, media, configurazioni o soltanto parte del sistema?
  2. Ogni quanto? La frequenza deve dipendere da quanto cambia il contenuto e da quanti dati si possono perdere.
  3. Dove? Esiste una copia separata dall’ambiente principale, protetta da accessi non autorizzati?
  4. Per quanto tempo? Quante versioni storiche rimangono disponibili?
  5. Chi verifica? Viene eseguito periodicamente un test di ripristino, almeno in un ambiente di prova?
  6. Chi paga il recupero? È incluso o fatturato a parte?

La frequenza non dovrebbe essere scelta «perché la fanno tutti». Un sito vetrina aggiornato raramente ha esigenze differenti da un portale che riceve richieste o ordini ogni giorno.

Il backup automatico non equivale a un ripristino garantito

Un provider può programmare copie giornaliere e offrire un pulsante di restore. Non è però sufficiente a dimostrare che un modulo, un’integrazione o i dati esterni torneranno a funzionare dopo un incidente. La prova utile è un recupero testato, con eventuali limitazioni documentate.

Nelle aziende che dipendono fortemente dal sito si possono definire anche due obiettivi: quanto storico di dati si è disposti a perdere (RPO) e quanto tempo di indisponibilità è accettabile (RTO). Sono obiettivi progettuali da negoziare, non risultati che derivano automaticamente dall’esistenza di un backup.

Aggiornamenti e sicurezza: chi decide quando intervenire?

La guida ufficiale WordPress considera fondamentale aggiornare il software, preferire componenti mantenuti e limitare i rischi di accesso. OWASP, nel Top 10:2025, include fra i rischi più importanti la cattiva configurazione, il controllo degli accessi e i problemi nella catena delle dipendenze software.

Da qui derivano domande operative: chi controlla gli avvisi di sicurezza? Chi valuta la compatibilità di un aggiornamento? È prevista una copia prima di modifiche potenzialmente rischiose? Chi interviene se il sito non funziona dopo l’aggiornamento?

Un aggiornamento non dovrebbe essere rinviato indefinitamente, ma neppure eseguito alla cieca su un sito con funzioni commerciali critiche. Un buon processo stabilisce quando testare in staging, quando intervenire con urgenza e chi può autorizzare eventuali modifiche a pagamento.

Credenziali, ruoli e accessi

Il cliente deve sapere chi può accedere al pannello, al provider, al dominio e ai sistemi collegati. Le credenziali personali non andrebbero condivise fra più operatori; dove disponibile, è opportuno utilizzare autenticazione a più fattori e ruoli con i privilegi strettamente necessari.

Anche la consegna finale è parte della sicurezza: alla cessazione del rapporto devono essere gestiti accessi del fornitore, rotazione delle credenziali eventualmente condivise e trasferimento delle informazioni necessarie per continuare a usare il sito.

Monitoraggio: misurare le funzioni che contano davvero

Dire che «il sito è online» non significa che sia funzionante. La homepage può aprirsi regolarmente mentre un modulo non consegna più email, una pagina restituisce un errore o un sistema di pagamento è fermo.

Prima di scegliere strumenti di monitoraggio, individuerei le funzioni essenziali: disponibilità delle pagine, scadenza dei certificati, contatti, eventuali prenotazioni o checkout, errori rilevanti. Un test periodico del modulo contatti vale spesso più di una dashboard ricca di numeri inutilizzati.

Il contratto dovrebbe chiarire quali controlli sono automatici, quali manuali, chi riceve gli avvisi e chi ha il compito di prenderli in carico. Un sistema che invia notifiche a una casella mai letta non risolve il problema.

SLA: differenza fra presa in carico e soluzione

Uno degli equivoci più costosi riguarda i tempi. «Rispondiamo entro quattro ore» non significa «ripristiniamo il servizio entro quattro ore». Un fornitore può impegnarsi a prendere in carico una segnalazione, diagnosticarla e comunicare un piano di intervento; la soluzione potrebbe dipendere anche da hosting, registrar o servizi terzi.

In un accordo chiaro dovrebbero comparire:

  • Giorni e orari effettivi dell’assistenza, con fuso orario.
  • Canale ufficiale per aprire una segnalazione.
  • Criteri per distinguere incidenti critici da richieste ordinarie.
  • Tempi di prima risposta e aggiornamento sullo stato.
  • Eventuali impegni di intervento o ripristino, con limiti espliciti.
  • Esclusioni, dipendenze da terzi ed eventuali costi straordinari.

Per una piccola attività, promettere supporto continuo 24/7 senza una struttura adeguata sarebbe poco credibile. Meglio impegni realistici e verificabili.

Proprietà di dominio, hosting e contenuti: evitare dipendenze inutili

Un’impresa dovrebbe conoscere chi risulta titolare o intestatario dei servizi, chi controlla la registrazione del dominio, dove risiede il codice sorgente e chi possiede le credenziali amministrative. È opportuno disciplinare diritti di uso, licenze e trasferibilità senza presumere che ogni componente sia automaticamente proprietà del cliente.

Domande importanti: il sito continuerà a funzionare se cambio fornitore? Posso ottenere un’esportazione utilizzabile? I contenuti e le immagini sono utilizzabili anche altrove? Cosa accade agli abbonamenti di terze parti e ai servizi pagati dal fornitore?

Non esiste una risposta universale: la portabilità dipende da tecnologia, licenze e contratto. Ma questi aspetti devono essere comprensibili prima che si verifichi un conflitto.

Cosa chiedere nel report mensile

Un rapporto di manutenzione non deve essere lungo. Dovrebbe però permettere al cliente di capire che cosa è stato fatto e che cosa richiede attenzione:

Voce Evidenza utile
Aggiornamenti Componenti aggiornati, esito e anomalie
Backup Esecuzione, data dell’ultimo test di ripristino, limiti
Incidenti Segnalazione, presa in carico, esito o attività aperte
Funzioni critiche Esito della prova di moduli e integrazioni
Sicurezza Avvisi rilevanti, priorità, interventi concordati
Prossime attività Interventi necessari, responsabilità e possibili costi

Le metriche hanno valore solo se conducono a decisioni. Un elenco di strumenti usati non sostituisce la verifica dell’effettiva operatività.

Domande frequenti

La manutenzione del sito è sempre obbligatoria?

Non esiste un unico pacchetto obbligatorio per tutti i siti. Esistono tuttavia attività continuative necessarie per mantenere servizi, sicurezza e dati sotto controllo. Frequenza e perimetro dipendono dal tipo di sito, dalle sue funzioni e dagli obblighi applicabili.

Se pago l’hosting, la manutenzione è compresa?

Non necessariamente. Alcuni provider gestiscono infrastruttura, certificati e backup, mentre aggiornamenti applicativi, moduli, contenuti e assistenza possono restare esclusi. Va verificato nel contratto concreto.

Un sito statico ha bisogno di manutenzione?

Sì, anche se può richiederne meno di un CMS complesso su certe attività. Dominio, hosting, dipendenze, moduli, integrazioni, sicurezza e contenuti rimangono responsabilità da assegnare.

Cosa succede se un aggiornamento blocca il sito?

Il fornitore dovrebbe seguire la procedura concordata: diagnosi, comunicazione, eventuale rollback o ripristino e verifica delle funzioni principali. I tempi e le responsabilità devono essere specificati prima dell’incidente.

Il contratto dovrebbe garantire che il sito non sarà mai violato?

No. Nessun fornitore può eliminare completamente il rischio. Un accordo serio descrive controlli preventivi, gestione degli incidenti, recupero e limiti del servizio, senza promesse di sicurezza assoluta.

La manutenzione si giudica quando qualcosa va storto

Un buon accordo non si misura dal numero di sigle tecniche, ma dalla chiarezza delle responsabilità. Bisogna sapere chi controlla le funzioni essenziali, come si protegge il lavoro già svolto, cosa fare in caso di incidente e quanto costano gli interventi esclusi.

Prima di firmare, chiedi un elenco verificabile delle attività, le regole per i backup e un processo realistico di supporto. E se il fornitore non distingue assistenza, sviluppo ed emergenze, chiariscilo prima di affidargli una funzione importante della tua impresa.

Vuoi progettare o rivedere un sito aziendale con un perimetro tecnico chiaro? Scopri l’approccio di UMINIA allo sviluppo web.

Fonti consultate

Le indicazioni contrattuali sono criteri pratici di valutazione, non consulenza legale.