CMS headless per l'ecommerce: quando serve e chi possiede la pagina

La domanda arriva quasi sempre nella stessa forma, e nella forma sbagliata: ci serve un CMS headless? È la domanda di chi ha già deciso l'architettura e sta cercando il pezzo che manca, e quando arriva a quel punto la decisione vera è stata presa mesi prima da qualcun altro, spesso da uno sviluppatore che aveva voglia di lavorare con un framework nuovo.

La decisione vera ha un'altra forma, meno elegante e molto più scomoda: chi possiede la pagina. Non il sito, non il progetto, non i contenuti in astratto: la singola pagina, quella che il marketing deve cambiare il giovedì pomeriggio perché la campagna parte lunedì. Chi la possiede decide dove vive il testo, chi lo può modificare senza chiedere il permesso, quale sistema genera l'URL, quale sistema decide il canonical, e in che punto della catena qualcuno resta bloccato ad aspettare.

Su questo il mercato italiano offre pochissima letteratura utile, perché la discussione si è fermata sulla definizione, e la definizione la sanno tutti. Quello che serve a chi deve firmare un preventivo è una tabella di titolarità e un conto realistico di che cosa costa tenere due sistemi invece di uno. Siamo partner Shopify, quindi il nostro non è un parere neutro, e conviene dirlo prima: quello che segue è il ragionamento che facciamo davanti a un progetto vero, con i punti in cui la piattaforma non basta scritti dove capitano.

Contenuto di prodotto, contenuto editoriale, contenuto di pagina

Prima di decidere chi possiede cosa serve smettere di chiamare contenuto tre cose diverse che si comportano in modo diverso e vivono meglio in posti diversi.

Il contenuto di prodotto è tutto ciò che descrive un articolo di catalogo e che scala con il catalogo: nome, descrizione, materiali, taglie, certificazioni, immagini, schede tecniche. Cresce con il numero di referenze, si moltiplica con le lingue, e quando il catalogo diventa grande smette di essere un problema di CMS e diventa un problema di dati, che è la ragione per cui esistono il PIM e il DAM e per cui vale la pena avere in chiaro le differenze fra PIM e DAM prima di mettere un CMS a fare un lavoro che non è il suo.

Il contenuto editoriale è quello che non ha un prodotto sotto: articoli, guide, storie di brand, pagine istituzionali, lookbook, landing di campagna. Non scala con il catalogo, scala con il numero di persone che scrivono e con la frequenza con cui pubblicano.

Il contenuto di pagina è la struttura: quali blocchi ci sono su una home, in quale ordine, con quale immagine, con quale titolo, e per quale mercato. È il contenuto che il marketing vuole toccare più spesso e quello che, se lo tocca uno sviluppatore, produce il collo di bottiglia più costoso di tutto il progetto.

Un CMS headless è bravissimo sul secondo e sul terzo, è discutibile sul primo, e la maggior parte dei progetti che si giustificano dicendo che i contenuti sono strategici in realtà ha un problema solo sul terzo. Se non hai in testa quale dei tre ti fa male, la scelta del CMS è una scommessa.

Che cosa Shopify gestisce già, con nome e cognome

La conversazione sul CMS headless nasce quasi sempre da un presupposto vecchio, che la piattaforma di commerce sappia gestire solo prodotti e ordini e che tutto il resto sia terra di nessuno. Su Shopify non è più così da anni, e conviene contare con precisione quello che c'è prima di comprare quello che manca.

I metaobject, contenuto strutturato dentro la piattaforma

I metaobject di Shopify sono strutture di dati che definisci tu. Si crea una definizione, cioè lo schema dei campi, dalle impostazioni dei dati personalizzati, e poi si creano le voci, che sono i contenuti veri e stanno nella sezione dedicata dell'admin. I campi hanno un tipo, testo, file, riferimento, URL, e una definizione può contenerne molti: è, alla lettera, contenuto strutturato, la stessa cosa che i CMS headless vendono come loro caratteristica distintiva.

Ci sono tre dettagli che fanno la differenza fra un contenitore di dati e un sistema di contenuti, e sono tutti e tre presenti. Le voci di un metaobject si possono pubblicare come pagine web attivando l'opzione nella definizione, scegliendo quali campi diventano il titolo e la descrizione per il risultato di ricerca, e con un handle che è modificabile e finisce nell'URL. Il tema può renderizzarle con un template dedicato per tipo di metaobject. E le impostazioni delle sezioni si collegano ai campi tramite le origini dinamiche, così un blocco del tema mostra il contenuto di un metaobject senza che nessuno scriva codice.

Il punto che di solito nessuno racconta è il quarto: i metaobject si modificano direttamente dall'editor del tema, senza passare dall'admin, vedendo la pagina mentre cambia. È l'editing visuale, quello che si perde andando headless, e ce l'hai già. Il confine tecnico, invece, sta nel tema: il ciclo diretto sulle voci di una definizione in Liquid ne prende cinquanta alla volta, e con la paginazione si arriva a duecentocinquanta per pagina, il che va benissimo per una raccolta di testimonianze o di schede tecniche e comincia a stringere su un archivio editoriale grande.

Il blog nativo, e dove si ferma per davvero

Shopify ha un motore di blog integrato, con un blog di default e la possibilità di crearne altri. Funziona, ed è più che sufficiente per pubblicare. I limiti veri, quelli che si sentono con una redazione al lavoro, sono due e conviene nominarli invece di scoprirli dopo.

Non esiste una funzione di categorie: l'organizzazione tematica si fa con i tag, che vanno benissimo come etichette ma non sono una tassonomia con una gerarchia e una descrizione propria. E l'autore di un articolo si sceglie da un elenco che contiene il proprietario del negozio e i membri dello staff con accesso amministrativo, mentre i collaboratori e lo staff con il solo accesso al POS non compaiono: una firma esterna, un ospite, un consulente, non è un autore ma un nome scritto dentro il testo.

Se la tua redazione è una persona che pubblica due volte al mese, nessuno dei due limiti ti toccherà mai. Se sono sei persone in tre lingue con un legale che deve leggere prima di pubblicare, li hai già incontrati entrambi, e la domanda vera diventa quale sistema debba governare il flusso di lavoro, non quale piattaforma ospiti il testo.

Quello che l'online store fa e che nessuno mette a bilancio

C'è una voce che nei confronti fra tema e headless non compare quasi mai, e che pesa: il lavoro tecnico che l'online store fa da solo. Shopify genera e mantiene la sitemap del negozio in automatico, con file separati per prodotti, collezioni, blog e pagine, e la aggiorna quando aggiungi qualcosa. Ha un robots.txt predefinito, personalizzabile via file del tema. Aggiunge i canonical per evitare i duplicati. E sui negozi internazionali include nella sitemap gli URL di ogni mercato, con canonical autoreferenziali e hreflang che collegano le versioni fra loro, aggiornandosi quando aggiungi un mercato nuovo.

Su un frontend costruito da te tutto questo diventa codice che qualcuno scrive, testa e mantiene, e che va rifatto ogni volta che nasce un mercato. Non è una ragione per non farlo, è una voce di preventivo che nei confronti non c'è quasi mai, e che si presenta puntuale al primo mercato nuovo.

Le quattro configurazioni reali, in ordine di costo

Fra il tema chiuso e la composizione totale non c'è un interruttore, c'è una scala con quattro gradini veri, ognuno con un proprietario diverso della pagina. La quasi totalità dei progetti che vediamo sta bene sul primo o sul secondo, e quasi tutti quelli che partono pensando al quarto ci arrivano dopo avere pagato il terzo due volte.

Primo gradino: tema e metaobject, la piattaforma possiede tutto

Il tema serve le pagine, i metaobject tengono i contenuti strutturati, l'editor del tema è l'interfaccia con cui il marketing lavora. Un solo sistema, un solo posto in cui cercare quando qualcosa non torna, una sola anteprima, un solo modello di URL. Il costo aggiuntivo di gestione è zero perché non c'è nessun sistema aggiuntivo da gestire, e il limite si sente quando i modelli di contenuto diventano molti e complessi o quando servono flussi editoriali che l'admin non ha.

Secondo gradino: tema più CMS per il solo editoriale

Il commerce resta interamente su Shopify e il tema resta il frontend, ma la parte editoriale, il blog, le guide, le pagine di brand, passa a un CMS esterno che serve i contenuti al tema via API. È la configurazione meno raccontata e la più frequente fra quelle che funzionano, perché risolve esattamente il problema che la maggioranza ha, cioè una redazione vera, senza toccare il transazionale e senza rifare il frontend.

È anche la configurazione in cui la parola headless diventa fuorviante: non stai facendo un ecommerce headless, stai aggiungendo un CMS accanto a un ecommerce che non è headless per niente. Chi vende progetti confonde volentieri le due cose, perché la seconda si preventiva a una frazione della prima.

Un esempio nostro, che vale più di uno schema: su TheDoubleF il magazine dentro il blog è gestito con Live Story, che non è un nostro prodotto e non è una partnership. Con Shopify quel magazine era troppo complesso da tenere in piedi, e il punto non era il backend: era l'impaginato, cioè la libertà del team marketing di comporre pagine editoriali senza passare da uno sviluppatore. Il transazionale è rimasto interamente su Shopify e il frontend non è stato toccato: è il secondo gradino, esattamente questo.

Terzo gradino: frontend costruito da te, con il CMS che lo alimenta

Qui il tema esce di scena: il sito è un'applicazione che interroga Shopify per prodotti, carrello e checkout e il CMS per tutto il resto. Il controllo sul rendering è totale, e con esso la responsabilità: routing, sitemap, hreflang, cache, anteprime, tutto passa a te. Su Shopify il percorso più battuto è quello degli strumenti di casa, e vale la pena capire come funzionano Hydrogen e Oxygen prima di scegliere uno stack proprio, perché la differenza fra i due mondi si misura in mesi di manutenzione.

Quarto gradino: commerce, contenuti e frontend separati

La composizione totale, in cui anche pezzi del commerce vengono sostituiti o affiancati da servizi specializzati. Ha senso per numeri e vincoli che si contano su una mano in Italia, e chi ci sta bene lo sa già senza chiederlo. Se ti stai chiedendo se il tuo progetto sia questo, la risposta è quasi certamente no, e la parte utile della domanda sta nel capire quando l'headless ha senso prima che la decisione la prenda l'entusiasmo di qualcun altro.

La titolarità, pagina per pagina

Il modo più rapido di trasformare la discussione architetturale in una decisione è compilare una riga per tipo di pagina e scrivere accanto un solo nome. Non due, uno: la titolarità condivisa è il modo elegante di dire che nessuno è responsabile.

Le righe che si compilano quasi da sole sono queste, e conviene scriverle in quest'ordine.

• Scheda prodotto e pagine di collezione: restano alla piattaforma, perché il prezzo, la disponibilità, le varianti e il carrello vivono lì, e ogni tentativo di farle possedere al CMS finisce con due verità sulla stessa pagina.
• Landing di campagna: è il caso in cui il CMS vince più spesso, perché cambiano ogni settimana, non hanno nulla di transazionale sotto e il costo di un ticket di sviluppo per ognuna non rientra.
• Blog e guide: decide la redazione, non l'architettura. Se sono sei persone con una revisione, il CMS; se è una persona che pubblica due volte al mese, il blog nativo basta e l'integrazione costa più di quanto rende.
• Pagine istituzionali e di servizio: seguono chi le tocca, e di solito nessuno le tocca per mesi, quindi vale la regola del sistema che c'è già.

Poi ci sono le tre righe che si scoprono a progetto avviato, e sono quelle che fanno male. La navigazione, cioè chi decide il menu: se il menu è nel CMS e le collezioni sono su Shopify, qualcuno deve tenere allineati due elenchi. I redirect, perché una pagina che cambia indirizzo ha bisogno di un 301 e i due sistemi hanno due posti diversi in cui scriverlo. E le traduzioni, che meritano un discorso a parte.

Il costo dello sdoppiamento, quello che non sta nel canone

Il canone del CMS è la parte del conto che si vede, e nei listini pubblici copre i casi piccoli: sui prodotti enterprise i piani a scaffale si fermano prima, e il caso con più team editoriali, più lingue e ambienti di test separati si tratta con un commerciale. Il costo che decide se il progetto regge, però, sta da un'altra parte, e non è una licenza.

Due anteprime, due cache, due posti dove cercare l'errore

Quando un contenuto passa per due sistemi, l'anteprima diventa un problema di ingegneria: il CMS mostra il contenuto come lo vede lui, il frontend lo mostra come lo renderizza, e fare in modo che una persona del marketing veda la pagina vera prima di pubblicare è un lavoro che va costruito e mantenuto. Sopra ci sta la cache, che ora è doppia, con due tempi di invalidazione da far combaciare. Il sintomo classico arriva il giorno del lancio: il contenuto è pubblicato, la pagina non lo mostra, e per mezz'ora nessuno sa se il problema sia il CMS, la build o la CDN.

Le URL e i redirect tornano a essere un lavoro

Con un solo sistema l'indirizzo di una pagina è una conseguenza. Con due sistemi diventa una convenzione da concordare, mantenere e documentare, e ogni contenuto che cambia posto è un redirect che qualcuno deve ricordarsi di scrivere, nel posto giusto fra i due. È il tipo di debito che non fa rumore per un anno e poi si presenta tutto insieme sotto forma di traffico organico che non torna più. Vale la pena guardarlo in faccia prima, e la parte del ragionamento che riguarda la piattaforma sta dentro un progetto di replatforming, non dentro la scelta del CMS.

Le traduzioni, dove la titolarità si vede meglio

Se il contenuto sta nei metaobject, la traduzione la gestisce Shopify: l'app Translate & Adapt traduce automaticamente fino a due lingue, permette l'editor affiancato per rivedere, consente di adattare i contenuti fra mercati che parlano la stessa lingua, e i metaobject dichiarati traducibili sono localizzabili per mercato sia dall'app sia via API. Se il contenuto sta nel CMS, la traduzione è del CMS, con il suo modello e il suo flusso, e la coerenza fra i due sistemi è tua, incluso il caso in cui una lingua esiste da un lato e non dall'altro.

Nessuna delle due soluzioni è sbagliata. Quella sbagliata è la terza, quella che nasce senza decidere, e in cui metà dei testi di un mercato vive in un sistema e metà nell'altro.

Quando un CMS headless si paga da solo

Ci sono situazioni in cui il conto gira e il secondo sistema si giustifica da sé, e hanno tutte la stessa forma: un costo che esiste già, misurabile, che il CMS elimina.

La prima è una redazione con ruoli veri, dove qualcuno scrive e qualcun altro approva prima che la pagina esca: quel passaggio, se non lo governa un sistema, lo governa una catena di messaggi, e il conto si legge negli errori che finiscono online. La seconda è un modello di contenuto che il catalogo non contiene: schede tecniche complesse, tabelle di compatibilità, storie di prodotto con relazioni fra loro, che nei metaobject si possono modellare ma diventano scomode oltre una certa soglia. La terza è la coda dello sviluppo: se ogni pagina nuova passa da un ticket e la media di attesa è di settimane, il costo del CMS è già speso, sotto forma di tempo di sviluppatori senior impiegati a spostare blocchi. La quarta è il contenuto che deve vivere fuori dal web, in un'app, su un totem, in un portale B2B con la sua interfaccia, dove il tema non arriva per costruzione. La quinta è il numero di lingue e mercati: oltre una certa scala il lavoro di traduzione ha bisogno di un sistema che lo tratti come un flusso, non come una serie di campi.

Chi ha due di questi segnali fa bene a fare i conti. Chi non ne ha nessuno e sta valutando un CMS headless sta comprando una soluzione a un problema che ha qualcun altro. Il resto del quadro, cioè il conto vero di quello che si perde, sta negli svantaggi dell'ecommerce headless, e vale la pena leggerlo prima di firmare, non dopo.

L'obiezione più solida, e chi ha ragione

L'obiezione più solida a tutto questo non è quella che si sente di solito. La versione debole dice che i contenuti servono su tutti i canali e che quindi serve un sistema che li distribuisca: è debole perché i metaobject sono interrogabili via API come qualunque altra risorsa, quindi il contenuto dentro Shopify è già distribuibile, e chi ha guardato bene sa che Shopify è già composable sotto questo aspetto. L'omnicanalità non è un buon motivo per il secondo sistema, perché il primo la regge.

La versione forte dell'obiezione è un'altra, e ha ragione: la piattaforma di commerce ottimizza per il commercio, e ogni volta che un requisito editoriale entra in conflitto con un requisito transazionale perde l'editoriale. Chi possiede il modello di contenuto dentro un ecommerce accetta che il modello resti subordinato al catalogo, e per un'azienda in cui il contenuto è il prodotto, l'editoria, la formazione, il media, quella subordinazione è la cosa sbagliata. Lì il CMS non è un costo aggiuntivo, è il sistema principale, e l'ecommerce diventa un modulo dentro il sito e non il contrario.

La distinzione operativa è questa: se il contenuto serve a vendere il prodotto, la piattaforma può possederlo; se il contenuto è ciò che vendi, non può. Quasi tutti i progetti italiani di taglia media stanno nel primo caso e si comportano come se stessero nel secondo.

Come si decide, in concreto

Il percorso che funziona è noioso e per questo raramente lo si segue. Si parte dal primo gradino, si modellano i contenuti nei metaobject, si dà al marketing l'editor del tema e si lavora così per un trimestre, tenendo un registro banale: quante volte una pagina è rimasta bloccata in attesa di uno sviluppatore, quante volte un contenuto è stato pubblicato con un errore che una revisione avrebbe intercettato, quante volte è servito un modello di dati che i metaobject non riuscivano a tenere.

Dopo tre mesi quel registro dice se il secondo sistema serve, e dice anche quale: se i blocchi sono editoriali si sale al secondo gradino e il frontend non si tocca, se il blocco è il rendering si valuta il terzo. Chi vuole vedere come si tiene insieme la coppia nel concreto trova l'architettura descritta in Shopify Plus e Sanity insieme, che è la configurazione su cui abbiamo più chilometri.

Il vantaggio di questo ordine è che ogni gradino è reversibile finché non si tocca il frontend, e diventa irreversibile subito dopo. Il costo di scoprire al mese sei che il CMS non serviva è una sottoscrizione da disdire; il costo di scoprirlo dopo avere rifatto il sito è il sito.

Domande frequenti

Un ecommerce headless ha bisogno di un CMS headless?

Sì, nella pratica: se il frontend è costruito da te, i contenuti che non sono prodotti devono stare in un sistema che li serva via API, e quel sistema è un CMS headless. La domanda utile è quella rovesciata: se hai bisogno di un CMS headless, ti serve per questo anche un ecommerce headless? Quasi sempre no, e il secondo gradino, tema più CMS per il solo editoriale, costa una frazione.

I metaobject di Shopify sostituiscono un CMS?

Coprono la parte che serve alla maggioranza dei progetti: contenuto strutturato con campi tipizzati, pagine pubblicabili con il loro URL, titolo e descrizione per la SERP, rendering nel tema tramite template e origini dinamiche, modifica dall'editor del tema, e lettura via API sia dal tema sia da un frontend esterno. Non coprono il governo di un flusso editoriale con ruoli e revisione, né i modelli di contenuto molto articolati, né gli archivi grandi da scorrere dentro il tema, e sono le tre ragioni per cui un CMS si paga.

Quanto costa un CMS headless?

I listini pubblici dei prodotti principali hanno piani a scaffale per progetti piccoli e poi passano al preventivo quando entrano più team editoriali, il multilingua e gli ambienti separati, che è la fascia in cui sta un progetto enterprise. Il numero che conta nel conto complessivo, però, non è il canone: sono le giornate di integrazione iniziale e la manutenzione ricorrente dei due sistemi. Un ordine di grandezza dai nostri progetti, come prima stima e non come preventivo: un connettore di livello enterprise fra un sistema e Shopify, sviluppato da noi, sta fra i 10 e i 30 mila euro, e dove cade dentro quella forchetta lo decide che cosa si integra.

Qual è la differenza fra un CMS headless e un PIM?

Il CMS gestisce contenuti pensati per essere letti, il PIM gestisce dati di prodotto pensati per essere distribuiti e validati, con regole di completezza e di arricchimento per canale. Si somigliano solo visti da lontano, e usare l'uno per fare il lavoro dell'altro è il modo più comune di ritrovarsi con un catalogo ingestibile.

Si può cominciare senza CMS e aggiungerlo dopo?

Sì, ed è la strada che consigliamo, a una condizione: che i contenuti nascano già strutturati nei metaobject, con campi separati e non con un unico campo di testo ricco che contiene tutto. Da campi strutturati si migra verso un CMS con una mappatura; da un blob di HTML si migra a mano.

Che cos'è esattamente un CMS headless?

È un sistema di gestione dei contenuti che non ha un frontend proprio: conserva i contenuti in forma strutturata e li espone via API, lasciando a chi costruisce l'interfaccia la libertà di renderizzarli come vuole. La spiegazione distesa, con il significato di contenuto strutturato e le funzioni che distinguono i prodotti fra loro, sta in che cos'è Sanity CMS.