Questo articolo è una traduzione assistita dall’AI dell’originale in inglese, revisionata dall’autore.
Primo di una trilogia sullo strato di contenuto, la parte dello stack che decide cosa un’esperienza può dire e mostrare. Leggetelo insieme al DAM, lo strato degli asset diventato una supply chain, e alla DXP, la categoria che ha cercato di contenere l’intera esperienza.
I primi sistemi di gestione dei contenuti web risolvevano un problema che oggi suona quasi banale ma allora non lo era. Le organizzazioni volevano pubblicare più pagine, più spesso, senza chiedere a uno sviluppatore di modificare l’HTML ogni volta che cambiava la descrizione di un prodotto, un comunicato stampa o un indirizzo aziendale. Il web delle origini era fatto di file, con contenuto, layout, navigazione e codice spesso mescolati insieme, così pubblicare significava modificare un documento, controllare i link, spostare i file su un server e sperare che nulla si rompesse. Man mano che i siti crescevano, quel modello smetteva di scalare.
Il CMS ha separato il contenuto almeno da una parte del codice attorno, introducendo template, workflow, permessi, versioning e un’interfaccia che le persone fuori dal team di sviluppo potevano davvero usare. Quella separazione ha creato uno dei contratti operativi più duraturi della tecnologia digitale: i team di business gestiscono il contenuto, i team tecnici gestiscono il sistema che lo presenta. Per molto tempo la pagina è stata al centro di quel contratto, poi il contenuto ha smesso di avere la forma di una pagina. Doveva comparire in applicazioni mobili, esperienze di commerce, interfacce di prodotto, email, portali clienti, assistenti vocali e dispositivi connessi, e ora deve anche essere recuperato, interpretato e assemblato da agenti AI. Il CMS è sopravvissuto a ognuna di quelle transizioni, ma ogni volta ha cambiato significato. Quello che era nato come motore di pubblicazione di pagine è diventato un repository di contenuto strutturato, poi una piattaforma headless, poi parte di un’architettura componibile, e ora i vendor lo descrivono sempre più come lo strato di contenuto per l’esperienza agentica. L’acronimo è rimasto lo stesso. Il ruolo architetturale no.
Ho osservato gran parte di quell’evoluzione dall’interno. Alla fine degli anni Novanta costruivo sistemi di gestione dei contenuti in Allaire ColdFusion, oggi una tecnologia Adobe, quando separare il contenuto dal codice significava ancora scrivere a mano le query per il database ed i template delle pagine. La mia tesi di laurea era su una piattaforma di blog che avevo scritto da zero e chiamato AVBlog, un progetto che è sopravvissuto alla tesi abbastanza a lungo da rilasciare una version 1.5 a metà anni 2000 (ed utilizzato da diversi siti live), e costruirlo significava reinventare a mano ogni astrazione di cui parla in questo articolo: un modello di contenuto, i template, un workflow di editing, i permalink. Più tardi ho gestito ambienti web enterprise su Adobe Experience Manager Sites e Assets, ed ho tenuto in vita siti dinamici più piccoli su WordPress e Joomla. Il filo conduttore di tutto questo è l’unica cosa che non è mai cambiata. Nel momento in cui smettete di modificare file e iniziate a gestire contenuto, avete preso una decisione architetturale, che ve ne accorgiate o no.
Cosa risolveva davvero
Il problema originale del CMS non era la content strategy, era la dipendenza dalla pubblicazione. Prima che la gestione dei contenuti diventasse una categoria di software, aggiornare un sito richiedeva di solito l’accesso ai file sottostanti e conoscenze tecniche sufficienti a non danneggiare la presentazione o la navigazione attorno, così anche cambiamenti semplici dipendevano da un webmaster, uno sviluppatore o un’agenzia. Man mano che i siti aziendali si espandevano da poche pagine statiche a cataloghi prodotto, newsroom, sezioni investitori, siti multilingua e destinazioni di customer service, quel collo di bottiglia diventava impossibile da ignorare.
Un CMS ha rotto il collo di bottiglia introducendo un insieme di astrazioni che insieme hanno cambiato il modo di pubblicare. Il contenuto poteva essere inserito tramite form invece che scritto direttamente in HTML, i template potevano controllare la presentazione separatamente dalle parole e dalle immagini al loro interno, e ruoli e approvazioni potevano determinare chi era autorizzato a creare, revisionare e pubblicare. La cronologia delle versioni rendeva i cambiamenti tracciabili e reversibili, la navigazione e le relazioni fra pagine diventavano qualcosa che il sistema gestiva invece di qualcosa mantenuto a mano, e la pubblicazione stessa diventava un workflow controllato invece di un compito di trasferimento file.
Il cambiamento importante era organizzativo tanto quanto tecnico. Un team di marketing, comunicazione o editoriale poteva ora possedere il calendario di pubblicazione senza possedere il codice. Gli sviluppatori costruivano ancora i template e le integrazioni e i designer definivano ancora il sistema di presentazione, ma la pubblicazione quotidiana si avvicinava alle persone responsabili del messaggio. È per questo che il CMS è diventato così diffuso. Non ha semplicemente reso i siti più facili da costruire, ha cambiato chi poteva operarli.
C’è qui una genealogia più lunga che vale la pena nominare, perché il web stesso è stato proposto come risposta alla complessità della gestione dell’informazione. La proposta del 1989 di Tim Berners-Lee al CERN descriveva un modo per connettere informazioni distribuite fra persone, sistemi e documenti, e il CMS è arrivato più tardi come una risposta pratica a una versione più ristretta dello stesso problema: come organizzare, mantenere e pubblicare un corpo crescente di informazione web senza lasciarne collassare la struttura. Quel requisito originale esiste ancora. È cambiata solo la scala.
Il mercato che lo ha plasmato
Il mercato del CMS è stato plasmato da due forze diverse che alla fine si sono incontrate a metà strada. La prima era la gestione dei contenuti web enterprise, dove le grandi organizzazioni avevano bisogno di governance, pubblicazione multilingua, gestione multisito, permessi complessi, rilasci programmati, integrazioni e funzionamento affidabile su grandi patrimoni digitali, così i vendor costruivano sistemi attorno a siti aziendali, portali e team di pubblicazione ad alto volume. La seconda era la pubblicazione web aperta, dove piattaforme come Drupal e WordPress rendevano la gestione dei contenuti accessibile a un mercato molto più ampio, abbassando il costo di gestire un sito, creando grandi ecosistemi di sviluppatori e affermando l’aspettativa che pubblicare dovesse essere possibile tramite un browser invece che tramite un processo di deploy. WordPress da solo gira ancora su qualcosa oltre il quaranta per cento di tutti i siti web, e su quasi il sessanta per cento di ogni sito costruito su un CMS riconoscibile, che è la misura più chiara che esista di quanto completamente il modello di pubblicazione via browser abbia vinto. Questi due mercati differivano per scala e modello operativo, ma condividevano la stessa assunzione architetturale: il sito era la destinazione primaria, e la pagina era l’unità primaria di contenuto.
Quell’assunzione ha plasmato il modello dati. Una pagina aveva un titolo, un corpo, un’immagine, una posizione in una gerarchia e magari una collezione di componenti, i template determinavano dove quegli elementi comparivano, la navigazione rifletteva l’albero delle pagine, e l’anteprima significava vedere la pagina come sarebbe apparsa sul sito. Per il mercato che ha creato il CMS, questo era esattamente giusto. Il sito era il centro dell’esperienza digitale, le applicazioni mobili erano secondarie o non esistevano, il contenuto delle email era di solito assemblato altrove, le piattaforme di commerce gestivano la presentazione del prodotto in modo indipendente, e i sistemi di customer engagement consegnavano messaggi attraverso i propri template. Il CMS possedeva il sito, e il resto dello stack possedeva tutto il resto attorno.
Col tempo quel confine netto è diventato più difficile da sostenere. I team di contenuto volevano riutilizzare la stessa storia di prodotto su web, app, email e commerce, i brand volevano un unico processo di approvazione per ogni canale, gli sviluppatori volevano front end moderni senza sostituire il workflow editoriale, e i team regionali volevano flessibilità locale senza ricreare lo stesso contenuto in ogni mercato. Il modello centrato sulla pagina ha iniziato a mostrare i suoi limiti, perché un pezzo di contenuto che esiste solo come blocco dentro una pagina è difficile da riutilizzare altrove, un messaggio di campagna salvato come HTML formattato non si assembla facilmente in una card mobile o in un componente email personalizzato, e un claim di prodotto incorporato dentro un template è difficile da governare in modo indipendente dalla pagina in cui compare. Il CMS aveva reso scalabile la pubblicazione. Ora il mercato aveva bisogno che il contenuto stesso diventasse portabile.
Come i vendor ne hanno cambiato il significato
La prima risposta è stata l’espansione. I vendor di gestione dei contenuti web hanno aggiunto form, portali, personalizzazione, analytics, strumenti di campagna, integrazioni di commerce e digital asset management finché il CMS è diventato il centro di una più ampia suite di web experience. Aveva senso commercialmente e tecnicamente, perché una volta che una piattaforma controllava già la pagina era naturale aggiungere altre delle capacità necessarie a ottimizzare quella pagina, ma ha anche dilatato la categoria al punto in cui un CMS poteva significare uno strumento di pubblicazione leggero, una piattaforma web enterprise, un motore di contenuto per il commerce o il componente di contenuto dentro una suite di esperienza molto più grande. Gli analisti hanno notato la categoria dissolversi prima della maggior parte dei buyer. Nel gennaio 2020 Gartner ha ritirato il suo Magic Quadrant per il Web Content Management dopo averlo pubblicato per circa vent’anni, giudicando il mercato ormai commoditizzato e la domanda dei clienti spostata verso lo scope più ampio della DXP, e ha ripiegato ciò che restava in una più leggera Market Guide. Quando la società di ricerca che si è fatta un nome classificando una categoria decide che la categoria non merita più un quadrante, quello è il segnale più chiaro possibile che il CMS ha smesso di essere una cosa che si compra ed è diventato uno strato dentro qualcosa di più grande. È questa la vera radice della confusione fra CMS e DXP che ancora oggi intorbida il procurement: il confine è sfumato perché Gartner stessa lo ha dissolto.
La seconda risposta è stata la separazione. Le piattaforme CMS headless hanno disaccoppiato la gestione dei contenuti dalla presentazione, e invece di assumere che il CMS avrebbe reso la pagina finale, esponevano contenuto strutturato tramite API e permettevano a siti, applicazioni e altri canali di consumarlo in modo indipendente. Questo ha cambiato l’unità di design, perché l’oggetto importante non era più sempre la pagina. Poteva essere un beneficio di prodotto, un evento, una nota legale, una proposta di campagna, la sede di un negozio, una risposta di supporto o un modulo promozionale riutilizzabile, e la modellazione del contenuto è diventata più importante della configurazione dei template. La promessa era semplice, modellare il contenuto una volta, gestirlo centralmente e consegnarlo ovunque, e il valore architetturale era reale. Uno strato di contenuto disaccoppiato permetteva ai team di sviluppo di usare framework front-end diversi, rilasciare esperienze in modo indipendente dai workflow editoriali e servire più canali dallo stesso repository governato, e si allineava naturalmente ai principi API-first, cloud-native e headless poi raggruppati sotto MACH e architettura componibile.
Ma l’headless ha introdotto un nuovo problema, perché toglieva assunzioni dalla piattaforma e poi chiedeva all’organizzazione di sostituirle con architettura. Anteprima, routing, composizione della pagina, localizzazione, ricerca, caching ed esperienza editoriale non sparivano quando lo strato di rendering veniva disaccoppiato, la loro responsabilità semplicemente si spostava, e le organizzazioni che adottavano l’headless senza progettare quelle responsabilità a volte scoprivano di aver sostituito un CMS restrittivo con un repository flessibile e una grande quantità di lavoro custom. È qui che il mercato si è spostato di nuovo, verso ciò che i vendor ora chiamano piattaforme di contenuto componibili, CMS ibridi o sistemi headless visuali, tutti tentativi di mantenere contenuto strutturato e consegnato via API restituendo abbastanza contesto a marketer ed editor per assemblare e vedere in anteprima esperienze complete.
E ora è in corso un terzo cambiamento, perché lo strato di contenuto sta diventando indirizzabile dagli agenti. L’accordo del 2026 con cui Salesforce acquisisce Contentful rende questa direzione insolitamente esplicita, con Salesforce che descrive l’architettura di contenuto strutturato di Contentful come uno strato che Agentforce può interrogare, assemblare e consegnare dinamicamente su ogni canale. Quell’inquadramento conta, perché il CMS non è più soltanto il posto dove un editor umano prepara qualcosa per la pubblicazione. Sta diventando la sorgente governata da cui una macchina può recuperare fatti approvati, claim, offerte e frammenti di contenuto in runtime. In quel modello il modello di contenuto non è solo una comodità editoriale, è il vocabolario disponibile all’agente; i permessi non sono solo controlli di pubblicazione, definiscono cosa l’agente può leggere, combinare, adattare o esporre; e i metadati non sono lì solo per migliorare la ricerca, danno all’agente il contesto necessario a decidere quale contenuto è valido per un mercato, un pubblico, una lingua, un canale o una situazione regolatoria. Il CMS si è spostato da interfaccia di pubblicazione a infrastruttura di runtime.
Cosa significa architetturalmente oggi
Un CMS moderno si capisce meglio come un sistema governato per contenuto strutturato riutilizzabile, il che è più preciso di chiamarlo piattaforma per siti web e più utile che classificarlo come headless o tradizionale prima di aver capito i requisiti. Le sue responsabilità architetturali di solito attraversano il definire la struttura e le relazioni del contenuto, gestire i workflow di authoring, revisione, approvazione e pubblicazione, controllare versioni, localizzazione e varianti di mercato, esporre il contenuto a siti, applicazioni e sistemi a valle, preservare abbastanza contesto perché gli editor capiscano dove il contenuto comparirà, imporre governance su chi può creare, cambiare, pubblicare e ritirare contenuto, e rendere il contenuto approvato individuabile da persone, applicazioni e agenti.
Ciò che non dovrebbe possedere automaticamente è altrettanto importante. Un CMS non ha bisogno di diventare il profilo cliente master, non ha bisogno di decidere quale pubblico riceve un messaggio, non ha bisogno di possedere la pressione di canale, la next-best action o l’arbitraggio dei journey, e non ha bisogno di sostituire il DAM per ogni asset binario o il PIM per ogni attributo di prodotto. La domanda architetturale pulita è quale contenuto è riutilizzabile, chi lo governa, e come ogni esperienza recupera la versione giusta, e quella domanda porta a una serie di decisioni pratiche di design. Il fallimento che vedo più spesso sta a monte di tutte: i team modellano il contenuto per adattarlo al sito che hanno oggi, così il primo canale davvero nuovo costringe a ricostruire l’intero modello, e il CMS che doveva rendere il contenuto portabile diventa la ragione per cui non lo è.
La prima decisione è l’unità minima significativa di contenuto. Se il modello è troppo grossolano, il contenuto resta intrappolato dentro le pagine, ma se è troppo atomico, gli editor devono assemblare ogni frase da frammenti e l’esperienza di authoring diventa inutilizzabile. La seconda è quali relazioni appartengono al CMS, perché una storia di prodotto può riferirsi a un’offerta, a una nota legale, a un’immagine e a un mercato, eppure il CMS non dovrebbe diventare silenziosamente il master per prezzi, inventario, consenso o eleggibilità del cliente solo perché quei valori compaiono nell’esperienza. La terza è dove viene eseguita la composizione dell’esperienza, dato che in alcune architetture il CMS assembla pagine e componenti mentre in altre un’applicazione front-end, un motore di commerce o una DXP compone l’esperienza finale a partire da più servizi, e quel confine va reso esplicito. La quarta è come funziona la personalizzazione, perché il CMS può archiviare varianti ma di solito è un altro strato a decidere quale variante è appropriata, e quando sia il CMS sia la piattaforma di engagement contengono logica di targeting, la governance diventa rapidamente difficile. L’ultima è cosa possono fare gli agenti, perché leggere contenuto approvato è diverso dal modificare contenuto sorgente, e man mano che le interfacce agentiche si diffondono il design degli accessi deve distinguere recupero, raccomandazione, composizione, modifica e pubblicazione come permessi separati con rischi separati. L’architettura non è completa quando il contenuto può essere consegnato tramite un’API. È completa quando proprietà, modellazione, governance, consegna e decisioning di runtime concordano su cosa quell’API significhi.
Con cosa viene confuso
Il CMS è regolarmente usato come etichetta generica per diverse capacità adiacenti, e separarle è gran parte del valore nel capire la categoria. Non è un DAM, perché un CMS gestisce contenuto editoriale strutturato e le sue relazioni mentre un DAM gestisce asset digitali, i loro metadati, diritti, versioni e rendition; i due spesso si integrano strettamente e alcune suite li vendono entrambi, ma risolvono problemi di governance diversi. Non è una DXP, perché un CMS è di solito uno dei componenti centrali di una piattaforma di digital experience mentre una DXP rivendica un ruolo più ampio su composizione, consegna, personalizzazione, ottimizzazione e integrazione, e chiamare un CMS una DXP non crea quelle capacità aggiuntive. Non è una CEP, perché il CMS gestisce cosa si può dire mentre la CEP decide chi dovrebbe ricevere un’interazione, quando dovrebbe avvenire e attraverso quale canale, e benché un journey possa recuperare contenuto dal CMS, la governance del contenuto e il decisioning dell’engagement non andrebbero trattati come la stessa funzione. Non è un PIM, perché un sistema di product information management governa attributi di prodotto, classificazioni e informazioni commerciali mentre un CMS può aggiungere contesto narrativo ed editoriale attorno a quei prodotti senza diventare la fonte di verità per il catalogo. E non è una knowledge base, anche se può alimentarne una, perché i sistemi di conoscenza richiedono i propri modelli per autorità, evidenza, recupero e qualità della risposta, e archiviare articoli in un CMS non li rende automaticamente materiale di grounding adatto per sistemi di customer service o AI. I confini di categoria non sono perfettamente netti e non hanno bisogno di esserlo. Ciò che conta è che lo siano i confini di proprietà.
Conta ancora?
Sì, ma la vecchia definizione non basta più. Ed ecco la parte che trovo davvero strana del CMS. È sopravvissuto trent’anni non difendendo la sua definizione originale ma abbandonandola ripetutamente. Ogni volta che il CMS ha contato di più, è stato perché aveva smesso di riguardare la pagina: prima quando ha separato il contenuto dal codice, poi quando è diventato headless e ha smesso di renderizzare qualsiasi cosa, e ora mentre diventa una sorgente che le macchine leggono invece di un posto dove gli umani pubblicano. La vecchia definizione non basta più, perché il bisogno di gestire il contenuto non è sparito quando i siti sono diventati applicazioni, è diventato più importante quando il contenuto ha dovuto muoversi fra canali, mercati e interfacce. L’headless non ha reso il CMS obsoleto, ha tolto l’assunzione che il CMS dovesse possedere la presentazione finale; l’architettura componibile non ha rimosso lo strato di contenuto, ha reso più visibili i contratti attorno a quello strato; e l’esperienza agentica non rimuoverà neanche la gestione dei contenuti, renderà contenuto strutturato, provenienza, permessi e governance più consequenziali, perché le macchine consumeranno il repository a una scala e a una velocità che i team di pubblicazione umani non hanno mai raggiunto.
L’acronimo conta ancora perché la capacità conta ancora, ma un CMS non dovrebbe più essere valutato soprattutto chiedendo quanto facilmente crea una pagina. Il test migliore è se il modello di contenuto può rappresentare chiaramente il business, se le persone possono governarlo senza diventare dipendenti dagli sviluppatori, se i canali possono recuperarlo senza duplicarlo, se gli agenti possono usarlo senza aggirare approvazione, diritti o vincoli di brand, e se l’organizzazione può cambiare lo strato di presentazione senza ricostruire il contenuto stesso. Il CMS è nato come il sistema che permetteva alle organizzazioni di pubblicare senza toccare il codice, e il suo prossimo ruolo è più strategico, perché sta diventando il contratto che permette a ogni canale, applicazione e agente di usare il contenuto senza perderne il significato.
Il CMS ha smesso di essere la cosa che renderizza le vostre pagine ed è diventato la sorgente governata da cui ogni canale e ogni agente legge, quindi valutatelo come il contratto che mantiene il contenuto significativo attraverso l’intero stack, non come un editor di pagine.
Fonti
W3C
- Information Management: A Proposal (La proposta del 1989 di Tim Berners-Lee, che inquadra il web come risposta alla complessità della gestione dell’informazione distribuita.) · A Little History of the World Wide Web (La proposta originale, il primo browser-editor e la prima architettura web.)
Drupal e WordPress
- Drupal: Our history (L’evoluzione di Drupal da sito community sperimentale a CMS open-source.) · WordPress: About (La missione di pubblicazione aperta che ha reso la gestione dei contenuti via browser ampiamente accessibile.) · W3Techs: Usage statistics of WordPress (Quota di WordPress su tutti i siti e sui siti costruiti su un CMS.)
Gartner
- Gartner Retires the Magic Quadrant for Web Content Management (Il ritiro del 2020 del Magic Quadrant per il WCM man mano che il mercato si commoditizzava e la domanda si spostava verso la DXP.)
Contentful
- Headless CMS explained (La separazione della gestione dei contenuti dallo strato di presentazione e il ruolo delle API nella consegna multicanale.) · Content modelling basics (Come tipi di contenuto, campi e relazioni sostituiscono i modelli legati alla pagina.)
MACH Alliance
- The MACH Manifesto (I principi microservices-based, API-first, cloud-native SaaS e headless dietro molte architetture componibili.)
Salesforce e Contentful
- Salesforce Signs Definitive Agreement to Acquire Contentful (Contentful posizionata come infrastruttura di contenuto strutturato che Agentforce può interrogare, assemblare e consegnare dinamicamente.) · Scaling Our Vision with Salesforce (Il racconto dei fondatori sul passaggio da CMS centrato sulla pagina a contenuto strutturato per il web agentico.)
