Non perdere mai i propri contenuti: proteggere il lavoro editoriale del sito di una PMI

I contenuti sono il vero capitale

Una PMI romanda rifà il proprio sito. Sei mesi di lavoro editoriale: trenta pagine di servizi riscritte, quaranta articoli del blog, le schede prodotto, i casi di studio redatti con il titolare su un angolo di tavolo. Una mattina, un’operazione maldestra nel CMS sovrascrive metà dei testi. La versione visualizzata online era già quella nuova. Nessuno ha un’esportazione recente. Il lavoro di sei mesi riparte da zero.

Questo scenario capita più spesso di un incidente tecnico. Il codice di un sito si ricostruisce in fretta. I contenuti, invece, racchiudono ore di scrittura, scelte di tono, parole chiave studiate, una memoria aziendale. È il capitale che richiede tempo per essere rifatto.

Questo articolo spiega come proteggiamo questo livello applicativo da Voren: i testi, la cronologia del CMS, la banca dati del sito, le esportazioni. Il principio si riassume in una frase. Ogni versione dei contenuti deve poter essere ritrovata, a freddo, senza dipendere da una sola persona né da un solo strumento.

I quattro livelli di contenuto da proteggere

Il sito di una PMI contiene raramente un solo tipo di contenuto. Distinguere i livelli permette di sapere che cosa proteggere, e con quale frequenza.

I contenuti editoriali: le pagine, gli articoli, le schede prodotto. Sono i testi che il cliente rilegge, approva, modifica nel corso dei mesi. Il livello più costoso da ricostruire.

La cronologia del CMS: le bozze, le versioni intermedie, le revisioni. Un buon CMS tiene traccia di chi ha modificato che cosa e quando. Questa cronologia vale oro il giorno in cui bisogna tornare alla formulazione di tre settimane prima.

La banca dati applicativa: le voci strutturate gestite dal sito. Un catalogo di servizi, un elenco di referenze dei clienti, moduli registrati, commenti moderati. Dati che il cliente ha inserito e che non esistono da nessun’altra parte.

I media associati: le foto, le immagini, i documenti PDF caricati nel CMS. Spesso dimenticati perché sembrano «ovvi», mentre la versione ottimizzata e ritagliata esiste solo lì.

Il versioning dei contenuti, giorno dopo giorno

La prima protezione non si mette in piedi a posteriori. Vive nel modo in cui i contenuti vengono prodotti.

Da Voren, le pagine e gli articoli sono scritti in file di testo versionati in Git. Ogni modifica lascia una traccia con data e ora, attribuita, reversibile. Ritrovare la formulazione di una pagina così com’era il 3 marzo richiede pochi secondi. Ripristinare una versione precedente equivale ad annullare una correzione in un programma di videoscrittura, ma sull’intera cronologia del sito.

Questa scelta cambia la natura del rischio. Un errore di scrittura non distrugge nulla in modo definitivo. Una cancellazione accidentale si recupera. Due persone che lavorano sullo stesso testo vedono i loro contributi fondersi in modo pulito invece di sovrascriversi.

Per i contenuti gestiti direttamente dal cliente in un CMS, la logica si trasferisce. Si attiva la cronologia delle revisioni, si documenta chi ha il diritto di pubblicare e si introduce una rilettura prima della messa in produzione. I contenuti non passano mai da una bozza alla versione visualizzata senza un passaggio intermedio tracciato.

Le esportazioni regolari dal CMS

La cronologia interna di un CMS protegge dall’errore umano. Non protegge dalla perdita dello strumento stesso: un account sospeso, una banca dati corrotta, un fornitore che chiude.

La risposta sta in una parola. Esportazione. I contenuti devono uscire dal CMS a intervalli regolari, in una forma leggibile e indipendente.

In concreto, un’esportazione programmata recupera l’insieme dei contenuti strutturati e li deposita in uno spazio di archiviazione separato dallo strumento di produzione. A seconda del CMS, assume la forma di un file di dati completo, di un’esportazione della banca dati o di una cartella di file. Ciò che conta è il risultato. Il giorno in cui il CMS diventa inaccessibile, i contenuti esistono altrove, in un formato che si può rileggere e reimportare.

La frequenza dipende dal ritmo delle modifiche:

Sito vetrina poco modificato: basta un’esportazione settimanale. Nel peggiore dei casi si perde una settimana di modifiche, cosa che resta rara su questo tipo di sito.

Sito con un blog attivo: un’esportazione giornaliera. I contenuti cambiano abbastanza da giustificare una traccia aggiornata ogni giorno.

Sito con contenuti inseriti dal cliente (catalogo, referenze, moduli): almeno un’esportazione giornaliera, con conservazione delle versioni successive per trenta-novanta giorni.

La conservazione: tenere più versioni nel tempo

Un’esportazione unica che sovrascrive la precedente protegge male. Presuppone che ci si accorga di un problema entro ventiquattro ore. Ma i danni silenziosi esistono anche nei contenuti.

Un esempio concreto. Una modifica maldestra cambia il tono di dieci schede prodotto. Nessuno se ne accorge subito, perché le pagine si visualizzano normalmente. Tre settimane dopo il cliente se ne rende conto. Se l’unica esportazione disponibile è di ieri, contiene già l’errore. Bisogna poter risalire alla versione precedente alla modifica.

Da qui una regola semplice sulla conservazione. Tenere più generazioni di esportazioni nel tempo, non solo l’ultima. Trenta giorni per un sito vetrina, novanta giorni per un sito in cui i contenuti sono un asset aziendale. Questa profondità di cronologia copre gli errori di cui non ci si accorge subito.

La stessa logica vale per la cronologia del CMS. Una conservazione troppo breve delle revisioni equivale a cancellare la memoria dei testi. La si imposta abbastanza ampia da coprire un ciclo completo di rilettura.

Il ripristino testato: la parte che tutti saltano

Un’esportazione mai reimportata non è una protezione. È una supposizione.

Il file può essere troncato, illeggibile, incompatibile con la versione attuale del CMS. Una cartella di media può aver perso i percorsi che collegano le immagini alle pagine. Lo si scopre solo al momento del ripristino, cioè nel momento peggiore, se non lo si è mai verificato a freddo.

La contromisura si riassume in un’abitudine trimestrale:

1. Recuperare l’ultima esportazione dei contenuti.
2. Reimportarla in un ambiente di rilettura separato.
3. Verificare che le pagine, gli articoli e le schede si visualizzino con il testo intatto.
4. Controllare che i media siano correttamente collegati ai loro contenuti.
5. Annotare il risultato: durata, punti critici, correzioni da apportare.

Se il ripristino fallisce, l’esportazione era inutile. Lo si scopre durante un test tranquillo, non durante un incidente. E si corregge subito il processo.

L’esempio del blog di Voren

Il blog che state leggendo conta più di cento articoli. Ognuno vive in un file di testo versionato. La cronologia completa di ogni pagina risale alla sua prima riga. Una riscrittura come questa lascia una traccia pulita, reversibile, attribuita.

Parallelamente, i contenuti strutturati del sito vengono esportati ogni giorno verso uno spazio di archiviazione distinto dallo strumento di produzione, con novanta giorni di conservazione a scorrimento. Ogni trimestre viene effettuato un ripristino di controllo in un ambiente di rilettura. L’ultimo ha richiesto undici minuti e ha confermato l’integrità dell’insieme.

Una volta impostato, questo dispositivo non costa quasi nulla da far funzionare. Costa soprattutto rigore al momento dell’installazione. È il ruolo della manutenzione: trasformare una buona intenzione in una routine che regge.

Gli errori frequenti

Contare solo sulla cronologia del CMS. Lo strumento conserva una memoria interna, molto utile contro l’errore umano. Il giorno in cui lo strumento stesso si blocca o diventa inaccessibile, questa memoria se ne va con lui. Serve una copia dei contenuti al di fuori dello strumento.

Dimenticare i media. Il testo viene esportato, le immagini no. La versione ritagliata e ottimizzata delle immagini esiste solo nel CMS. Va inclusa nel perimetro dei contenuti da proteggere.

Conservare solo l’ultima versione. Senza profondità di cronologia, un errore notato tre settimane dopo diventa irreparabile. Si conservano più generazioni di esportazioni.

Non testare mai la reimportazione. Un’esportazione mai rimessa alla prova è un’ipotesi, non una garanzia. La verifica trimestrale trasforma l’ipotesi in certezza.

Lasciare che il processo fallisca in silenzio. Un’esportazione programmata che si blocca senza allarme per due mesi dà un falso senso di sicurezza. Si imposta un allarme in caso di errore, e lo si sorveglia.

Per approfondire

Vedere la nostra formula di manutenzione: versioning dei contenuti, esportazioni programmate e ripristino testato inclusi, con verifica trimestrale nelle formule Pro e Premium.

Leggere il nostro articolo sul calendario editoriale: aiuta a costruire i contenuti che meritano di essere protetti.