Perche la tua web agency non aggiorna il sito (e perche e un problema)

Il modello "costruisci e dimentica"

Ecco qualcosa che la maggior parte delle web agency non ti dira mai: nel momento in cui ti consegnano il sito finito, smettono di pensarci. La fattura e pagata, il progetto e chiuso, il team passa al cliente successivo. Il tuo sito resta su un server da qualche parte, con lo stesso codice del lancio, e diventa un po' piu vulnerabile ogni settimana che passa.

Non e un problema di nicchia. E lo stato predefinito del settore web, specialmente in Ticino e in tutta la Svizzera. Ho verificato centinaia di siti web di PMI nel corso degli anni, e lo schema e tristemente coerente: un sito costruito due o tre anni fa, con un CMS obsoleto, con plugin che non sono stati toccati dal giorno del lancio. L'agenzia che l'ha costruito? E andata avanti. Potrebbe non esistere piu.

Le conseguenze sono reali. Un sito web non aggiornato e una porta aperta per gli aggressori. Se vuoi capire i rischi specifici, li abbiamo trattati in dettaglio nel nostro articolo sui rischi di un sito web non aggiornato. Ma oggi voglio concentrarmi sul perche questo accade e cosa puoi fare come imprenditore.

Perche le agenzie non aggiornano il tuo sito

Non c'e un contratto di manutenzione

Il motivo piu comune e il piu semplice: nessuno ha concordato la manutenzione del sito. L'agenzia ti ha preventivato design, sviluppo e lancio. La manutenzione non faceva parte dell'ambito, non e stata discussa, non e stata prezzata. Una volta che il sito e online, l'agenzia non ha alcun obbligo contrattuale di toccarlo di nuovo.

Dal punto di vista dell'agenzia, questo ha perfettamente senso dal punto di vista finanziario. La manutenzione e un lavoro a basso margine. Richiede di tenere traccia di decine o centinaia di siti cliente, ciascuno con versioni CMS diverse, plugin diversi, ambienti di hosting diversi. Significa gestire fallimenti di aggiornamento, layout rotti e problemi di compatibilita, il tutto per una tariffa mensile che copre a malapena il tempo impiegato.

Quindi la maggior parte delle agenzie semplicemente non la offre. O la offre come un ripensamento, una voce nel preventivo che il cliente cancella per contenere il budget.

La cultura del "non toccarlo se funziona"

C'e un atteggiamento profondamente radicato in molte agenzie, specialmente quelle piu piccole: se il sito funziona, lascialo stare. Aggiornare il core di WordPress, o Joomla, o qualsiasi CMS sia stato usato, significa rischiare che qualcosa si rompa. Un aggiornamento di un plugin potrebbe entrare in conflitto con il tema. Un aggiornamento della versione PHP potrebbe causare errori fatali. E se qualcosa si rompe, il cliente chiama, e l'agenzia deve risolvere gratis (o per un compenso che crea attrito).

Quindi il calcolo diventa: non fare nulla e nulla si rompe. Aggiorna e qualcosa potrebbe rompersi. Per un'agenzia senza ricavi da manutenzione, la scelta razionale e chiara. Non fare nulla.

Il problema, ovviamente, e che "nulla si rompe" appare vero solo in superficie. Sotto il cofano, le vulnerabilita note si accumulano. Gli aggressori scansionano proprio queste installazioni obsolete. Il sito puo sembrare a posto per anni fino al giorno in cui viene compromesso, defacciato o usato per distribuire malware. A quel punto, l'agenzia e da tempo sparita.

Nessun ambiente di staging

Un ambiente di staging e una copia del tuo sito web dove gli aggiornamenti possono essere testati prima di essere applicati al sito live. E pratica standard nello sviluppo web professionale. E anche qualcosa che la maggior parte dei progetti di siti web per PMI non include mai.

Senza un ambiente di staging, ogni aggiornamento viene applicato direttamente in produzione. Se qualcosa va storto, il tuo sito live va giu. Questo e il motivo per cui molte agenzie e i loro clienti evitano del tutto gli aggiornamenti. Il rischio di un guasto visibile sembra peggiore del rischio invisibile di una vulnerabilita di sicurezza.

Configurare un ambiente di staging non e costoso o complicato. La maggior parte dei provider di hosting di qualita offre staging con un clic. Ma deve far parte del flusso di lavoro dall'inizio, e qualcuno deve essere responsabile del suo utilizzo.

Paura di rompere le cose

Questo e strettamente correlato al problema dello staging, ma va piu in profondita. Molte agenzie, in particolare quelle piu piccole che servono il mercato PMI in Ticino, non hanno competenze tecniche approfondite nel CMS che implementano. Sanno come installare WordPress, scegliere un tema, configurare alcuni plugin e consegnare un sito che abbia un bell'aspetto. Ma non hanno l'esperienza per applicare aggiornamenti con sicurezza, risolvere problemi di compatibilita o recuperare da upgrade falliti.

Quando non sei sicuro della tua capacita di risolvere cio che un aggiornamento potrebbe rompere, eviti di aggiornare. E natura umana. Ma il risultato e che migliaia di siti web aziendali restano senza patch per anni, accumulando vulnerabilita note che qualsiasi script kiddie puo sfruttare.

Il vuoto di responsabilita cliente-agenzia

Chiedi a un imprenditore: chi e responsabile della sicurezza del tuo sito web? La maggior parte dira "la mia web agency". Chiedi alla web agency: chi e responsabile della sicurezza del sito del cliente? La maggior parte dira "il cliente, a meno che non abbiamo un contratto di manutenzione".

Questo vuoto e dove la sicurezza muore. Nessuna delle due parti crede che sia il suo compito, quindi nessuno lo fa. L'imprenditore presume che l'agenzia si stia occupando delle cose. L'agenzia presume che il cliente sappia che deve richiedere (e pagare) la manutenzione continua. Entrambe le assunzioni sono sbagliate, e il sito resta esposto.

In Svizzera, la situazione legale aggiunge un altro livello. Ai sensi della Legge federale rivista sulla protezione dei dati (nLPD/revLPD), il titolare del trattamento (cioe l'azienda che raccoglie dati personali attraverso il sito web) e responsabile delle misure tecniche adeguate. "La mia agenzia non ha aggiornato il sito" non e una difesa se i dati dei clienti vengono compromessi attraverso una vulnerabilita nota.

Segnali di allarme: la tua agenzia trascura la sicurezza

Come fai a sapere se la tua web agency sta lasciando il tuo sito esposto? Ecco degli indicatori concreti:

• Non hai mai ricevuto un rapporto di manutenzione. Se nessuno ti ha mai detto cosa e stato aggiornato e quando, nulla e stato aggiornato.
• Non sai quale versione CMS esegue il tuo sito. Se la tua agenzia non ha mai menzionato un numero di versione, non lo sta monitorando.
• Non hai un ambiente di staging. Se non puoi testare le modifiche prima che vadano in produzione, gli aggiornamenti sono rischiosi o inesistenti.
• La tua agenzia risponde alle domande sulla sicurezza con rassicurazioni vaghe. "Non preoccuparti, l'hosting si occupa di quello" non e una risposta. I provider di hosting gestiscono la sicurezza a livello server. La sicurezza a livello applicazione (il tuo CMS, i plugin, i temi) e responsabilita tua.
• Non ti e mai stato chiesto di approvare o pianificare aggiornamenti. Un partner di manutenzione responsabile comunica sugli aggiornamenti pianificati, specialmente gli upgrade di versioni maggiori.
• L'agenzia non ha un processo di sicurezza documentato. Chiedi: cosa succede quando viene divulgata una vulnerabilita critica in un plugin che usiamo? Se non possono descrivere il loro processo, non ne hanno uno.
• I tuoi plugin includono elementi abbandonati o rimossi. Controlla il pannello di amministrazione del tuo CMS. Se i plugin mostrano "Questo plugin e stato chiuso" o non sono stati aggiornati da oltre un anno, hai un problema. Il nostro articolo sulle vulnerabilita dei plugin nei CMS spiega perche questo conta.

Domande che ogni imprenditore dovrebbe fare alla propria agenzia

Se attualmente hai una web agency che gestisce il tuo sito, fissa una chiamata e fai queste domande. Le loro risposte ti diranno tutto cio che devi sapere:

1. Quale versione CMS esegue il mio sito, ed e l'ultima? Dovrebbero poter rispondere immediatamente. Se devono "controllare e rifarsi vivi", e un segnale d'allarme.
2. Quanti plugin/estensioni sono installati e sono tutti aggiornati? Dovrebbero saperlo. Dovrebbero anche poter dire quali plugin sono stati abbandonati dai loro sviluppatori.
3. Quale versione PHP esegue il mio sito? Se e inferiore a 8.2 (nel 2025), serve un piano di aggiornamento.
4. Avete un ambiente di staging per il mio sito? Se la risposta e no, chiedi perche no e cosa servirebbe per configurarne uno.
5. Qual e il vostro processo quando viene divulgata una vulnerabilita critica? La risposta corretta include il monitoraggio dei database di vulnerabilita, la valutazione dell'impatto, il test della patch sullo staging e il deployment tempestivo. Qualsiasi cosa meno specifica e una non-risposta.
6. Chi e responsabile degli aggiornamenti di sicurezza? E nel nostro contratto? Ottieni chiarezza per iscritto. Gli accordi verbali valgono la carta su cui sono stampati.
7. Cosa succede se il mio sito viene hackerato? Avete un piano di risposta agli incidenti? Un partner professionale ha un processo documentato: isolare, investigare, ripristinare dal backup, patchare la vulnerabilita, monitorare per ri-compromissione.
8. Potete mostrarmi un log di tutti gli aggiornamenti applicati negli ultimi 12 mesi? Se non esiste nessun log, nessun aggiornamento e stato applicato.

Come dovrebbe essere un vero contratto di manutenzione

Se la tua agenzia non offre manutenzione, o se la loro offerta e vaga ("teniamo d'occhio le cose"), ecco cosa dovrebbe includere un vero accordo di manutenzione:

Ambito e responsabilita

• Definizione chiara di cio che e coperto: aggiornamenti core CMS, aggiornamenti plugin, aggiornamenti tema, gestione versione PHP, monitoraggio sicurezza.
• Definizione chiara dei tempi di risposta: quanto velocemente verranno applicate le patch di sicurezza critiche? (Accettabile: entro 48 ore dalla divulgazione per CVE critiche. Non accettabile: "alla prossima finestra di manutenzione programmata, che e trimestrale.")
• Definizione chiara di cio che non e coperto: sviluppo di nuove funzionalita, modifiche ai contenuti, modifiche al design. Questi dovrebbero essere definiti e fatturati separatamente.

Processo di aggiornamento

• Tutti gli aggiornamenti testati su un ambiente di staging prima del deployment in produzione.
• Backup automatici eseguiti prima di ogni ciclo di aggiornamento.
• Procedura di rollback documentata e testata.
• Cliente notificato degli aggiornamenti maggiori (es. upgrade di versioni maggiori del CMS) prima che vengano applicati.

Reportistica

• Rapporto mensile di manutenzione che mostra: cosa e stato aggiornato, quali vulnerabilita sono state risolte, eventuali problemi riscontrati, stato attuale di tutti i componenti.
• Revisione annuale della sicurezza che riassume la manutenzione dell'anno, eventuali incidenti e raccomandazioni.

Prezzi

Quanto dovresti aspettarti di pagare? Per un sito WordPress o Joomla standard con 10-20 plugin, un contratto di manutenzione ragionevole in Svizzera costa tra CHF 150 e CHF 400 al mese, a seconda della complessita del sito e delle garanzie sui tempi di risposta. Questo copre cicli di aggiornamento regolari, monitoraggio della sicurezza, backup e risposta base agli incidenti.

Se sembra costoso, confrontalo con il costo di un sito web compromesso: fermo dell'attivita, requisiti di notifica delle violazioni dei dati secondo la legge svizzera, danni alla reputazione e il costo della bonifica d'emergenza (che tipicamente costa tra CHF 2.000 e CHF 10.000 per una compromissione seria).

Cicli di aggiornamento mensili vs trimestrali

Con quale frequenza dovrebbero essere applicati gli aggiornamenti? La risposta dipende dal profilo di rischio, ma ecco un quadro generale:

Tipo di aggiornamento	Frequenza raccomandata	Note
Patch di sicurezza critiche	Entro 48 ore	Per CVE con CVSS 7.0+, aspettare non e accettabile
Aggiornamenti di sicurezza regolari	Settimanale o bisettimanale	Fix di sicurezza minori, patch dei plugin
Aggiornamenti funzionali	Mensile	Nuove funzionalita in plugin/temi, testare a fondo
Upgrade di versione maggiore	Entro 30 giorni dal rilascio stabile	Versioni maggiori core CMS, upgrade PHP, richiedono test su staging
Audit di sicurezza completo	Annuale	Revisione di tutti i componenti, rimozione plugin inutilizzati, audit degli accessi

I cicli di aggiornamento trimestrali sono troppo lenti per qualsiasi cosa legata alla sicurezza. Nei tre mesi tra gli aggiornamenti, decine di nuove vulnerabilita possono essere divulgate nel tuo CMS e plugin. Gli strumenti di exploit automatizzati vengono aggiornati entro giorni o ore dalla pubblicazione di un CVE. Un ciclo trimestrale significa che sei potenzialmente esposto per mesi.

Mensile e la frequenza minima accettabile per aggiornamenti non critici. Settimanale e meglio. Le patch critiche dovrebbero sempre essere applicate non appena sono disponibili e testate.

Controllo interno vs dipendenza dall'agenzia

Alcuni imprenditori, frustrati dalla negligenza dell'agenzia, considerano di portare la gestione del sito web internamente. Vale la pena pensarci attentamente.

Argomenti a favore della gestione interna

• Controllo diretto: Decidi tu quando avvengono gli aggiornamenti, non un'agenzia che potrebbe deprioritizzare il tuo sito.
• Risposta piu rapida: Quando esce una vulnerabilita critica, puoi agire immediatamente invece di aspettare che la tua agenzia se ne occupi.
• Migliore consapevolezza: Comprendi la tua superficie di attacco perche la gestisci direttamente.
• Efficienza dei costi su scala: Se hai piu siti o una presenza web complessa, una persona interna puo essere piu conveniente di piu contratti con agenzie.

Argomenti a favore della gestione tramite agenzia

• Competenza: Una buona agenzia ha visto centinaia di installazioni CMS e conosce gli schemi di errore comuni.
• Strumenti: Le agenzie che prendono sul serio la manutenzione usano strumenti di monitoraggio, sistemi di aggiornamento automatizzato e scanner di vulnerabilita che sarebbero costosi per una singola azienda.
• Disponibilita: Se la tua unica persona interna e in vacanza quando esce un CVE critico, chi patcha il sito?

La via di mezzo

Per la maggior parte delle PMI, l'approccio migliore e un modello ibrido:

1. Possiedi il tuo account di hosting. Non lasciare mai che l'agenzia possieda il tuo hosting. Dovresti avere accesso diretto al server, al pannello di amministrazione del CMS e al registrar del dominio. Se l'agenzia scompare, puoi ancora accedere a tutto.
2. Possiedi il tuo repository di codice. Se e stato fatto sviluppo personalizzato, il codice sorgente dovrebbe essere in un repository che controlli tu (GitHub, GitLab, Bitbucket). L'agenzia puo avere accesso come contributore, ma tu possiedi il repository.
3. Contratta la manutenzione separatamente. Il tuo fornitore di manutenzione non deve essere la stessa agenzia che ha costruito il sito. Avere una parte diversa che controlla e mantiene il sito puo far emergere problemi che lo sviluppatore originale ha trascurato.
4. Ottieni accesso admin e formazione. Dovresti poter accedere al tuo CMS e vedere la dashboard. Dovresti sapere come controllare le versioni dei plugin. Dovresti sapere che aspetto ha un avviso di sicurezza.
5. Abbi un backup che controlli tu. I backup automatici dovrebbero andare in una posizione di archiviazione che possiedi tu, non solo il server dell'agenzia. Se l'agenzia fallisce, i tuoi backup dovrebbero essere comunque accessibili.

Cosa succede quando la manutenzione viene trascurata

Lasciate che descriva uno scenario che vediamo regolarmente. Una PMI ticinese ha fatto costruire il proprio sito web quattro anni fa da un'agenzia locale. Esegue WordPress 5.9 con 22 plugin. PHP 7.4. L'agenzia che l'ha costruito non offre piu manutenzione. L'imprenditore accede per aggiornare i contenuti occasionalmente ma ignora i badge "aggiornamenti disponibili" nella dashboard perche "l'ultima volta che ho provato, qualcosa si e rotto."

Un lunedi mattina, i clienti iniziano a segnalare che il sito web reindirizza a un sito di spam farmaceutico. Google ha gia segnalato il dominio con un avviso "Questo sito potrebbe essere stato compromesso". I posizionamenti nei motori di ricerca sono evaporati. Il modulo di contatto ha inviato spam all'intero database clienti.

La bonifica ha richiesto tre settimane e e costata CHF 8.500. Il danno alla reputazione ha richiesto molto piu tempo per essere recuperato. Tutto perche una vulnerabilita nota in un plugin, patchata dallo sviluppatore otto mesi prima, non era mai stata applicata.

Non e una storia dell'orrore inventata. E un composito di casi reali che abbiamo gestito. I dettagli cambiano (a volte e una homepage defacciata, a volte e un miner di criptovalute in esecuzione sul server, a volte sono dati dei clienti rubati), ma la causa principale e sempre la stessa: nessuno stava mantenendo il sito.

L'alternativa del sito statico

C'e un approccio diverso che elimina molti di questi grattacapi della manutenzione: i generatori di siti statici e l'architettura JAMstack moderna. I siti costruiti con strumenti come Astro, Next.js o Hugo non hanno un CMS tradizionale in esecuzione sul server. Non c'e PHP, nessun database, nessun ecosistema di plugin da patchare. La superficie di attacco e drasticamente piu piccola.

Questo non significa che i siti statici non richiedano manutenzione. Le dipendenze devono ancora essere aggiornate, le configurazioni di hosting contano ancora, e qualsiasi funzionalita dinamica (moduli di contatto, ricerca, e-commerce) introduce la propria superficie di attacco. Ma la postura di sicurezza di base e di gran lunga migliore rispetto a un'installazione CMS tradizionale.

Se stai considerando un rifacimento del sito web o un nuovo sito, vale la pena esplorare se un'architettura moderna potrebbe ridurre il carico di manutenzione continuo. Ne abbiamo scritto di piu nel nostro confronto tra WordPress e JAMstack.

Passare all'azione

Se hai letto fin qui, probabilmente riconosci alcuni di questi schemi nella tua situazione. Ecco cosa fare:

1. Scopri cosa esegue il tuo sito. Accedi al pannello di amministrazione del tuo CMS e annota la versione CMS, la versione PHP e il numero di plugin/estensioni. Se non hai accesso admin, quello e il problema numero uno.
2. Controlla quando le cose sono state aggiornate l'ultima volta. La maggior parte delle piattaforme CMS mostra la data dell'ultimo aggiornamento per ogni plugin. Se tutto e stato aggiornato l'ultima volta alla data del lancio originale, hai la tua risposta.
3. Parla con la tua agenzia. Usa le domande elencate sopra. Ottieni risposte chiare per iscritto. Se non possono o non vogliono rispondere, inizia a cercare un nuovo partner di manutenzione.
4. Fai fare una valutazione della sicurezza. Un audit di sicurezza indipendente del tuo sito web ti mostrera esattamente a che punto sei. Non si tratta di incolpare la tua agenzia; si tratta di capire il tuo rischio.
5. Imposta un piano di manutenzione. Che sia interno, tramite la tua agenzia o tramite un partner specializzato, metti in atto una manutenzione continua con responsabilita e tempistiche chiare.

Il tuo sito web non e un progetto una tantum. E un pezzo vivo di infrastruttura che richiede attenzione continua, come la tua rete aziendale, il tuo software di contabilita o i tuoi locali fisici. Le agenzie che costruiscono e dimenticano non sono malevole; stanno solo ottimizzando per il proprio modello di business. E il tuo compito assicurarti che qualcuno stia ottimizzando per la tua sicurezza.

Se hai bisogno di aiuto per valutare la tua situazione attuale o impostare un piano di manutenzione adeguato, contattaci. Lavoriamo con PMI in tutto il Ticino e la Svizzera per colmare il divario della manutenzione e mantenere i siti web sicuri.