Blog di Madi Studio

Il sito non basta: cosa serve davvero per vendere online

Dimitri — Tue, 01 Sep 2026 00:00:00 GMT

Quando ci arriva la richiesta di un e-commerce, la conversazione parte quasi sempre dal sito: che aspetto avrà, quante pagine, su quale piattaforma. Domande legittime, ma sono le ultime. Il sito è la parte più prevedibile del progetto: si sceglie, si costruisce, si mette online. Quello che decide se il negozio venderà sta quasi tutto fuori dal sito, ed è la parte a cui spesso nessuno ha ancora pensato.

C'è una domanda che faccio sempre alla prima chiamata: chi prepara i pacchi? Se dall'altra parte arriva una risposta, il progetto è già a buon punto. Se arriva una pausa, il lavoro vero comincia lì.

Il catalogo non si esporta, si costruisce

Il primo scoglio non è tecnico: sono le schede prodotto. Per ogni articolo servono foto decenti, una descrizione che dica qualcosa di specifico, taglie o varianti, il peso per calcolare la spedizione, la disponibilità reale. Moltiplicato per tutto il catalogo diventa la voce di lavoro più grossa del progetto, e non compare in nessun preventivo perché non la fa lo sviluppatore: la fa chi conosce i prodotti.

La scheda prodotto è il tuo commesso. Se non sa rispondere alle domande, il cliente esce dal negozio: «maglietta di cotone di alta qualità» non dice niente a nessuno, mentre grammatura, vestibilità e istruzioni di lavaggio rispondono a quello che una persona chiederebbe al banco.

Su NNB Upcycling, un negozio di capi rigenerati che abbiamo costruito, ogni capo esiste in un pezzo solo. Il lavoro grosso non è stato il design: è stato il flusso con cui un capo entra in catalogo, viene fotografato, descritto e tolto dalla vendita nel momento esatto in cui qualcuno lo compra.

La logistica si decide prima del lancio

Corriere, tempi di consegna, imballaggio, cosa succede agli ordini del venerdì sera. Sembrano dettagli operativi da sistemare dopo, e invece condizionano il sito stesso: per calcolare le spedizioni al checkout servono pesi e zone, e se vendi anche in un negozio fisico il magazzino va tenuto sincronizzato, altrimenti prima o poi vendi online qualcosa che è appena uscito dalla porta.

Anche la soglia per la spedizione gratuita è una decisione di margine, non di design. Va fatta guardando i numeri tuoi: quanto ti costa spedire, quanto vale un ordine medio, quanto puoi assorbire per non far scappare chi ha il carrello pieno.

Il consiglio che do è scrivere il processo su carta prima di parlare con chiunque: l'ordine arriva, chi lo vede, chi preleva il prodotto, chi stampa l'etichetta, chi risponde al cliente che chiede dove sia il pacco. Se una di queste caselle resta senza un nome, è quella la cosa da risolvere. Non il sito.

Pagamenti: ogni metodo che manca è un carrello abbandonato

Integrare un sistema di pagamento oggi è routine: si attiva, si collega, funziona. La decisione vera è quali metodi offrire. Carta e PayPal sono il minimo, poi ci sono i wallet come Apple Pay e Google Pay, il bonifico per gli importi alti e, in certi settori, ancora il contrassegno. Ogni metodo ha le sue commissioni, e ogni metodo assente è una parte di clienti che arriva in fondo al checkout e non conclude.

Non esiste la lista giusta in assoluto, esiste quella giusta per i tuoi clienti. Chi compra d'impulso dal telefono vuole pagare con un tocco; chi spende cifre importanti vuole sentirsi al sicuro, e a volte vuole parlare con qualcuno prima. Il checkout va progettato su di loro, non sulle abitudini di chi lo sviluppa.

I resi sono parte del prodotto

Se vendi a consumatori, il diritto di recesso entro 14 giorni non lo decidi tu: è la legge sulla vendita a distanza. Quello che decidi tu è tutto il resto: chi paga la spedizione di ritorno, come si richiede il reso, in quanto tempo rimborsi, se offri il cambio taglia.

Una politica di reso chiara vende. È il modo con cui dici a una persona che può comprare senza rischio qualcosa che non ha mai toccato. L'errore che vedo più spesso è trattarla come un'eccezione fastidiosa da nascondere in fondo alle condizioni: il cliente la cerca prima di comprare, non dopo, e se non la trova spesso non compra.

La fiducia si costruisce con i dettagli

Un negozio online sconosciuto ha un solo modo per sembrare affidabile: essere trasparente su tutto. Partita IVA e ragione sociale nel footer, un indirizzo email che risponde, condizioni scritte in un italiano comprensibile, tempi di consegna dichiarati e poi rispettati. Niente di tutto questo costa qualcosa in sviluppo; l'assenza di uno solo di questi elementi costa vendite.

Le recensioni aiutano, ma arrivano dopo. Nei primi mesi la fiducia si gioca su segnali più piccoli: un numero di telefono vero, foto fatte da te invece che scaricate dal listino del fornitore, una pagina che racconta chi c'è dietro. Sono cose che nessuna piattaforma genera da sola.

Il sito è la parte facile

Dopo diversi progetti e-commerce la mia posizione è questa: il sito è la parte facile, ed è proprio per questo che è la prima cosa che si chiede. Ha un prezzo, un fornitore, una data di consegna. Catalogo, logistica, pagamenti, resi e assistenza non hanno niente di tutto questo: sono lavoro tuo, continuo, e nessuno può consegnarteli chiavi in mano.

Se stai pensando di aprire un e-commerce, prima di chiedere un preventivo scrivi una pagina su come gestirai queste cinque cose. Se le risposte ci sono, il progetto diventa concreto e chi lo sviluppa lavora su basi vere. Se non ci sono, meglio scoprirlo su un foglio che a negozio aperto. Noi, quando lavoriamo su un e-commerce, partiamo sempre da lì: prima il processo, poi la piattaforma.

Gestionale su misura o in abbonamento: chi si adatta a chi?

Dimitri — Thu, 27 Aug 2026 00:00:00 GMT

La richiesta arriva quasi sempre nella stessa forma: quanto costa farlo su misura. È una domanda legittima e capisco perché venga prima di tutte, ma mette a confronto un prezzo e un canone, che sono due cose che non stanno sulla stessa riga.

La domanda che conviene fare è un'altra: chi si adatta a chi.

Il canone non è un costo, è una rata

Il prodotto in abbonamento ha un vantaggio vero, e va detto subito da chi come noi vive di sviluppo: parte lunedì. Niente analisi, niente attesa, niente da costruire. Per molte aziende questo chiude la discussione, e fanno bene.

Solo che il canone ha una forma sua. Cresce con gli utenti, cresce con i moduli che a un certo punto ti servono, e non finisce mai. Un progetto su misura concentra la spesa all'inizio e poi lascia una manutenzione, che è molto più bassa ma non è zero: se qualcuno te la racconta come zero, ti sta vendendo qualcosa.

Il confronto onesto quindi non è prezzo contro canone. È quanto spendi in cinque anni nell'una e nell'altra ipotesi, contando tutto. E in quel conto c'è una voce che non compare in nessuno dei due preventivi.

Il costo di piegare l'azienda al software

È la parte che vedo più spesso quando mi passano un sistema esistente da integrare, e quasi nessuno la considera un costo.

Il prodotto a scaffale copre quasi tutto quello che fai. Quel poco che resta fuori si sistema come si può: un campo note usato per qualcosa che non c'entra, un foglio di calcolo tenuto a fianco perché quella cosa lì dentro non si può fare, un export e un reimport ogni lunedì mattina, una persona che ogni fine mese riconcilia due elenchi che dovrebbero essere lo stesso elenco.

Nessuna di queste voci ha un prezzo scritto da qualche parte. Tutte hanno un costo, si paga ogni giorno, e cresce insieme all'azienda.

C'è poi una conseguenza meno visibile e più seria: dopo un po' il processo aziendale smette di essere quello giusto e diventa quello che il software permette. Se il modo in cui lavori è un vantaggio competitivo, questo è il momento in cui lo stai buttando via per risparmiare su un canone.

Quando il prodotto in abbonamento è la scelta giusta

Lo dico volentieri, anche se da chi sviluppa su misura ci si aspetta il contrario: nella maggior parte dei casi il prodotto pronto è la risposta corretta.

Quando i processi sono standard, cioè fatturi, gestisci magazzino e scadenze come chiunque altro nel tuo settore.
Quando le integrazioni con macchinari, fornitori o portali sono poche e già previste dal prodotto.
Quando il numero di persone che lo useranno resta piccolo, perché è lì che il canone per utente resta leggero.
Quando il modo in cui lavori non è il tuo vantaggio: se il vantaggio è il prodotto che vendi o la rete commerciale, il gestionale deve solo funzionare e sparire.

In queste condizioni costruire da zero significa spendere di più per riottenere qualcosa che esiste già, e spesso peggio.

Quando i processi sono troppo tuoi

Il ribaltamento avviene quando il modo di lavorare è la cosa che ti distingue, oppure quando la tua filiera ha una forma che nessun prodotto generico ha previsto.

Capita spesso nelle aziende manifatturiere: un flusso di commessa che non somiglia a nessun altro, cataloghi con varianti che il prodotto standard non sa rappresentare, dati che devono arrivare da un macchinario o da un fornitore in un formato suo. Con Lumico abbiamo lavorato proprio su questo, una piattaforma B2B per la gestione dei grandi cantieri, dove il processo era troppo specifico perché un prodotto a scaffale lo potesse contenere.

Il segnale da riconoscere è semplice: se stai valutando prodotti e in ognuno trovi la stessa cosa che non si può fare, e quella cosa è centrale nel tuo lavoro, hai già la risposta.

Cosa c'è davvero dentro un preventivo su misura

Questa parte la scrivo io, quindi so quali voci vengono lette e quali saltate.

Analisi e sviluppo sono quelle che tutti guardano. Poi ci sono tre voci che chi legge tende a considerare accessorie, e che nella pratica decidono se il progetto va bene o male.

La migrazione dei dati è la prima, ed è quasi sempre sottovalutata. Portare dentro anni di anagrafiche, storico ordini e documenti da un sistema che li ha organizzati a modo suo è lavoro vero, e va fatto prima che qualcuno inizi a usarlo davvero.

La formazione è la seconda: un gestionale su misura fa esattamente quello che serve, ma nessuno lo ha mai visto prima e non ci sono tutorial in giro.

L'evoluzione è la terza, e la metto sempre esplicita. Un gestionale non è finito il giorno della consegna: l'azienda cambia e il software la deve seguire. La differenza rispetto all'abbonamento è che qui decidi tu cosa cambiare e quando, invece di aspettare che finisca nella roadmap di qualcun altro.

La domanda da fare

Non è quanto costa. È: nei prossimi cinque anni, chi si adatta a chi.

Se la risposta è che ti adatti tu, e la cosa a cui ti adatti è proprio quella che sai fare meglio della concorrenza, allora il canone basso non è un risparmio.

Se invece i tuoi processi somigliano a quelli di tutti gli altri, il prodotto pronto è la scelta giusta e chi ti propone di costruire da zero ti sta facendo spendere di più per avere di meno. Quando ne parliamo per un gestionale su misura, la prima cosa che facciamo è capire in quale dei due casi sei, e succede spesso che la risposta sia la seconda.

Tre automazioni con l'AI che funzionano, e nessuna fa notizia

Dimitri — Thu, 27 Aug 2026 00:00:00 GMT

Le richieste che mi arrivano sull'AI somigliano quasi tutte alla stessa cosa: un assistente che parla con i clienti al posto di una persona. È la parte spettacolare, ed è anche quella che si rompe in pubblico. Nel frattempo, dentro le stesse aziende, ci sono tre o quattro lavori che qualcuno fa a mano ogni giorno da anni, e a quelli non pensa nessuno.

Sono lavori noiosi. Ed è esattamente per questo che si automatizzano bene.

Il criterio non è quanto è intelligente, è quanto è ripetitivo

Quando devo dire se ha senso automatizzare qualcosa uso tre condizioni, e sono banali: il lavoro è ripetitivo, è testuale, e il risultato è verificabile da chi lo riceve. Se manca la terza lascio perdere, perché un output che nessuno controlla è un errore che si accumula in silenzio.

Le tre cose che seguono passano tutte e tre le condizioni. Nessuna fa notizia.

1. Smistare quello che arriva

Ogni azienda ha un imbuto di richieste in ingresso: form del sito, caselle di posta condivise, messaggi che arrivano da tre canali diversi. Qualcuno li apre uno per uno, capisce di cosa si tratta, e li gira alla persona giusta. È un lavoro che non lascia traccia e si mangia le mattine.

Qui l'AI fa una cosa sola: legge il testo, capisce di che categoria è, e propone dove mandarlo. Un preventivo al commerciale, un problema tecnico all'assistenza, una candidatura in un'altra cartella.

La parte che conta è quella che si tiene. La classificazione è un suggerimento, non un ordine: il messaggio arriva alla persona con l'etichetta già messa, e se l'etichetta è sbagliata quella persona la cambia in un secondo. Non si perde niente, e si smette di leggere tutto per decidere cosa leggere.

2. Tirare i dati fuori dai documenti

Questa è la più concreta, e per me la più sottovalutata. Chi lavora con fornitori riceve documenti che contengono dati strutturati chiusi dentro un PDF: righe d'ordine, listini, schede tecniche, bolle. Per farli entrare in un gestionale qualcuno li ricopia.

Ricopiare a mano non è solo lento. È la fase dove nascono gli errori che si scoprono a valle, quando il numero sbagliato è già finito in fattura.

Un modello legge il documento e restituisce i campi in forma strutturata. La differenza rispetto ai vecchi sistemi di lettura automatica è che non serve una configurazione per ogni fornitore: il layout può cambiare, i dati si trovano comunque.

La condizione resta la terza. Il modo che funziona è una schermata di conferma dove i campi estratti stanno accanto al documento originale: chi conferma guarda, corregge se serve, e va avanti. È la stessa disciplina che serve costruendo un portale B2B, dove la validazione non è un dettaglio dell'interfaccia ma il punto in cui il dato diventa affidabile.

3. Scrivere le schede prodotto partendo dalle specifiche

Chi ha un catalogo grosso conosce il problema: ci sono le specifiche tecniche, complete e illeggibili, e servono le descrizioni. Nessuno le scrive tutte. Restano centinaia di prodotti con tre righe copiate dal fornitore, che è anche il motivo per cui non si posizionano.

Partire dalle specifiche cambia la natura del lavoro. Il modello non deve inventare: ha i dati, deve solo dirli in italiano leggibile e con lo stesso tono su tutto il catalogo. È generazione automatica su materiale vero, che non è la stessa cosa che scrivere articoli a vuoto.

Due avvertenze. Le descrizioni vanno riviste, e Google guarda proprio quella revisione: ne abbiamo scritto parlando di contenuti generati con l'AI. E va deciso prima cosa non deve entrare nel testo, perché un modello che trova un vuoto lo riempie, e su una scheda prodotto una certificazione inventata diventa un problema commerciale.

Il resto è lavoro umano

In tutti e tre i casi la parte automatizzata è la stessa: leggere, capire, riformulare. Quello che resta a una persona è il resto.

Decidere cosa fare di un caso strano. Rispondere a un cliente arrabbiato. Accorgersi che un documento è sbagliato all'origine e non nella lettura. Sapere che quel fornitore scrive le quantità in un'unità diversa da tutti gli altri.

E poi mantenerla. Un'automazione non è un progetto che finisce: cambia un formato, cambia un fornitore, e va rivista. Chi la mette in piedi senza mettere in piedi anche il modo di accorgersi che ha smesso di funzionare ha spostato il problema, non l'ha risolto.

Da dove si comincia

Non dal processo più costoso. Dal più noioso e meno rischioso, quello dove un errore si vede subito e non fa danni.

E va misurato prima quanto tempo ci vuole oggi, perché altrimenti dopo non c'è modo di sapere se è servito. Sui risparmi diffida delle percentuali che girano nei materiali commerciali: non dicono niente sul tuo caso. Preferisco non darti una cifra piuttosto che dartene una inventata.

La mia posizione è questa: l'AI conviene dove il lavoro è già scritto, già ripetitivo e già controllabile da qualcuno. La domanda giusta non è quale processo sia più importante, ma quale processo qualcuno sta già facendo a mano nello stesso modo ogni giorno. Se vuoi ragionarci, l'AI applicata è uno dei servizi di cui parliamo più volentieri, e la prima cosa che ti diciamo è quali dei tuoi processi non vale la pena toccare.

A cosa serve un sito web nel 2026, se hai già i social

Dimitri — Tue, 25 Aug 2026 00:00:00 GMT

Me lo chiedono quasi sempre a fine riunione, quando il grosso è già deciso: «ma secondo te il sito serve ancora? Tanto ormai i clienti ci scrivono su Instagram». È una domanda onesta. Il sito costa, va aggiornato, e intanto i contatti arrivano da altre parti. Capisco chi se la fa.

La risposta breve è sì. Quella lunga parte da una premessa che con la solita storia della vetrina non c'entra niente: il sito è l'unico pezzo della tua presenza online che possiedi davvero. Tutto il resto è in affitto.

Sui social sei in affitto

Un profilo social non è tuo. È un account su una piattaforma di qualcun altro, che decide quanto e a chi mostrare quello che pubblichi, con regole che cambiano senza preavviso.

Mi è capitato di lavorare con brand che avevano costruito quasi tutto su un canale solo. Poi l'algoritmo ha cambiato priorità, la copertura dei post è scesa e non c'era nessuno a cui chiedere spiegazioni. Nessun ban, niente di drammatico: solo la piattaforma che fa i suoi interessi, come è normale che sia. Il punto non è che le piattaforme siano cattive. Il punto è non avere un posto tuo quando succede.

C'è poi un limite più banale: sui social il formato lo decide la piattaforma. Un'azienda con tre linee di servizio, un e-commerce con cento prodotti, uno studio tecnico che deve documentare i progetti: niente di tutto questo sta comodo in un feed. Il feed è fatto per scorrere, non per approfondire.

ChatGPT non parla di te per sentito dire

Il paradosso è che proprio l'AI, quella che secondo alcuni rende i siti inutili, è il motivo più nuovo per averne uno. Quando qualcuno chiede a ChatGPT o a Perplexity «chi mi consigli per rifare il bagno a Modena», la risposta viene costruita a partire da contenuti pubblicati sul web aperto. Pagine, non profili: gran parte di quello che pubblichi sui social è chiuso dietro un login, o comunque poco leggibile per questi sistemi.

Se non hai un sito, per un assistente AI esisti solo attraverso quello che scrivono gli altri: una recensione, una directory, un articolo di terzi. Se ce l'hai, e le pagine sono strutturate bene, la fonte sei tu. È il lavoro che oggi chiamiamo GEO, l'ottimizzazione per le risposte generate, e per come lo vedo io è la continuazione naturale della SEO: stessa logica, un lettore in più.

L'unico posto dove decidi tu

Sul sito scegli tu cosa si vede per primo, come si racconta un progetto, quali domande anticipare, che tono usare. Sembra poco, ma prova a fare la stessa cosa su un profilo: il formato è quello, l'ordine è cronologico inverso e il post di ieri è già sepolto.

Mi è capitato di ereditare un progetto in cui il catalogo viveva nelle storie in evidenza di Instagram: per trovare un prezzo bisognava scorrerle tutte, e ogni variazione voleva dire rifare le grafiche. Quando abbiamo costruito il sito, metà del lavoro è stato semplicemente rimettere in una struttura navigabile contenuti che esistevano già. Non abbiamo scritto quasi niente di nuovo: gli abbiamo dato un indirizzo.

Una pagina fatta bene, poi, lavora per anni: continua a portare richieste mesi dopo la pubblicazione, senza che nessuno la rispolveri. Un post, dopo due giorni, ha finito il suo giro.

«Ma tanto i siti non li visita più nessuno»

Obiezione vera a metà. È vero che nessuno naviga più per svago tra siti aziendali, e che la scoperta ormai avviene altrove: sui social, su Google, sempre più spesso dentro una risposta generata. Ma tra scoprire e decidere c'è di mezzo un passaggio che facciamo tutti: andare a controllare.

Il sito nel 2026 non è il luogo della scoperta: è il luogo della verifica. Chi ti incrocia su Instagram o ti trova citato da un'AI poi ti cerca, e quello che trova in quei due minuti decide se il contatto parte o muore lì. Lo faccio anch'io, dall'altra parte del tavolo: prima di pagare un hosting o un servizio di terze parti vado a vedere chi c'è dietro, e se trovo un sito abbandonato chiudo la scheda.

Per questo un sito vecchio di otto anni, lento e con contenuti di un altro decennio, fa più danni di nessun sito: la verifica la fallisci proprio nel momento in cui qualcuno ti stava scegliendo.

Sito sì, ma non quel sito

Quindi no, secondo me il sito non è un investimento sprecato nemmeno nel 2026. Sprecato è il sito-brochure fatto una volta e mai più toccato: quello costa e non restituisce niente, e alimenta proprio la domanda da cui siamo partiti.

Il sito che ha senso oggi è un'altra cosa: la versione ufficiale della tua attività. Aggiornato, veloce, leggibile dalle persone e dalle macchine, collegato ai canali dove la gente ti scopre. I social ci portano dentro le persone, le AI lo leggono e ti citano, e tu resti proprietario di tutto quanto. È il criterio con cui progettiamo i siti in studio, ed è la domanda giusta da farsi prima di aprire il portafoglio: non «sito o social», ma «dove vive la versione della mia attività che controllo io?».

Vendere capi che esistono in un pezzo solo: il caso NNB Upcycling

Dimitri — Mon, 24 Aug 2026 00:00:00 GMT

NNB Upcycling System'18 fa una cosa che manda in crisi qualsiasi piattaforma e-commerce: ogni capo del catalogo è un pezzo unico. Nasce da abiti vintage italiani recuperati e rilavorati, quindi niente taglie multiple, niente riassortimenti, niente «torna disponibile». Quando si vende, la sua scheda ha finito di vivere. Noi dovevamo costruirci sopra un negozio online.

Questo è il racconto di come lo abbiamo fatto, delle scelte che rifarei e del punto in cui il progetto rischiava di incepparsi davvero. Che non era il codice.

Un catalogo dove ogni scheda vive una volta sola

Un e-commerce normale ragiona per modelli: una scheda prodotto, tre colori, cinque taglie, il magazzino che si ricarica. Qui il modello non esiste. Ogni capo è un prodotto nuovo, con le sue foto, le sue misure e la sua storia, e sparisce alla prima vendita.

La conseguenza pratica l'abbiamo capita presto: il punto fragile del progetto è chi carica i prodotti, non chi li compra. Se pubblicare un capo richiede mezz'ora e dieci campi da compilare, il catalogo muore prima del sito. Per questo abbiamo tenuto la struttura delle schede il più semplice possibile: il brand carica i capi nuovi da solo, senza passare da noi.

Sulla piattaforma lo dico da sviluppatore a cui piacciono gli stack moderni: WooCommerce non è la scelta che esalta chi scrive codice. Per questo caso però è quella onesta. Il brand ha bisogno di mettere online un capo appena finito di rilavorare, non di aprire un ticket ogni volta. Quando l'autonomia di chi gestisce il catalogo è il primo requisito, una piattaforma che il cliente sa usare da solo, e che non lo lega a noi, batte qualsiasi preferenza personale.

Il design deve sparire dietro ai capi

Con un brand di moda la tentazione è fare la cosa scenografica. Abbiamo fatto l'opposto: interfaccia essenziale, molto bianco, i capi come unico soggetto. Un pezzo unico non ha bisogno di una cornice che urla. Ha bisogno di spazio e di foto che si vedono bene.

La navigazione segue la stessa logica: pochi passaggi tra l'arrivo sul sito e il carrello. Un capo unico crea un tipo particolare di urgenza: chi lo vuole sa che non tornerà disponibile, e ogni schermata in più tra il desiderio e l'acquisto è un'occasione per ripensarci.

L'inglese e l'euro sono scelte di posizionamento

Il sito è in inglese e i prezzi sono in euro. Sembra un dettaglio tecnico. In realtà è la decisione più strategica del progetto: il pubblico che cerca moda upcycling non finisce ai confini dell'Italia, e un brand che vuole vendere in Europa deve presentarsi nella lingua di chi compra.

Sotto il cofano ci sono le cose che non si vedono ma decidono se il negozio si trova: meta title e descrizioni curati, dati strutturati sulle pagine, tracciamento e-commerce per capire da dove arrivano gli acquisti. Nessuna magia. Solo il lavoro di base fatto quando il sito nasce, invece che recuperato un anno dopo.

Il collo di bottiglia vero: i video dei prodotti

Per l'advertising e i social servivano video. E qui i capi unici presentano il conto: non puoi organizzare uno shooting per ogni giacca, e un video girato oggi promuove un capo che tra una settimana potrebbe non esserci più. Una produzione video tradizionale, su un catalogo di pezzi singoli, non sta in piedi.

Li abbiamo generati con l'AI, partendo dai capi reali. Il vincolo che ci siamo dati è uno solo, ed è quello che rende il lavoro difficile: il capo nel video deve essere identico al capo in vendita. Su un pezzo unico la fedeltà visiva è la scheda tecnica: se la cucitura nel video non è quella vera, stai mostrando un prodotto che non esiste.

Quindi ogni video passa un controllo a occhio: texture, cuciture, proporzioni, dettagli delle stampe. Quello che non regge il confronto con il capo vero si rigenera o si scarta. Qualche risultato lo trovi nella pagina del progetto, e il modo in cui affrontiamo questo tipo di lavoro è raccontato nella pagina dei contenuti AI.

Vale la pena dirlo, vista la diffidenza che c'è sul tema: qui l'AI non inventa capi che non esistono. Riproduce in movimento un prodotto reale, fotografato, in vendita. Per un catalogo di pezzi unici è l'unico modo sensato di avere video di prodotto senza moltiplicare i costi a ogni capo nuovo.

Cosa porterei via da questo progetto

Se stai pensando a un negozio online e il tuo prodotto ha qualcosa di fuori standard, capi unici, produzioni limitate, pezzi su misura, non partire dalla grafica. Parti dal processo: come nasce una scheda prodotto, chi la carica, cosa succede quando il pezzo si vende, con quali contenuti lo racconti. La grafica si sistema sempre. Un flusso di lavoro sbagliato te lo porti dietro per anni.

E il posizionamento si decide all'inizio. La lingua, la valuta, i mercati a cui parli sono scelte da fare prima di scrivere una riga di codice, perché cambiare idea a negozio avviato costa molto di più. Il nostro modo di impostare un progetto e-commerce parte esattamente da queste domande.

Contenuti scritti con l'AI: cosa penalizza Google davvero

Dimitri — Mon, 24 Aug 2026 00:00:00 GMT

Questo blog lo scrive in buona parte un'AI, e il flusso che lo produce l'ho costruito io. Quindi la domanda che mi fanno quando lo racconto («ma Google non vi penalizza?») me la sono già posta prima, con il sito dello studio in gioco. La risposta corta è no. Quella lunga spiega anche cosa conviene fare a te, con il tuo.

Cosa ha detto Google, senza interpretazioni

La posizione ufficiale è pubblica dall'inizio del 2023: Google premia i contenuti di qualità comunque siano prodotti. Non esiste una penalizzazione per l'uso dell'AI in sé. Quello che viene valutato è il risultato: la pagina risponde a una domanda reale? Dice qualcosa che le altre non dicono? Chi la firma sa di cosa parla?

Più interessante è quello che Google ha smesso di dire. Nelle linee guida sui contenuti utili la formula «scritti da persone, per le persone» è diventata «creati per le persone». La parte rimasta è quella che conta: lo strumento non è mai stato il punto, il destinatario sì.

La linea vera si chiama scaled content abuse

A marzo 2024 Google ha aggiornato le sue politiche antispam introducendo il concetto di scaled content abuse: produrre grandi quantità di pagine con lo scopo principale di posizionarsi, non di aiutare chi legge. La definizione è volutamente indifferente allo strumento. Vale per l'AI, per gli articoli pagati a peso, per i template che rigirano lo stesso testo su cento città.

Questo ribalta la domanda. Non «posso usare l'AI?» ma «questa pagina ha una ragione di esistere?». Le cento pagine «web agency + nome della città» erano spam dieci anni fa, quando le scriveva uno stagista, e restano spam oggi che le genera un modello in un pomeriggio. Un articolo che spiega bene una cosa vera, invece, non diventa spam perché l'ha impaginato una macchina.

Il rischio vero non è la penalizzazione

È l'irrilevanza. La maggior parte dei contenuti AI che vedo in giro non verrà mai penalizzata: semplicemente non si posizionerà, perché non aggiunge niente. Un modello linguistico lasciato solo produce il riassunto medio di quello che ha letto. Frasi corrette, generiche, che potrebbero stare su qualunque sito. Google non ha bisogno di punirle: gli basta preferire la pagina che porta qualcosa in più. Un caso reale, una misura fatta davvero, una posizione netta.

Il modo più concreto per stare sopra quella soglia è l'esperienza diretta. Le nostre regole di scrittura impongono episodi veri: un progetto ereditato, una misura fatta su un sito reale, un errore commesso in produzione. È la cosa che un modello non può inventare al posto tuo, ed è esattamente quella che manca al riassunto medio.

Poi ci sono i dati inventati. Quando un modello non conosce una cifra, spesso la produce lo stesso, con grande sicurezza. Un blog aziendale che cita numeri falsi danneggia la reputazione prima ancora del posizionamento.

Com'è fatto un flusso editoriale che regge

Il nostro, per come lo abbiamo messo in piedi:

Gli argomenti li sceglie una persona. C'è una coda editoriale dove ogni voce ha un angolo e una keyword decisi da chi il mestiere lo fa. L'AI non decide mai di cosa parlare.
Le regole di scrittura sono divieti, per iscritto. Nessuna statistica, percentuale o data che non sappiamo sostenere: se un numero servirebbe ma non c'è, la frase si riscrive senza. Niente aneddoti di fantasia, niente frasi riciclabili in un altro articolo.
Le verifiche stanno prima della pubblicazione. Link interni che puntano a pagine esistenti, cifre sostenibili, una rilettura a caccia di frasi che suonano finte. Dopo la pubblicazione non rilegge nessuno, quindi il controllo deve stare tutto lì.
Sopra ogni articolo c'è un nome. Se c'è scritta una cosa sbagliata, la figura la fa una persona dello studio, non «il sistema». La responsabilità è il correttore più efficace che conosco.

La parte che sorprende chi me lo chiede: scrivere le regole è costato più lavoro dei primi articoli. Il lavoro non sparisce, si sposta. Dalla scrittura alla direzione editoriale: scegliere cosa vale la pena dire, e impedire al sistema di dire sciocchezze.

Le domande da fare a chi ti vende contenuti

Se stai valutando un fornitore che ti propone articoli scritti con l'AI, le domande da fare sono queste: chi sceglie gli argomenti, e in base a cosa. Chi verifica i fatti prima che vadano online. Cosa succede quando il modello sbaglia. E diffida di chi vende volume: «trenta articoli al mese» senza un piano è la descrizione di uno scaled content abuse con la fattura.

Secondo me l'AI dentro un flusso editoriale è come un framework nello sviluppo: toglie il lavoro meccanico e amplifica quello che sai già. Se non hai niente da dire, ti aiuta a dirlo più in fretta e su più pagine, e Google se ne accorge. Se hai un punto di vista e regole serie, ti permette di pubblicare con costanza cose che stanno in piedi. È il criterio con cui costruiamo i flussi di contenuti AI per i clienti, ed è lo stesso che applichiamo quando facciamo SEO: prima la ragione di esistere della pagina, poi tutto il resto.

La pubblicità entra in ChatGPT, e il problema non sono gli annunci

Dimitri — Sun, 23 Aug 2026 00:00:00 GMT

Dal 24 agosto ChatGPT mostra pubblicità anche in Italia, insieme ad altri trenta mercati europei. Riguarda chi usa il piano gratuito e il piano Go; chi paga Plus, Pro o i piani aziendali non le vede.

La notizia in sé è poco sorprendente: un servizio con centinaia di milioni di utenti gratuiti da qualche parte i soldi li deve prendere. Quello che mi interessa è un'altra cosa, e non è tecnica.

Cosa cambia, secondo quello che dichiara OpenAI

Vale la pena separare i fatti dalle reazioni. Nella sua pagina di assistenza OpenAI scrive che:

gli annunci compaiono sotto la risposta, etichettati e visivamente separati dal testo;
girano su sistemi separati dal modello, e gli inserzionisti non possono modificare, riordinare o influenzare le risposte;
le conversazioni e i dati personali non vengono condivisi con gli inserzionisti;
non vengono mostrati ai minori di diciotto anni, né accanto a temi sensibili come salute, salute mentale e politica;
in Europa la pubblicità parte senza personalizzazione, a differenza degli Stati Uniti dove è attiva da febbraio.

Negli Stati Uniti la personalizzazione, quando l'utente la attiva, usa il tema della conversazione in corso più, opzionalmente, le chat passate, la memoria e le interazioni con gli annunci precedenti. In Europa questo pezzo per ora non c'è, e la ragione ha un nome: GDPR.

Sul lato inserzionisti, in Europa si parte attraverso le grandi agenzie e una piattaforma self-service è annunciata ma non ancora aperta. Quindi per ora non è una cosa che una PMI italiana può comprare da sola.

Una risposta contro dieci link

Qui sta la differenza che conta, e non riguarda la tecnologia ma la forma del prodotto.

Quando cerco su Google ricevo dieci risultati. I primi sono a pagamento e c'è scritto, gli altri no, e io scelgo. Posso scorrere, confrontare, ignorare i primi tre. La pubblicità occupa uno spazio dentro una lista, e una lista per sua natura mi lascia il confronto.

Un assistente non mi dà una lista. Mi dà una risposta. Se quella risposta consiglia un gestionale, io non vedo gli altri quattro che potevano andare bene: vedo quello. Anche con l'annuncio perfettamente separato sotto, il potere non sta nell'annuncio, sta nel fatto che sopra c'è una sola opzione e nessun modo di sapere cosa è stato scartato.

È un problema che esisteva già prima della pubblicità, per la verità. La pubblicità lo rende soltanto economicamente interessante.

Il problema non è la separazione, è che non possiamo verificarla

Prendo per buono che oggi i due sistemi siano separati. Non ho motivo di pensare il contrario e sarebbe una scelta suicida mentirci sopra.

Il punto è che nessuno, da fuori, può controllarlo. Con un motore di ricerca posso vedere l'etichetta "sponsorizzato" e confrontare con i risultati organici: la verifica è alla portata di chiunque. Con un assistente non esiste il risultato organico da confrontare. Esiste una frase, e la sua imparzialità è una promessa.

Non sto dicendo che la promessa sarà tradita. Sto dicendo che è una promessa e non un meccanismo, e che quando gli incentivi tirano da una parte per anni le promesse si logorano. Anche Google separava bene la pubblicità, all'inizio.

La parte buona, che esiste

Detesto i pezzi che vedono solo il lato brutto, quindi metto anche l'altro piatto sulla bilancia.

Un livello gratuito pagato dalla pubblicità è il motivo per cui uno studente, un artigiano o un'associazione senza budget hanno accesso allo stesso strumento che uso io. L'alternativa non è un ChatGPT gratuito e puro: è un ChatGPT solo a pagamento. Chi si indigna per gli annunci sta implicitamente proponendo di alzare un muro davanti a chi non può pagare venti euro al mese.

E la scelta di partire in Europa senza personalizzazione, per quanto imposta dalle regole, è la versione meno invasiva possibile: un annuncio legato all'argomento di cui stai parlando adesso, non al tuo profilo costruito in mesi di conversazioni.

Cosa cambia per chi ha un sito o un'azienda

Questa è la parte concreta, e secondo me è quella che passa più inosservata.

Da un paio d'anni si parla di ottimizzare i contenuti per farsi citare dalle risposte generate. È un lavoro che ha senso e che facciamo anche noi. Ma oggi arriva un dato nuovo: dentro quella risposta comincia a esserci spazio comprabile. Il che significa che essere la fonte migliore non sarà più l'unico modo per stare lì.

La conclusione che ne traggo non è "smettete di curare i contenuti". È che nessuna strategia di visibilità dovrebbe poggiare su un canale che non controlli. Vale per i social da dieci anni e ora vale anche per gli assistenti: il tuo sito, la tua lista di contatti e i clienti che ti cercano per nome restano le uniche cose che nessuno può riprezzare.

Più un bene o più un male

Più un male, ma non per il motivo che sento ripetere in giro. Non mi preoccupano gli annunci sotto la risposta: sono onesti, li riconosci, li ignori come ignori tutto il resto.

Mi preoccupa che stiamo spostando l'abitudine di miliardi di persone da "cerco e scelgo" a "chiedo e mi fido", e che stiamo aggiungendo un incentivo economico proprio nel momento in cui la fiducia diventa l'unico strumento di controllo che ci resta. La pubblicità dentro un motore di ricerca è un cartello sulla strada. Dentro un assistente assomiglia più a un consiglio di un amico che potrebbe essere pagato, e non c'è modo di chiederglielo.

Continuerò a usarlo, ovviamente, e continuerò a pagarlo. Che sia già una risposta.

Core Web Vitals: tre fastidi che hai già provato, misurati

Dimitri — Wed, 29 Jul 2026 00:00:00 GMT

I Core Web Vitals sono tre misure che Google usa per dire se una pagina è piacevole da usare. Detta così sembra una faccenda da tecnici. Nella pratica misurano tre fastidi che hai provato mille volte da utente.

Cosa misurano, senza sigle

LCP è quanto tempo passa prima che compaia la cosa grossa della pagina: l'immagine principale, il titolo. Non quando "inizia a caricare", quando si vede qualcosa di utile.
INP è quanto la pagina tarda a reagire quando tocchi qualcosa. È il bottone premuto due volte perché la prima sembrava non aver fatto niente.
CLS è quanto il contenuto si sposta sotto gli occhi mentre carica. È il link cliccato per sbaglio perché a metà tap è arrivato un banner e ha spinto tutto in basso.

Le tre insieme descrivono una cosa sola: quanto la pagina rispetta il tempo di chi la apre.

Che effetto hanno per davvero

Sul posizionamento sono un fattore, ma piccolo: un sito lento con contenuti giusti batte un sito velocissimo che non risponde alla domanda. Chi ti promette il primo posto sistemando i Web Vitals ti sta vendendo la parte facile.

Sul comportamento delle persone invece pesano molto, e non serve un grafico per capirlo. Una pagina che si muove sotto il dito e un bottone che non risponde sono i due motivi per cui si torna indietro senza nemmeno leggere.

Dove il conto si vede subito è la pubblicità. Se paghi per portare traffico su una pagina e quella pagina si apre in cinque secondi, stai pagando due volte: una il clic, una il fatto che una parte di quei clic se ne va prima di vedere l'offerta. È l'unico caso in cui la lentezza ha un prezzo che puoi leggere in una fattura.

Il punto pratico è questo: i Web Vitals non sono un esame da superare. Sono un modo di misurare un fastidio che altrimenti resterebbe una sensazione, e le sensazioni non si possono correggere.

Le cause che trovo quasi sempre

In ordine di frequenza, su siti aziendali italiani:

Immagini enormi servite piccole. Una foto da 4000 pixel dentro un riquadro da 400. È la causa numero uno di LCP alto e la più facile da togliere.
Script di terze parti. Analitiche, chat, mappe, pixel pubblicitari, cookie banner. Ognuno sembra innocuo e tutti insieme bloccano il browser proprio mentre l'utente prova a toccare qualcosa.
Niente spazio riservato per le immagini. Se il browser non sa quanto sarà alta una foto, la pagina salta quando arriva. Si risolve dichiarando le dimensioni, e costa dieci secondi.
Temi pesanti. Un tema comprato porta il codice di tutte le sue varianti, anche quelle che non usi.
Font caricati male. Il testo resta invisibile mentre il font scende, oppure cambia forma a metà lettura.

Nessuna di queste è una scelta consapevole di qualcuno. Sono cose che si accumulano, come le librerie di JavaScript.

Come guardarli senza illudersi

Esistono due tipi di numeri e vengono confusi in continuazione. Il test che lanci dal tuo computer misura una visita finta, in condizioni decise da te. I dati di campo misurano le visite vere, con i telefoni veri delle persone e la loro rete.

Il primo serve a capire cosa aggiustare. Il secondo è quello che conta. Un sito può passare il test in laboratorio e andare male in campo, e quando succede la colpa è quasi sempre di qualcosa che si carica solo nella vita reale: consensi, chat, contenuti personalizzati.

Il consiglio che dò sempre: prova il tuo sito col tuo telefono, in giro, non in ufficio col wi-fi. Ci vogliono due minuti e vale più di qualsiasi rapporto.

Da dove partirei, in questo ordine

Su un sito già in piedi, l'ordine conta più della lista, perché i primi due interventi si portano via la maggior parte del problema e costano poco:

Ridimensionare le immagini e servirle nei formati moderni. Nessuna modifica al design, nessun rischio, e di solito è qui che si recupera più tempo.
Fare l'inventario degli script di terze parti e togliere quelli che nessuno guarda più. Nei siti con qualche anno di vita ce n'è sempre almeno uno rimasto da una campagna finita.
Dichiarare le dimensioni di immagini e riquadri pubblicitari, così la pagina smette di saltare.
Solo dopo, se serve ancora, guardare il tema e il codice. È la parte che costa di più, e affrontarla per prima significa spesso pagare per risolvere un problema che era delle immagini.

Quello che sconsiglio è inseguire il punteggio. Da un certo punto in poi si spende molto per guadagnare qualche decina di millisecondi che nessun utente percepirà, mentre lo stesso tempo speso sui contenuti sposta davvero le visite.

La mia posizione

La velocità non è una funzione da aggiungere alla fine. È il risultato di quello che decidi di non mettere dentro.

Nei progetti dove seguiamo anche il posizionamento la prima cosa che guardiamo non è il punteggio, è l'elenco di cosa arriva al browser. Quasi sempre metà si può togliere senza che nessuno se ne accorga, e quella metà è il regalo più grande che puoi fare a chi visita il sito.

Cosa si rompe in un sito che nessuno tocca da tre anni

Dimitri — Sun, 12 Jul 2026 00:00:00 GMT

Un cliente mi ha girato gli accessi di un sito consegnato tre anni fa e mai più toccato. Dentro il pannello: decine di aggiornamenti in attesa, un tema abbandonato dal suo autore e un modulo di contatto che aveva smesso di inviare email chissà da quando. Nessuno se n'era accorto, perché nessuno lo apriva mai.

Non è un caso sfortunato: è la situazione più comune che trovo quando eredito un progetto. Il sito viene trattato come una brochure, si stampa una volta e poi vive di rendita. Solo che una brochure non ha dipendenze da aggiornare, non scade e non può essere bucata.

Un sito è software, e il software invecchia

Anche il sito vetrina più semplice poggia su una pila di componenti che non controlli: il linguaggio del server, il CMS, il tema, i plugin, le librerie del frontend. Ognuno di questi pezzi pubblica aggiornamenti, e ogni aggiornamento che salti allarga la distanza fra il tuo sito e il mondo che gli gira intorno.

Il problema non è quasi mai il singolo aggiornamento saltato: è l'accumulo. Aggiornare un plugin indietro di una versione richiede un clic. Aggiornarne venti fermi da tre anni, su una versione di PHP che l'hosting sta per dismettere, è un progetto a sé. Mi è capitato di metterci più tempo a rimettere in piedi un sito trascurato di quanto ne fosse servito per costruirlo.

Le cose che si rompono in silenzio

La parte insidiosa è che quasi niente si rompe con un errore a tutto schermo. Le rotture vere sono silenziose:

il modulo di contatto smette di inviare, il sito sembra vivo ma le richieste finiscono nel nulla; è il danno peggiore proprio perché non lo vedi;
il certificato SSL non si rinnova e il browser comincia ad avvisare i visitatori che il sito non è sicuro;
un servizio esterno cambia le sue API e la mappa, il feed dei prodotti o il sistema di prenotazione smettono di funzionare;
i backup automatici si fermano per mancanza di spazio, e nessuno lo scopre finché non servono.

Su quest'ultimo punto ho una regola semplice: un backup che non hai mai provato a ripristinare non è un backup, è una speranza. Il test di ripristino è la parte di manutenzione che nessuno vuole pagare e che un giorno vale da sola tutto il canone.

La sicurezza non funziona come nei film

Quando dico che un sito non aggiornato è un rischio, l'immagine che scatta in testa a molti clienti è l'hacker che sceglie proprio il loro sito come bersaglio. Non funziona così: non sceglie nessuno. Esistono bot che scandagliano la rete in automatico cercando versioni di plugin con vulnerabilità note, e quando ne trovano una entrano. Non gli interessa chi sei: gli serve il tuo server per mandare spam, ospitare pagine di phishing o reindirizzare i tuoi visitatori.

Non è nemmeno una questione di piattaforma. WordPress finisce spesso sul banco degli imputati perché è il più diffuso, quindi il più scandagliato, ma un progetto su misura con le dipendenze ferme da tre anni ha lo stesso identico problema.

Le conseguenze però le paghi tu: l'avviso di sito compromesso su Google, le email aziendali che finiscono in spam perché il dominio ha perso reputazione, il posizionamento costruito in anni che crolla. Ripulire un sito compromesso costa sempre più della manutenzione che l'avrebbe evitato, e una parte del danno, quella sulla reputazione del dominio, non si ripara con un intervento tecnico.

Il conto arriva tutto insieme

La manutenzione saltata è un debito che matura interessi. Per mesi non succede niente e sembra di aver avuto ragione. Poi un aggiornamento obbligato dell'hosting, un plugin abbandonato dal suo autore o una compromissione presentano il conto di tre anni in una volta sola. A quel punto le opzioni rimaste sono due: un intervento d'urgenza costoso o il rifacimento.

Il paradosso è che spesso il rifacimento si fa, si paga, e il sito nuovo riparte esattamente come il precedente: senza nessuno che se ne occupi. Il ciclo ricomincia da capo, solo con un preventivo in più nel cassetto.

Cosa deve esserci in una manutenzione fatta bene

Non serve un contratto da multinazionale. Per la maggior parte dei siti aziendali una manutenzione seria contiene poche cose, fatte con regolarità:

aggiornamenti di CMS, tema, plugin e dipendenze, provati in un ambiente di test quando toccano pezzi delicati;
backup automatici conservati fuori dal server del sito, con un test di ripristino ogni tanto;
monitoraggio di uptime, scadenze di dominio e certificato, errori nei moduli;
un giro a mano periodico sulle pagine che contano: la home, il modulo di contatto, il checkout se c'è.

C'è poi una scelta a monte che cambia il peso di tutto questo. Una parte del nostro lavoro di sviluppo web va verso i siti statici anche per questa ragione: meno componenti in esecuzione sul server vuol dire meno superficie da difendere e meno cose che possono rompersi da sole. La manutenzione non sparisce, ma si riduce a una frazione.

Se stai per commissionare un sito, la domanda giusta non è quanto costa farlo. È chi se ne occupa dopo, e a quali condizioni. Un sito senza manutenzione non resta com'era il giorno della consegna: peggiora ogni mese, in silenzio. E il silenzio, qui, è la parte più cara.

WordPress, headless o statico: chi ci metterà mano dopo?

Dimitri — Sun, 05 Apr 2026 00:00:00 GMT

La domanda arriva sempre nella stessa forma: "meglio WordPress o qualcosa di più moderno?". È la domanda sbagliata, perché mette in fila una piattaforma e un aggettivo.

Le scelte vere sono tre, e si distinguono per una cosa sola: dove sta il lavoro che qualcuno dovrà fare dopo il lancio.

I tre modelli, in una riga ciascuno

WordPress. Contenuti, pagine e sito vivono nello stesso programma, su un server che esegue PHP. Cambi una cosa nell'amministrazione e la vedi online subito.
Headless. I contenuti stanno in un servizio a parte con la sua interfaccia di redazione, e il sito li legge da un'API. Chi scrive e chi sviluppa lavorano su due cose separate.
Sito statico. Le pagine vengono costruite una volta in fase di rilascio e servite come file già pronti. Non c'è nessun programma in esecuzione quando qualcuno apre il sito.

Le ultime due si combinano, ed è la strada che uso più spesso: contenuti in un CMS headless, pagine generate staticamente. Questo blog è fatto così, e ne parlo sapendo anche cosa mi costa.

La manutenzione è la voce che decide

Un sito WordPress ha tre cose da aggiornare: il core, il tema e i plugin. Nessuna delle tre è opzionale, e ognuna può rompere le altre. Il conto non arriva il primo mese, arriva al secondo anno.

Su un sito statico non c'è niente in esecuzione da aggiornare sul server. Le dipendenze da tenere aggiornate ci sono comunque, ma stanno nel codice e le tocchi quando pubblichi, non mentre il sito è online.

Questa è la differenza che vedo pesare più di tutte quando eredito un progetto. Un WordPress lasciato fermo tre anni è un lavoro di recupero. Un sito statico lasciato fermo tre anni è semplicemente un sito vecchio, che però funziona ancora.

Sicurezza: quello che non esiste non si può bucare

La maggior parte dei siti compromessi che mi è passata davanti non era stata attaccata da nessuno in particolare. Era un plugin vecchio trovato da uno script automatico che gira su tutto internet.

Con un sito statico quella superficie non c'è: nessun database da interrogare, nessun codice che gira a ogni visita, nessuna pagina di accesso da indovinare. Non significa essere invulnerabili, significa avere meno cose che possono andare storte.

Velocità: uno parte veloce, l'altro lo diventa

Un sito statico è veloce per costruzione: i file sono già pronti e arrivano da una rete di distribuzione vicina a chi li chiede. Non è merito di nessuno, è la conseguenza di come funziona.

WordPress può diventare veloce, e alcuni siti WordPress sono molto veloci. Ma è un risultato che si ottiene aggiungendo strati: cache, ottimizzazione delle immagini, riduzione degli script dei plugin. Ogni strato è una cosa in più che può smettere di funzionare.

Autonomia della redazione, che è il punto dolente

Qui WordPress ha un vantaggio che nessuno racconta abbastanza: chi ci ha già lavorato lo sa usare, e può costruirsi una pagina nuova da solo, anche sbagliando.

Con headless più statico l'editor è più pulito e non si può fare disordine, perché la struttura delle pagine la decide chi sviluppa. Il rovescio è che una pagina di un tipo nuovo richiede una modifica al codice. Va detto prima, non scoperto dopo.

C'è anche un dettaglio pratico che sorprende sempre: su un sito statico la pubblicazione non è istantanea, perché il sito va ricostruito. Sono minuti, non ore, ma se pubblichi dieci notizie al giorno è una frizione reale.

I costi ricorrenti non si assomigliano

WordPress costa hosting, e un hosting che regge PHP e database costa più di uno che serve file. Poi costano le licenze dei plugin professionali, che si rinnovano ogni anno, e costa il tempo di chi aggiorna.

Headless costa un abbonamento al servizio dei contenuti, e va guardato con attenzione perché i prezzi crescono a scaglioni: il salto di piano arriva quando aumentano gli utenti della redazione o le chiamate all'API, non quando aumentano le visite. La parte statica invece costa quasi niente da servire.

Detto in soldi: il primo modello ha una spesa piccola e continua più il rischio di una spesa grossa e improvvisa quando qualcosa si rompe. Il secondo ha una spesa fissa più alta e prevedibile. Quale conviene dipende da quanto vale la prevedibilità per te.

Quando scelgo cosa

WordPress resta la scelta giusta quando la redazione pubblica tanto e vuole autonomia totale sulla forma delle pagine, quando il team lo conosce già, o quando serve una funzione che nel suo ecosistema esiste pronta e altrove va scritta da zero: prenotazioni, aree riservate, corsi.

Headless più statico conviene quando il sito è soprattutto presentazione, quando le performance contano per il posizionamento, quando nessuno in azienda ha il tempo di fare manutenzione, e quando le pagine sono molte ma di pochi tipi ripetuti.

Il campanello d'allarme, in un preventivo di sviluppo web, è quando la piattaforma viene proposta prima di aver chiesto chi pubblicherà i contenuti e quanto spesso. Quella risposta viene prima della tecnologia.

La mia posizione

Non esiste la scelta moderna e quella superata. Esiste chi si prende in carico la manutenzione e chi si illude che non serva.

Se la risposta è "nessuno ci metterà mano per due anni", allora la piattaforma con meno pezzi in movimento è quella giusta, qualunque sia la moda del momento.

JavaScript è nato in dieci giorni e non ce lo togliamo più

Dimitri — Mon, 02 Mar 2026 00:00:00 GMT

Ogni volta che apro un progetto ereditato da qualcun altro, prima o poi trovo un == dove doveva esserci un ===. Il bug che ne esce è sempre lo stesso tipo di bug, e ha la stessa età del linguaggio.

Quel doppio uguale non è lì per pigrizia di qualcuno. È lì perché toglierlo romperebbe pagine che nessuno può più ricompilare. Ed è la stessa ragione per cui JavaScript, messo insieme in dieci giorni nel 1995, è ancora l'unico linguaggio che il browser esegue davvero.

Dieci giorni, e un nome scelto dal marketing

Brendan Eich lo scrive in Netscape nel 1995. Il primo prototipo nasce in circa dieci giorni, e non doveva servire a costruire applicazioni: doveva far muovere qualcosa dentro una pagina. Validare un campo, aprire un menu. Nient'altro.

Si chiamava Mocha, poi LiveScript, poi JavaScript. L'ultimo nome è una scelta commerciale per agganciarsi a Java, che in quel momento andava forte e con cui non c'entra niente. È il primo pasticcio del linguaggio, e trent'anni dopo mi tocca ancora spiegare a qualcuno che sono due cose diverse.

I difetti non sono stati corretti, e non è una dimenticanza

Alcune cose che JavaScript fa ancora oggi, esattamente come le faceva allora:

typeof null      // 'object'
0.1 + 0.2        // 0.30000000000000004
[] == false      // true
'5' - 2          // 3
'5' + 2          // '52'

Sui decimali è onesto dire che non è colpa sua: quello è lo standard IEEE 754 e lo fanno quasi tutti i linguaggi. Gli altri invece sono roba sua. typeof null che risponde "object" è un bug del 1995, riconosciuto come tale, mai sistemato.

Il motivo si riassume in una frase che in TC39, il comitato che decide lo standard, vale più di qualsiasi eleganza: non rompere il web. Se domani typeof null iniziasse a rispondere correttamente, da qualche parte si spegnerebbe un modulo scritto nel 2004 che nessuno mantiene più e che però serve a qualcuno. Il web non ha un deploy: non puoi ricompilare tutte le pagine che esistono.

Questa è la parte che trovo interessante. I difetti di JavaScript non sono il prezzo della fretta del 1995. Sono il prezzo di una promessa mantenuta per trent'anni.

Hanno provato tutti a sostituirlo

E non sono stati tentativi timidi:

VBScript di Microsoft, che funzionava solo in Internet Explorer.
Gli applet Java, morti di lentezza e problemi di sicurezza.
Flash, che per anni ha fatto girare mezzo web e ha chiuso definitivamente nel 2020.
Dart, per cui Google voleva mettere una macchina virtuale dentro Chrome, e ha rinunciato: oggi Dart compila in JavaScript.

Il caso più istruttivo è TypeScript, perché ha vinto. Solo che non sostituisce JavaScript: ci compila dentro. Anche WebAssembly, che è veloce e serio, non lo tocca il DOM: per muovere un pixel deve comunque chiamare JavaScript. È un compagno, non un erede.

Il 2015 è l'anno in cui è diventato un linguaggio serio

ES2015 porta let e const, i moduli, le classi, le promise, le arrow function. Da lì in poi c'è un rilascio all'anno e un processo a stadi per proporre modifiche. Prima si scriveva JavaScript nonostante il linguaggio, con librerie che tappavano i buchi; da lì si è cominciato a scriverlo con il linguaggio.

In mezzo, nel 2009, era già arrivato Node: lo stesso linguaggio anche sul server. Il che è comodo e allo stesso tempo è la porta da cui è entrato il problema di oggi, che non è più la sintassi ma la quantità.

Cosa c'entra questo con il tuo sito

Se stai facendo fare un sito, questa storia ti riguarda in tre punti concreti.

Il primo: tutto quello che si muove in una pagina passa da JavaScript. Non è una preferenza di chi lo sviluppa, è l'unico linguaggio che il browser sa eseguire. Chiedere "si può fare senza JavaScript" quasi mai ha senso; chiedere "quanto ne arriva all'utente" ha molto senso.

Il secondo: la retrocompatibilità che tiene in vita typeof null è la stessa che permette al sito di un'azienda di aprirsi ancora dieci anni dopo. È una garanzia che nessun'altra piattaforma ti dà.

Il terzo, ed è quello che vedo sbagliare più spesso: siccome aggiungere una libreria costa un comando, se ne aggiungono troppe. Ogni libreria è peso che l'utente scarica, e quel costo non lo paga chi sviluppa dal suo portatile — lo paga chi apre il sito in 4G mentre cammina. Quando facciamo un progetto di sviluppo web è la prima voce che guardiamo: quanto JavaScript arriva davvero al browser, e cosa si vede se non arriva.

La mia posizione

JavaScript non lo difendo perché è elegante, perché non lo è. Lo difendo perché è l'unico pezzo grosso di infrastruttura che ha deciso di non rompere niente, e ha tenuto la parola. Il conto di quella scelta lo paghiamo in bug del 1995 che ci portiamo dietro per sempre.

Mi sembra un affare. Un linguaggio progettato meglio, in dieci giorni, non lo avremmo avuto comunque. Un web in cui le pagine vecchie si aprono ancora, invece, ce lo siamo tenuto.