Headless ecommerce: cos'è, come funziona e quando ha senso

Un ecommerce headless è un negozio online in cui il front end, cioè le pagine che il cliente naviga, è un software separato dal back end che governa catalogo, ordini, clienti, prezzi e pagamenti, e i due sistemi si parlano attraverso le API. La parola evoca scenari futuribili, la sostanza è una scelta di architettura: la testa, il livello di presentazione, viene staccata dal corpo, il motore commerciale, e diventa un progetto a sé.

Per chi compra non cambia nulla di visibile: naviga un sito, riempie un carrello, paga. La differenza la vive chi il negozio lo costruisce e lo gestisce, perché separare la testa dal corpo significa avere due sistemi al posto di uno, con le competenze, i costi e il coordinamento che ne seguono.

Per questo la domanda giusta su un progetto headless non è tecnica ma economica: quale risultato mi compra questa complessità, e potevo ottenerlo spendendo meno? Per la stragrande maggioranza degli ecommerce la risposta onesta è che un tema Shopify ben costruito, scelto dal Theme Store o sviluppato su misura, fa già tutto quello che serve. L'headless è lo strumento per i casi che restano fuori, e sono meno di quanti se ne raccontino. Qui spieghiamo che cosa è e come funziona, perché una scelta del genere si fa sui fatti, non sulle parole di moda.

Cosa significa headless, alla lettera

Headless significa senza testa. In un ecommerce tradizionale, quello che si chiama monolitico, front end e back end sono un blocco unico: la stessa piattaforma che gestisce il catalogo disegna anche le pagine, con i suoi template, le sue logiche di rendering, i suoi vincoli. In un ecommerce headless quel blocco viene tagliato in due. Il back end conserva tutto ciò che fa funzionare la vendita, prodotti, varianti, listini, promozioni, ordini, anagrafiche, pagamenti e checkout; il front end diventa un'applicazione autonoma che chiede al back end i dati che le servono e li presenta come vuole.

La testa, va detto, non è sparita: è diventata sostituibile, che è un altro modo di dire che è diventata un progetto a parte, con il suo budget, il suo team e il suo ciclo di vita. È qui che nasce tutto quello che dell'headless si ama e si paga: la libertà totale sul livello di presentazione da un lato, il fatto di dover costruire e mantenere quel livello da zero dall'altro.

Come funziona: le API fra il corpo e le teste

Il dialogo fra i due sistemi passa dalle API, le interfacce con cui un software espone i propri dati e le proprie funzioni a un altro software. Quando un cliente apre una pagina prodotto di un ecommerce headless, il front end chiede al back end le informazioni di quel prodotto, titolo, prezzo, varianti, disponibilità, le riceve in un formato neutro e le impagina secondo il proprio design. Lo stesso vale per il carrello, per la ricerca, per le promozioni: ogni funzione commerciale resta nel motore, il front end la richiama e la veste.

Nel caso di Shopify questo strato si chiama Storefront API, ed è l'interfaccia pensata apposta per costruire vetrine personalizzate sopra il motore della piattaforma. Un dettaglio che chiarisce bene la divisione dei compiti: anche in un progetto headless, di norma, il pagamento non si reinventa, il front end accompagna il cliente fino al checkout della piattaforma, che resta quello, con la sua sicurezza e le sue conformità; il checkout interamente custom via API esiste, ma è riservato a Shopify Plus ed è l'eccezione, non la regola. Si costruisce la testa, non si ricostruisce la cassa.

Le teste possibili: sito, app, totem, portali B2B

Se il corpo è uno e le teste sono intercambiabili, le teste possono anche essere più di una. È l'argomento storico dell'headless, e resta il più concreto: lo stesso back end che alimenta il sito web può alimentare un'app mobile pensata per la fidelizzazione, un totem nel negozio fisico da cui sfogliare il catalogo, l'applicazione con cui gli agenti raccolgono gli ordini dai rivenditori, un portale B2B in cui ogni cliente vede il proprio listino. Un solo catalogo, un solo flusso di ordini, una sola anagrafica clienti, e esperienze diverse per contesti diversi.

Questa è anche la ragione per cui l'headless va valutato con freddezza: quei canali bisogna averli davvero, o avere un piano credibile per costruirli. Un'architettura pensata per servire cinque teste, quando di testa ce n'è una sola e ce ne sarà una sola per anni, è una cattedrale con una navata inutilizzata, che però si paga tutta. Gli esempi di siti headless pubblicati raccontano meglio di ogni teoria quali progetti sfruttano davvero questa moltiplicazione.

Di cosa è fatto un progetto headless

Un ecommerce headless non è un prodotto che si compra, è un insieme di componenti che si assembla. Il motore commerciale, che fornisce le funzioni di vendita via API. Il front end, un'applicazione sviluppata con un framework moderno, che è il cuore del lavoro custom. Quasi sempre un CMS headless, perché i contenuti, testi, immagini, pagine editoriali, devono pur vivere da qualche parte e il motore commerciale non è pensato per ospitarli. Poi l'hosting del front end e lo strato di integrazione che tiene insieme i pezzi.

C'è poi lo strato che nei rendering delle presentazioni non si vede mai e nei progetti reali pesa quanto il resto: le integrazioni con i sistemi aziendali. Il gestionale che detiene giacenze e anagrafiche, il PIM che governa le schede prodotto, la logistica che riceve gli ordini, il CRM che raccoglie la relazione con i clienti: in un'architettura distribuita ognuno di questi flussi va progettato, monitorato e mantenuto, e ogni componente in più moltiplica i punti in cui qualcosa può disallinearsi.

Il risultato è che l'azienda si ritrova proprietaria di un piccolo prodotto software interno, con tutto quello che ne consegue in manutenzione, aggiornamenti e dipendenza dalle persone che lo conoscono. Come si compone uno stack del genere in pratica, con Sanity e Shopify Plus a fare rispettivamente da testa editoriale e da motore, lo abbiamo raccontato in dettaglio a parte.

Cosa cambia per chi gestisce il negozio

Sul piano operativo la differenza si sente ogni giorno. Con un tema, il team di marketing cambia una sezione della home dall'editor, sposta un banner, pubblica una landing, prova un layout diverso, tutto in autonomia. Con un headless, i contenuti si gestiscono dal CMS dentro i moduli che gli sviluppatori hanno predisposto: ciò che è stato previsto si cambia con facilità, ciò che non è stato previsto è una richiesta di sviluppo, con i suoi tempi e il suo preventivo.

Non è un difetto, è la natura dell'architettura: la libertà assoluta sul design si esercita in fase di progetto, non in fase di gestione. Ma per un'azienda abituata a fare da sola, il passaggio a un flusso mediato dagli sviluppatori è un cambiamento organizzativo prima che tecnico, e va messo sul tavolo prima di firmare, non scoperto dopo.

Quali moduli convenga prevedere, e come si progetta un modello di contenuto che regga centinaia di pagine invece di dieci, si impara facendolo: l'architettura del nostro blog sta sugli stessi pezzi di un progetto headless, e i campi con cui un contenuto viene descritto, i ruoli delle pagine e le relazioni che le legano sono raccontati uno per uno.

Quanto costa un ecommerce headless

La struttura dei costi discende da tutto quello che abbiamo visto. Si costruiscono e si mantengono due sistemi invece di uno: il front end va sviluppato da zero, l'hosting e il CMS aggiungono canoni propri, ogni evoluzione tocca più componenti e chiede più figure professionali. Un progetto headless costa quindi un multiplo di un progetto su tema, e il divario non riguarda solo l'avvio: la manutenzione, l'ottimizzazione e ogni modifica successiva pesano di più per la stessa ragione strutturale.

Per dare l'ordine di grandezza con i numeri nostri: il solo front end custom vale dai 40.000 ai 70.000 euro, e la forbice dipende da chi lo fa e da come lo fa, dall'esperienza del team e dalle funzioni richieste; uno sviluppatore senior che sa usare bene l'AI abbatte i tempi, e con i tempi i costi, e tiene un ottimo lavoro nella parte bassa del range. E il front end non è tutto il progetto: nel caso di Shopify attorno ci stanno il setup dell'ecommerce, l'eventuale data integration con i sistemi aziendali, il project management e la gestione del progetto, ognuno con la sua voce di preventivo.

Il conto vero, peraltro, non si fa sul preventivo iniziale ma sul costo totale di possesso, quello che il sistema chiederà negli anni per restare vivo e crescere. È la voce che i preventivi mostrano meno volentieri, ed è quella che decide se i vantaggi dell'architettura ripagano la complessità. Su come si legge e si confronta un preventivo ecommerce, voce per voce, abbiamo scritto una guida dedicata.

Il progetto headless deve avere un senso

Arrivati qui, il criterio dovrebbe essere chiaro: l'headless è una scelta potente che si giustifica quando il progetto ha bisogni che un tema non copre. Un'omnicanalità reale, con più teste da servire davvero. Un'esperienza utente che il vincolo del tema non consente. Requisiti internazionali o editoriali profondi. Un team tecnico strutturato, interno o di partner, capace di governare un sistema distribuito. Fuori da questi casi, la complessità non compra niente che non si potesse avere a meno.

Il ragionamento completo su quando conviene un ecommerce headless e quando invece no, compresa la stagione in cui questa architettura è stata consigliata più per l'interesse di chi la vendeva che per il bisogno di chi la comprava, lo abbiamo fatto in un articolo dedicato; e un discorso a parte, ancora meno indulgente, meritano gli svantaggi di un headless che nei pitch non compaiono mai. Qui basti la regola: prima si definisce l'esperienza da offrire, poi si sceglie l'architettura più semplice che la rende possibile.

Come si colloca Shopify: tema, ibrido o headless

Shopify è il punto di osservazione migliore per capire quanto il confine si sia spostato, perché copre l'intera scala. Da un lato i temi con architettura Online Store 2.0: sezioni componibili su tutte le pagine, blocchi app e metafield permettono oggi una libertà grafica e contenutistica che pochi anni fa richiedeva davvero un front end custom. È la ragione per cui un tema ben costruito, preso dal Theme Store o sviluppato su misura, copre la stragrande maggioranza dei progetti: i tre argomenti classici a favore dell'headless, velocità, SEO e personalizzazione, si risolvono in larga parte lì dentro, a una frazione del costo.

Dall'altro lato, per i progetti che l'headless lo giustificano, Shopify offre uno stack nativo: la Storefront API come strato di dialogo e Hydrogen e Oxygen come framework React per lo storefront e hosting globale, con Oxygen incluso senza costi aggiuntivi su tutti i piani tranne Starter, come documenta la guida ufficiale di Hydrogen. In mezzo esistono gli approcci ibridi, tema dove basta e testa custom solo dove serve. Del resto Shopify è già una piattaforma composable, anche quando si presenta come un monolite: le API ci sono tutte, l'headless è un'opzione, non un obbligo.

Una cosa però va detta con chiarezza: passare a un headless, o abbandonarlo per tornare a un tema, è un replatforming vero e proprio, con la migrazione di dati, SEO e integrazioni che ne consegue. Anche per questo la scelta va fatta bene la prima volta, sui bisogni reali del progetto e non sull'entusiasmo del momento.

Domande frequenti

Cosa significa headless in un ecommerce?

Significa che il front end, le pagine che il cliente naviga, è un software separato dal back end che gestisce catalogo, ordini e pagamenti, e che i due comunicano via API. La testa del sistema è staccata dal corpo, da cui il nome.

Che differenza c'è tra headless e composable commerce?

Il composable commerce è l'evoluzione lessicale e architetturale dello stesso principio: invece di separare solo il front end, si compone l'intera architettura assemblando servizi specializzati che dialogano via API. La logica di fondo, e con lei i vantaggi e i costi, resta la stessa, e cambiare nome alla scelta non la rende più adatta a un progetto di quanto lo fosse prima.

Un ecommerce headless ha bisogno di un CMS headless?

Quasi sempre sì. Il motore commerciale gestisce prodotti e ordini, non è pensato per ospitare contenuti editoriali, pagine di racconto e materiali di marketing: quel ruolo lo prende un CMS headless, che serve i contenuti al front end esattamente come l'ecommerce serve i dati di vendita.

Si può fare un ecommerce headless con Shopify?

Sì. La Storefront API espone catalogo, carrello e clienti a qualunque front end, e lo stack nativo Hydrogen e Oxygen fornisce framework e hosting per costruirlo dentro l'ecosistema Shopify, mantenendo il checkout della piattaforma. Resta valida la domanda che precede la tecnologia: se un tema Online Store 2.0 basta, è quasi sempre la scelta migliore.

L'headless ecommerce è una tecnologia matura che ha smesso di essere una moda, ed è un progresso: oggi la si può scegliere per quello che è, un'architettura con vantaggi precisi e costi precisi, adatta a una minoranza di progetti con bisogni veri di omnicanalità, esperienza o scala. Per tutti gli altri, il tema resta la strada più solida ed economica, e sceglierlo non è una rinuncia: è ingegneria fatta bene. Distinguere i due casi prima di firmare un preventivo è esattamente il tipo di lavoro che facciamo nei progetti ecommerce headless e nei progetti su tema, con lo stesso metodo.