Chi modifica il sito dopo il lancio: ruoli, permessi e approvazione dei contenuti
Come decidere chi modifica testi, immagini e parti tecniche del sito dopo il lancio, con ruoli nel CMS, un responsabile per pagina e un'approvazione.
- Nº
- 17
- Pubblicato
- Lettura
- 10 min
- Categoria
- Notes
- Scritto da
- Revylio
Chi modifica il sito dopo il lancio: contenuti alle persone, tecnica a un solo responsabile
Chi modifica il sito dopo il lancio va deciso prima della messa online. Le persone dell'azienda aggiornano i contenuti delle pagine di cui rispondono. Una sola figura tecnica, interna o esterna, gestisce template, plugin, script e utenti. Ogni pubblicazione passa da un'approvazione. In questo modo il sito conserva l'accessibilità, la velocità e la conformità ottenute con il redesign.
La governance del sito è l'insieme delle regole che stabiliscono chi può cambiare cosa, chi approva e con quali controlli. Nella pratica si traduce in tre decisioni. La prima riguarda i ruoli e i permessi nel CMS, cioè il pannello di gestione con cui si modificano le pagine. La seconda assegna un responsabile a ogni pagina. La terza introduce un passaggio di approvazione prima della pubblicazione.
Questa guida usa WordPress come esempio concreto, perché la sua documentazione ufficiale descrive ruoli e permessi in modo preciso. La stessa logica vale per qualsiasi altro CMS: cambiano i nomi dei ruoli, non il principio. Chi scrive i contenuti non deve poter alterare la struttura tecnica del sito senza saperlo.
Perché una modifica non controllata può annullare accessibilità, velocità e GDPR del redesign
Un redesign porta il sito a un livello misurabile, ma ogni modifica successiva può farlo arretrare. Il sito non si degrada per un singolo errore grave. Si degrada per piccoli interventi fatti da persone diverse, ciascuno ragionevole se preso da solo.
Velocità
Il peso delle pagine cresce facilmente con le immagini caricate senza ottimizzazione. Ogni immagine pesante aggiunta senza controllo rallenta il caricamento, soprattutto da smartphone. L'effetto sulle richieste è descritto nella guida su quanto costa un sito lento in richieste.
Accessibilità
Un sito progettato secondo WCAG 2.1 AA perde conformità quando un redattore sceglie un titolo per il suo aspetto grafico anziché per la gerarchia. Lo stesso accade con un'immagine pubblicata senza testo alternativo. I controlli da fare sono riassunti nella guida sull'accessibilità del sito aziendale dopo l'EAA.
GDPR
Un video incorporato, una chat o un codice di tracciamento possono cambiare i dati che il sito raccoglie. Per questo motivo ogni script di terze parti va valutato rispetto all'informativa e al banner dei consensi prima di essere pubblicato.
Ruoli e permessi in WordPress: i sei ruoli predefiniti e il loro significato
Un ruolo, nella definizione di WordPress, è l'insieme delle attività che un utente con quel ruolo può svolgere. Le singole attività si chiamano capabilities, cioè permessi. Ne sono esempi publish_posts (pubblicare articoli), moderate_comments (moderare i commenti) e edit_users (modificare gli utenti).
La documentazione ufficiale di WordPress su ruoli e permessi elenca sei ruoli predefiniti:
- Super Admin
- Administrator
- Editor
- Author
- Contributor
- Subscriber
Tre caratteristiche contano per la governance del sito. Un account Administrator viene creato automaticamente all'installazione. In un'installazione a sito singolo gli Administrator sono, di fatto, Super Admin. Chi ha quell'account può quindi intervenire su tutto.
Il Contributor, invece, può scrivere e gestire i propri articoli ma non pubblicarli. Il Subscriber ha un solo permesso, read, cioè la lettura.
Per Editor e Author la documentazione riporta l'elenco esatto dei permessi. Conviene leggerlo prima di assegnare questi ruoli, anziché dedurne il contenuto dal nome. Se nessun ruolo predefinito corrisponde alle esigenze dell'azienda, uno sviluppatore può crearne di nuovi. Usa le funzioni add_role() e remove_role() per i ruoli e add_cap() e remove_cap() per i singoli permessi. Questa è un'attività tecnica, da affidare al responsabile tecnico del sito.
Permessi tecnici da riservare al responsabile tecnico: codice, file e template
Alcuni permessi di WordPress toccano direttamente il codice e la struttura del sito, e non servono a chi scrive contenuti. Concederli a un redattore significa permettergli di modificare, anche senza volerlo, proprio ciò che il redesign ha messo a punto.
unfiltered_html: secondo la documentazione, abilitarlo per utenti non fidati può portare alla pubblicazione di codice dannoso o mal formattato. In WordPress Multisite solo i Super Admin lo possiedono.unfiltered_upload: non è disponibile per nessun ruolo di default, Super Admin compresi. Si attiva solo definendo la costanteALLOW_UNFILTERED_UPLOADS.edit_theme_options: è il permesso principale con cui WordPress decide chi può accedere ai template e gestirli nel Site Editor. Lo stesso controllo vale per gli endpoint REST API di template e parti di template.customize: introdotto con la versione 4.0, dà accesso al Customizer.
Il Site Editor è disponibile quando è attivo un tema a blocchi. Permette di gestire da un'unica interfaccia template, parti di template, stili e navigazione. Un cambio di stile fatto lì si propaga a tutte le pagine. Per questo motivo il permesso edit_theme_options va considerato tecnico a tutti gli effetti.
Quando consegniamo un sito, in Svennis creiamo un account nominativo per ogni persona e teniamo l'account Administrator separato da quelli di redazione. Il problema che incontriamo più spesso presso i clienti è un unico accesso amministratore condiviso, che impedisce di sapere chi ha cambiato cosa.
Un responsabile per ogni pagina: come assegnare la proprietà dei contenuti
Il responsabile di pagina è la persona che risponde del contenuto di una pagina. Lo aggiorna, ne verifica l'esattezza e decide quando cambiarlo. Una pagina senza responsabile invecchia, perché tutti presumono che se ne occupi qualcun altro.
La proprietà del contenuto e il permesso tecnico sono due cose distinte. Il responsabile della pagina servizi può avere un ruolo che non consente di pubblicare. Risponde comunque dell'esattezza del testo. Chi pubblica, a sua volta, non diventa responsabile del merito del contenuto.
Il modo più semplice per assegnare la proprietà è un registro delle pagine. Se prima del rifacimento è stato fatto l'inventario descritto nella guida su come preparare i contenuti per il nuovo sito, il registro esiste già quasi del tutto. Per ogni pagina servono quattro colonne:
- indirizzo della pagina (URL);
- responsabile del contenuto;
- persona che approva la pubblicazione;
- data dell'ultima revisione.
Il registro va tenuto dove tutti lo trovano, per esempio in un foglio condiviso. Quando una persona lascia l'azienda, le sue pagine passano a un nuovo responsabile nello stesso giorno in cui si disattiva il suo account nel CMS.
Il passaggio di approvazione prima della pubblicazione e i controlli da fare
Il passaggio di approvazione è il momento in cui una seconda persona controlla una modifica prima che diventi visibile. In WordPress si ottiene con i ruoli. Chi ha il ruolo Contributor scrive e salva il contenuto, ma non può pubblicarlo. La pubblicazione spetta a chi possiede il permesso publish_posts.
L'approvazione non deve diventare una rilettura generica. Funziona meglio come una breve lista di controlli, sempre uguale, che chi approva segue prima di pubblicare:
- Il titolo della pagina e la meta descrizione sono presenti.
- I titoli interni seguono la gerarchia della pagina e non sono scelti per l'aspetto grafico.
- Ogni immagine nuova ha un testo alternativo e un peso contenuto.
- I link portano alla pagina giusta e i testi dei link si capiscono anche letti da soli.
- La modifica non aggiunge script, video incorporati o moduli di terze parti. Se li aggiunge, passa al responsabile tecnico.
Chi approva non deve essere per forza un esperto. Deve però conoscere questa lista e sapere a chi inoltrare ciò che esce dal suo perimetro. I cambi di indirizzo delle pagine, per esempio, toccano anche i reindirizzamenti trattati nella checklist della migrazione senza perdere traffico da Google.
Tabella decisionale: chi modifica, chi approva e cosa si verifica per ogni intervento
La tabella seguente riassume la divisione dei compiti per i tipi di modifica più frequenti dopo il lancio. È un punto di partenza da adattare alla Sua organizzazione. Il principio però resta fisso: i contenuti passano dal responsabile di pagina, la struttura tecnica dal responsabile tecnico.
| Tipo di modifica | Chi la fa | Chi approva | Cosa si verifica |
|---|---|---|---|
| Testo di una pagina esistente | Responsabile della pagina | Chi ha il permesso di pubblicare | Esattezza, gerarchia dei titoli, link |
| Nuovo articolo o notizia | Redattore con ruolo Contributor | Chi ha il permesso di pubblicare | Titolo, meta descrizione, immagini |
| Immagini e documenti | Responsabile della pagina | Chi ha il permesso di pubblicare | Testo alternativo, peso della pagina |
| Script, chat, video incorporati | Responsabile tecnico | Direzione, con chi segue la privacy | Dati raccolti, consensi, velocità |
| Template, stili e menu | Responsabile tecnico | Direzione | Accessibilità su tutte le pagine coinvolte |
| Plugin e aggiornamenti | Responsabile tecnico | Responsabile tecnico, con test | Funzionamento di moduli e pagine chiave |
| Utenti e ruoli | Responsabile tecnico | Direzione | Un account per persona, nessun accesso condiviso |
Le ultime quattro righe richiedono permessi che la documentazione di WordPress collega al codice o ai template, come unfiltered_html ed edit_theme_options. Per questa ragione restano fuori dalla portata di chi scrive i contenuti.
Esempio pratico: i ruoli WordPress in un'azienda con marketing, commerciale e agenzia esterna
L'esempio che segue mostra come applicare ruoli e approvazione in un'azienda tipo, con un sito WordPress a sito singolo appena rifatto. Le persone coinvolte sono il titolare, la responsabile marketing, un commerciale, una persona dell'ufficio personale e un'agenzia esterna per la parte tecnica.
L'assegnazione dei ruoli
- Agenzia esterna: ha l'unico account Administrator. In un sito singolo è di fatto un Super Admin, quindi gestisce plugin, template, utenti ed eventuali script.
- Responsabile marketing: riceve un ruolo che includa
publish_posts. Approva e pubblica i contenuti degli altri. - Commerciale e ufficio personale: hanno il ruolo Contributor. Scrivono le pagine servizi e gli annunci di lavoro, ma non possono pubblicarli.
- Titolare: non ha bisogno di un account. Approva i cambiamenti di sostanza, come un nuovo servizio, prima che vengano scritti.
Una richiesta che esce dal perimetro dei contenuti
Il commerciale chiede di aggiungere una chat sul sito. Non è una modifica di contenuto, perché inserisce uno script di terze parti. La richiesta passa quindi all'agenzia. L'agenzia valuta l'effetto sulla velocità e sui dati raccolti, e la direzione decide insieme a chi segue la privacy. Il commerciale non ha i permessi per inserire il codice da solo, e questo è voluto.
Cosa significa per un'azienda italiana: responsabilità scritte nel contratto con l'agenzia
Per un'azienda italiana che affida la parte tecnica a un fornitore esterno, la divisione dei ruoli va scritta nel contratto. Molte PMI scoprono dopo il lancio di non sapere chi custodisce l'accesso amministratore. Non sanno nemmeno chi aggiorna i plugin o chi risponde se un modulo smette di funzionare.
Prima di firmare, conviene chiarire per iscritto alcuni punti:
- chi detiene l'account Administrator e chi conserva una copia delle credenziali in azienda;
- a nome di chi sono registrati il dominio e l'hosting;
- chi esegue gli aggiornamenti e con quali test;
- chi valuta gli script di terze parti rispetto all'informativa privacy e ai consensi;
- chi verifica che le modifiche ai template rispettino il livello di accessibilità raggiunto.
Le domande da porre al fornitore sono raccolte nella guida su come scegliere l'agenzia per il sito aziendale. Per le aziende rientranti nell'European Accessibility Act, l'accessibilità non è un obiettivo da raggiungere una volta sola. Va mantenuta a ogni pubblicazione, e per questo il passaggio di approvazione diventa parte del lavoro ordinario.
Prossimi passi: cosa fare nella prima settimana dopo il lancio del sito
Le decisioni su chi modifica il sito dopo il lancio si prendono meglio quando il sito è appena online e nessuno ha ancora abitudini consolidate. Questi passaggi richiedono poche ore e si possono fare nell'ordine indicato:
- Elencare tutti gli account del CMS e disattivare quelli condivisi o non più necessari.
- Lasciare un solo account Administrator, assegnato al responsabile tecnico.
- Assegnare ai redattori il ruolo Contributor e a una o due persone un ruolo con il permesso di pubblicare.
- Verificare che nessun ruolo di redazione abbia
unfiltered_htmloedit_theme_options. - Compilare il registro delle pagine con responsabile, approvatore e data di revisione.
- Condividere con chi approva la lista dei controlli prima della pubblicazione.
Se il sito attuale non permette questa divisione, il limite di solito è strutturale. Può trattarsi di template modificabili da chiunque, di contenuti mescolati al codice o di nessuna gestione dei ruoli. In quel caso conviene valutare un intervento sul sito stesso. La pagina sul rifacimento e restyling del sito web descrive come Revylio imposta ruoli, accessibilità e velocità fin dalla consegna.