Decadimento post-lancio: perché un sito crolla 6 mesi dopo

Il decadimento post-lancio è il deterioramento graduale di un sito in produzione dopo la consegna, in cui le dipendenze restano indietro, i certificati scadono, i Core Web Vitals peggiorano e i contenuti smettono di rispondere a ciò che gli utenti cercano davvero. Il sito è andato online in tempo. Sei mesi dopo, nessuno è reperibile, nulla è monitorato, e le piccole correzioni che sarebbero costate un'ora nella prima settimana ora costano un quarto del budget per rifare tutto.

È il motivo più comune per cui le aziende mid-market ci ingaggiano una seconda volta su un sito che al lancio funzionava bene. Il codice non è peggiorato da solo. Il mondo intorno è andato avanti, il sito no.

Perché fa più male di quanto sembri

I numeri non sono leggeri. L'IEEE Computer Society stima che la manutenzione software pesi tra il 60 e l'80 percento del costo totale del ciclo di vita, contro solo il 40 percento per lo sviluppo iniziale. McKinsey riporta che il 30 percento dei CIO vede più del 20 percento del proprio budget tecnologico assorbito dal debito tecnico. Il PKI and Digital Trust Report 2024 di Keyfactor indica che l'88 percento delle aziende ha subito interruzioni non pianificate per certificati scaduti nei due anni precedenti.

Sul fronte dipendenze il quadro è peggiore. Una ricerca del 2025 mostra che l'80 percento delle dipendenze applicative resta non aggiornato per oltre un anno, anche quando il 95 percento dei componenti vulnerabili ha già una versione corretta disponibile. Un progetto npm medio porta dietro 79 dipendenze transitive, e nel solo 2025 sono stati pubblicati 454.648 pacchetti npm malevoli. Ogni sito lasciato fermo è dentro questa corrente.

Sommiamo lo scivolamento dei Core Web Vitals, il decadimento dei contenuti e i link interni rotti, e il sito che a lancio si posizionava perde terreno settimana dopo settimana. L'algoritmo di Google non annuncia la retrocessione. Il traffico semplicemente cala.

Perché la soluzione ovvia non funziona

La risposta di default è richiamare lo sviluppatore originale per interventi spot. Sembra efficiente. L'ha costruito lui, lo conosce. Lo abbiamo visto rompersi in tre modi prevedibili.

Primo, il prezzo è sbagliato. Un accordo break-fix paga lo sviluppatore per aspettare che qualcosa si rompa, il contrario dell'incentivo che tiene un sito sano. Secondo, la conoscenza è già evaporata. Sei mesi dopo il lancio, lo sviluppatore che ha spedito il sito ne ha spediti altri quattro. Il git log è l'unico testimone del perché un certo middleware esiste. Terzo, il ciclo è troppo lungo. Quando uno stakeholder si accorge che la dashboard è lenta, tre mesi di dati Core Web Vitals si sono già mossi contro il sito in Search Console.

Cosa funziona davvero

Tratta il sito come un prodotto con un piccolo backlog ricorrente

La manutenzione non è una fase. È una postura. Sui siti che teniamo a retainer corriamo uno sprint ricorrente di due o quattro ore ogni due settimane. Il lavoro si riempie da solo: una PR di Renovate da unire, una regressione Lighthouse da investigare, un'API deprecata da sostituire, un articolo le cui statistiche non sono più aggiornate. Due ore ogni quindici giorni battono un rifacimento in panico.

Automatizza l'igiene delle dipendenze prima che lei automatizzi te

Renovate o Dependabot, configurati per aprire pull request immediatamente sugli aggiornamenti di sicurezza e settimanalmente per le minor, intercettano circa il 90 percento dello scivolamento delle dipendenze prima che diventi un problema. Il lavoro non è unire ogni PR. È guardarle ogni settimana. Con una suite CI che funziona davvero, il merge è una decisione da un click. Senza, gli aggiornamenti diventano una scogliera e il sito resta su versioni vecchie per anni. Il compromesso della catena di fornitura npm di settembre 2025, che ha colpito chalk, debug, ansi-styles e strip-ansi (insieme 2,6 miliardi di download settimanali), è stato un promemoria che anche i pacchetti popolari non sono sicuri per default.

Misura ciò che gli utenti sentono davvero, non ciò che il monitor sintetico dice

Il Real User Monitoring sui Core Web Vitals batte i controlli sintetici ogni volta. Il motivo è la deriva dei contenuti. Nuove immagini, nuovi script pubblicitari, nuovi tag analytics si infilano nei mesi. Un test sintetico su una pagina fissa non vede cosa attraversa un visitatore reale, su un dispositivo reale, con una rete reale. Cabliamo Vercel Analytics o Cloudflare Web Analytics su ogni sito che spediamo, e impostiamo alert quando LCP, INP o CLS superano le soglie per due settimane consecutive.

Audit dei contenuti ogni 90 giorni

Le pagine non aggiornate da più di 90 giorni perdono citazioni AI e peso nel ranking. La cura è un calendario, non il panico. Ogni 90 giorni facciamo un audit dei contenuti sulle prime 20 pagine per traffico e sulle prime 10 per conversione: statistiche attuali, fonti ancora vive, link interni che puntano a pagine che esistono ancora, FAQ allineate a ciò che gli utenti chiedono davvero. La maggior parte delle pagine si tocca in cinque minuti. Alcune ricevono un refresh vero. L'effetto aggregato sulla visibilità in ricerca è importante.

Tratta certificati e DNS come fusibili

I certificati SSL e i record DNS sono la parte più facile da automatizzare e la più costosa quando vengono ignorati. L'outage Ericsson del 2018 ha messo offline la rete O2 nel Regno Unito ed è costato circa 1,4 miliardi di dollari in rimedio, tutto perché un certificato è scaduto. Il CA/Browser Forum sta riducendo la validità dei certificati SSL/TLS pubblici a 200 giorni dal 15 marzo 2026, poi a 100 giorni, poi 47. Il rinnovo manuale non è più sostenibile. Usa Let's Encrypt con autorenew, monitora la scadenza su ogni endpoint con un servizio come Uptime Kuma o BetterStack, e imposta TTL DNS che ti permettano di fare failover senza quattro ore di cache.

Costruisci il runbook prima che ti serva

Il sito si romperà di sabato alle 23 almeno una volta l'anno. La domanda è se la risposta richiede 20 minuti o tre giorni. Per ogni sito che spediamo scriviamo un runbook di cinque pagine: chi chiamare, dove vivono i segreti, come fare rollback dell'ultimo deploy, come tirare su una pagina di manutenzione statica dal CDN, dov'è la dashboard di Sentry, come ruotare una chiave compromessa. Conservato nel password manager aziendale, non sul portatile di uno sviluppatore.

Cosa significa nella pratica

Un sito che abbiamo auditato all'inizio del 2026 era online da 11 mesi. Il team originale era andato via. I punteggi Lighthouse erano scesi da 96 a 71 su mobile perché tre tornate di modifiche marketing avevano aggiunto 800KB di immagini hero non ottimizzate. Otto dipendenze erano vecchie, due con CVE note. Il blog aveva 14 link uscenti rotti, sei che puntavano a competitor che nel frattempo avevano cambiato dominio. Il form di contatto inviava i lead a una password SMTP che IT aveva ruotato quattro mesi prima.

Nessuno di questi problemi era drammatico. Insieme, avevano tagliato il traffico organico del 38 percento in sei mesi. La cura non è stata un rifacimento. Sono state quattro settimane di lavoro strutturato: Renovate, pipeline immagini, passata sui contenuti, audit dei link, runbook. Sei mesi dopo, il traffico è sopra al livello di lancio e il team è su un retainer di due ore ogni quindici giorni che intercetta la prossima ondata prima che si accumuli.

Il decadimento post-lancio è prima una questione di budget e poi una questione di codice. Il momento più economico per rimettere a posto un sito è prima che si sia rotto. Il momento più caro è dopo che una deriva lenta si è accumulata per un anno e il rifacimento è sul tavolo. Due ore ogni due settimane sono il prodotto assicurativo più economico su Internet.