DEV Community: Dimitri Sohonov

Bloccare i bot AI sul sito conviene? Dipende da quale dei tre, e Cloudflare ha già scelto per i domini nuovi

Dimitri Sohonov — Tue, 13 Oct 2026 00:00:00 +0000

Per un sito aziendale che non vive di pubblicità la risposta è no: lascia passare Search e Agent, e decidi solo sul Training. Bloccare tutto con un interruttore unico è il modo più rapido per sparire dalle risposte di ChatGPT proprio nel momento in cui un potenziale cliente chiede di te.

Ne scrivo adesso perché Cloudflare, dal 15 settembre 2026, questa scelta la fa da sola per i domini nuovi. Se il sito mostra annunci, il preset disattiva il Training e blocca gli agenti sulle pagine con pubblicità. Se non li mostra, lascia passare tutto. Chi ha collegato un dominio dopo quella data ha già una configurazione attiva, e nella maggior parte dei casi non l'ha mai aperta.

I bot AI non sono una cosa sola: Cloudflare li divide in tre

Dal 1° luglio 2026 Cloudflare classifica i crawler per quello che fanno con il contenuto, non per chi li manda. Le categorie sono tre, e la domanda del titolo ha una risposta diversa per ognuna.

Search : raccoglie e indicizza le pagine per rispondere a domande più avanti. È il crawler di un motore di ricerca, classico o generativo, e in cambio ti manda traffico.
Agent : agisce per conto di una persona, di solito in tempo reale. Qui dentro ci sono le letture di ChatGPT quando un utente chiede qualcosa e il modello va a prendersi la pagina in quel momento, e gli agenti che navigano un browser al posto tuo.
Training : prende il contenuto per addestrare o affinare un modello. Una volta assorbito, resta dentro il modello e non torna indietro.

La distinzione è la parte utile di tutta la faccenda. Il vecchio interruttore «Block AI Bots» trattava queste tre cose come una sola, e chi lo accendeva per tenersi lontano il Training si tagliava fuori anche dal resto.

Bloccare Agent vuol dire sparire dalle risposte di ChatGPT

È il punto che trovo più sottovalutato. Quando qualcuno chiede a ChatGPT «chi fa configuratori di prodotto in Emilia» o «questa azienda è affidabile», il modello spesso non risponde a memoria: va a leggere le pagine mentre scrive. Quella lettura è un Agent. Se il sito la blocca, il modello si arrangia con quello che trova altrove: la scheda di un portale, una recensione vecchia, il sito del concorrente che invece lascia passare.

Il paradosso è un'azienda che investe per farsi trovare dall'AI e poi blocca il bot che dovrebbe leggerla. Succede per inerzia, non per scelta: un pulsante che dice «blocca i bot AI» suona come sicurezza, e la mano va lì.

Se vuoi comparire nelle risposte generate, questa riga resta aperta. Ho già scritto come si scrive una pagina perché venga citata da ChatGPT e da AI Overview: niente di quello funziona se il bot non entra.

Search non si tocca, e nemmeno Cloudflare lo tocca

Nessuno dei due preset agisce su Search: resta su Allow sia con la pubblicità sia senza. È coerente con il patto di sempre: il crawler indicizza, tu ricevi visite. Qui non c'è nulla da decidere, e se trovi Search bloccato su una zona è un errore, non una strategia.

Training è l'unica scelta vera, e dipende da cosa vendi

Il Training è l'unica categoria su cui ha senso ragionare. Un editore, un blog con annunci, chiunque viva del testo che pubblica ha un motivo concreto per chiuderlo: il modello assorbe l'articolo e lo restituisce senza mandare nessuno sulla pagina. Un'azienda che vende un servizio o un prodotto ha l'interesse opposto: vuole che il modello sappia chi è, cosa fa e dove.

Il criterio che uso è questo: se il contenuto è il prodotto, chiudi. Se il contenuto serve a vendere un'altra cosa, lascia passare. In mezzo ci sono i casi da discutere, ma sono meno di quanto sembra.

C'è poi una sottigliezza che può costare cara. Le opzioni per il Training sono due e non fanno la stessa cosa. «Disallow AI Training» esprime la preferenza nel robots.txt, e i crawler misti come Googlebot, Applebot e Bingbot continuano a indicizzare. «Block» invece ferma tutti i crawler che fanno training, compresi quelli misti: Googlebot incluso. Il preset di Cloudflare usa il primo, per fortuna. Chi sceglie il secondo a mano per sentirsi più protetto rischia di uscire da Google per tenere fuori un modello.

Un'ultima nota su Bing: Microsoft recepirà la preferenza di non addestramento dal robots.txt solo da inizio 2027. Fino ad allora «Disallow AI Training» non arriva a Bing per quella via.

Dove sta il pannello e cosa controllare

Le tre righe stanno nelle impostazioni di sicurezza della zona, cioè del dominio, e valgono su tutti i piani, Free compreso. Per un sito aziendale senza pubblicità il risultato da leggere è: Search su Allow, Agent su Allow, Training deciso da te.

Le configurazioni precedenti sono state migrate in automatico. Chi aveva il vecchio «Block AI Bots» acceso si ritrova con la traduzione di quella scelta, e chi usava già i controlli separati ne conserva l'effetto. Tradotto: il pannello non va dato per buono, va aperto e letto. Due minuti per zona.

Un controllo rapido dall'esterno è leggere il robots.txt del sito, perché è lì che finisce la preferenza sul Training:

curl https://www.tuodominio.it/robots.txt

Se il sito non sta dietro Cloudflare, la logica è la stessa ma le regole le scrivi a mano. OpenAI, per dire, usa tre user agent diversi per le tre funzioni: GPTBot per il training, ChatGPT-User per le letture su richiesta, OAI-SearchBot per la ricerca. Bloccarli tutti con una riga sola riproduce esattamente l'errore del vecchio interruttore.

Cosa chiedere a chi ti gestisce il sito

Se il sito non lo gestisci tu, le domande da fare sono tre, e la risposta dovrebbe arrivare in giornata, non in una riunione:

Il dominio sta dietro Cloudflare? Se sì, com'è impostata la riga Agent?
Il Training è su Disallow o su Block? Se è su Block, per quale motivo?
Il robots.txt dice le stesse cose del pannello?

La mia posizione è questa: per quasi tutte le aziende che seguiamo, farsi leggere dall'AI vale più del fastidio di finire dentro un modello. Chi chiude tutto per principio protegge un contenuto che, nella maggior parte dei casi, era stato scritto per farsi trovare. Il blocco ha senso quando il testo è ciò che vendi. Se invece lavori per farti trovare dai motori classici e da quelli generativi, è la stessa partita, e si gioca con la porta aperta.

Supplier unit Google: l'hotel compare senza passare da un portale? Sì, ma solo se il sito regge da solo

Dimitri Sohonov — Sat, 10 Oct 2026 00:00:00 +0000

Dall'8 settembre 2026 Google documenta un blocco nuovo nei risultati per chi cerca dall'Europa. Accanto a quello dei portali di confronto, che Google chiama aggregator unit, ce n'è uno per i fornitori diretti: la supplier unit. Il singolo hotel, il negozio con la vetrina, l'idraulico. L'esempio dell'idraulico non è mio, sta nella pagina di Google.

Sì, un hotel può comparire lì senza passare da un portale. Non c'è un modulo da compilare e non c'è un feed obbligatorio : Google scrive che non serve fornire dati oltre a quelli che il suo crawler legge dal sito. Il che sposta tutta la partita su una domanda sola: quando Googlebot apre la tua pagina camere, cosa trova?

La supplier unit è il blocco dei fornitori diretti, e compare solo accanto a quello dei portali

Il blocco nasce dal Digital Markets Act. Google sta cambiando la pagina dei risultati per dare spazio ai servizi di ricerca verticale, cioè ai portali di confronto, e lo scrive così nella sua documentazione. La risposta è stata l'aggregator unit, e accanto ci ha messo la supplier unit per chi vende direttamente. Le due unità vanno in coppia: la pagina dice chiaro che quella dei fornitori compare solo se compare quella dei portali.

Vale per chi cerca dallo Spazio economico europeo e per cinque tipi di ricerca: hotel, voli, treni e autobus a lunga percorrenza, prodotti e attività locali. L'ultima voce è quella che allarga il discorso oltre il turismo: dal 18 settembre la documentazione la elenca accanto alle altre, e un negozio o uno studio con una sede fisica sta dentro quel perimetro quanto un albergo.

I requisiti che Google scrive sono due, e sono quasi nulli: il sito deve servire utenti nel SEE, e l'attività deve essere un fornitore diretto. Tutto il resto, cioè chi compare e in che ordine, non è scritto da nessuna parte.

Non serve iscriversi, e proprio per questo conta cosa c'è nell'HTML

Per l'aggregator unit un portale deve farsi approvare e mandare feed o collegarsi via API. Per la supplier unit no: la frase di Google è che non serve fornire dati aggiuntivi oltre a quelli accessibili tramite la scansione del web, e i feed sono citati come un modo per arricchire i risultati, non come condizione.

Sembra una buona notizia, ed è anche una trappola. Senza un feed, l'unica cosa che Google sa di te è quello che legge dalle tue pagine. E qui parlo di un problema che ho visto da dentro: mi è capitato di ereditare siti di strutture ricettive dove prezzi e disponibilità vivevano solo dentro il motore di prenotazione, caricato da un dominio esterno in una finestra incorporata. Per un visitatore la pagina sembrava completa. Per il crawler era una foto, una frase di benvenuto e un bottone. Di quello che c'era da vendere, niente.

Se Google deve decidere chi è un fornitore diretto con un'offerta leggibile, quel sito non lo è. Non per una penalizzazione: perché non c'è niente da leggere.

Cosa deve avere il sito perché Google ci trovi un'offerta

Sono le cose che controllo per prime quando metto mano a un sito di questo tipo, e nessuna richiede di rifarlo.

Prezzi e disponibilità scritti nella pagina. Se il motore di prenotazione è esterno, almeno le tipologie di camera, il prezzo di partenza e i periodi vanno nell'HTML servito dal tuo dominio, non solo nel widget. Lo stesso vale per un listino di servizi o per i prodotti di un negozio.
Una pagina per struttura, o per sede. Due hotel dello stesso gruppo sulla stessa pagina sono, per Google, un fornitore e mezzo. Tre sedi di un negozio su una pagina «dove siamo» sono tre attività locali che non esistono.
Dati strutturati di tipo Hotel o LocalBusiness con nome, indirizzo, telefono, orari e, dove ha senso, l'offerta. Qui devo essere preciso: la pagina della supplier unit non li nomina come requisito. Li richiede un'altra funzione, i caroselli strutturati, e in generale sono il modo più pulito per dire al crawler chi sei. A chi ha in mano il template costano un'ora.
Nome, indirizzo e telefono scritti come sul profilo Google Business. Sembra banale, e in molti siti che vedo la ragione sociale sul sito e il nome sulla scheda sono due cose diverse.
Contenuto che esiste senza interazione. Un prezzo che compare solo dopo aver scelto le date in un calendario è un prezzo che il crawler non vede.

Quello che Google non dice: come sceglie chi compare

La pagina non lo spiega, e non te lo dirò neanche io. Chi afferma di sapere cosa serve per entrare nella supplier unit sta vendendo qualcosa: la documentazione dice chi è idoneo, non chi viene scelto.

Quello che si può dire con onestà è che il crawler è lo stesso di sempre e l'indice è lo stesso di sempre. Un sito che si apre in fretta, che ha una pagina per ogni cosa cercata invece di una pagina per tutto, che non è una copia della scheda sul portale, parte avvantaggiato per le stesse ragioni per cui parte avvantaggiato nei risultati normali. Se vuoi un posto da cui cominciare, è il lavoro che facciamo nel servizio SEO e GEO: rendere il sito leggibile da una macchina prima ancora che da una persona.

E ricorda il vincolo di coppia: il blocco dei fornitori compare solo quando compare quello dei portali. Non controlli quando succede, e non ha senso misurare il risultato contando quante volte ti vedi.

Cosa cambia per chi ha un hotel o un negozio, in pratica

Non è il momento di togliere il portale: la supplier unit compare accanto all'aggregator unit, non al suo posto, e il portale resta quello che è oggi. È il momento di controllare se il tuo sito è un sito o una brochure attorno a un widget. Le domande da fare sono tre:

Aprendo il sorgente della pagina camere, o del listino, il prezzo c'è scritto?
Ogni struttura, o ogni sede, ha un suo indirizzo web?
Nome, indirizzo e telefono sono gli stessi, carattere per carattere, del profilo Google Business?

Se le risposte sono tre sì, non devi fare niente: aspetti e guardi. Se sono tre no, il problema non è la supplier unit: è che il tuo sito oggi non dice a nessuno, nemmeno a Google, cosa vendi. Sistemarlo è lavoro di sviluppo web ordinario, non una campagna.

La mia posizione è che questo blocco è la prima volta in cui Google, per regola e non per cortesia, mette il fornitore diretto nello stesso spazio del portale. Ne beneficia chi aveva già un sito che regge da solo. Chi ha delegato tutto al motore di prenotazione scopre adesso che Google non aveva niente da leggere. Non è una ragione per rifare il sito. È una ragione per aprire il sorgente della pagina camere e guardare cosa c'è.

Come funziona l'intelligenza artificiale? Indovina la parola dopo, e tutto il resto è costruito intorno

Dimitri Sohonov — Thu, 08 Oct 2026 00:00:00 +0000

Un modello come quello dietro ChatGPT fa una cosa sola: dato un testo, calcola quale pezzo di parola ha più probabilità di venire dopo, lo aggiunge, e ricomincia. Tutto il resto, la chat, le ricerche sul web, il codice che scrive, i task che sembra eseguire, è costruito intorno a questo meccanismo da programmi normali, spesso scritti da gente come me.

Lo dico subito perché è la cosa che spiego più spesso ai clienti quando integro un modello in un prodotto, ed è quella che cambia di più le aspettative. Non c'è una mente che capisce la richiesta e poi decide. C'è una funzione enorme che continua il testo, e un sistema attorno che prende quel testo e lo trasforma in azioni.

testo = richiesta
finché il modello non scrive il segnale di fine:
    probabilità = modello(testo) # una probabilità per ogni token possibile
    token = scegli(probabilità) # con un po' di caso: è la "temperatura"
    testo = testo + token

Ogni parola che leggi in una risposta è passata di lì.

Da dove viene: reti neurali vecchie, un'idea del 2017 e una quantità enorme di testo

Le reti neurali esistono da decenni: funzioni con milioni, oggi miliardi, di numeri regolabili, i parametri , che si aggiustano a forza di esempi. Per anni hanno funzionato bene sulle immagini e male sul linguaggio, perché una frase ha dipendenze a distanza: il soggetto all'inizio decide il verbo alla fine.

La svolta è un'architettura del 2017 chiamata transformer. Il meccanismo centrale si chiama attenzione: per ogni pezzo di testo, il modello calcola quanto deve guardare ciascuno degli altri pezzi. Il pronome guarda il nome a cui si riferisce, il verbo guarda il soggetto. Nessuno glielo programma: lo impara.

L'addestramento è brutale nella sua semplicità. Si prende una quantità enorme di testo, si nasconde la parola successiva, si chiede al modello di indovinarla e si correggono i parametri in base all'errore. Miliardi di volte. Alla fine, per indovinare bene la parola dopo, il modello ha dovuto imparare grammatica, fatti, stile, un po' di logica. Non perché qualcuno glieli abbia insegnati: perché servivano a sbagliare meno.

Il modello base che esce da lì completa testo e basta. Per farlo rispondere come un assistente c'è una seconda fase, molto più corta, in cui gli si mostrano esempi di domanda e risposta e si premiano le risposte che le persone preferiscono. È lì che nasce la forma chat.

La tua richiesta entra come numeri, non come parole

Quando scrivi «riassumi questa mail», il testo viene spezzato in token : frammenti di parola, a volte una parola intera, a volte una sillaba o un segno di punteggiatura. Ogni token diventa una lista di numeri, e da quel momento il modello lavora solo su numeri.

Per questo alcune cose che a noi sembrano banali per lui sono difficili. Contare le lettere di una parola, per esempio: il modello non vede le lettere, vede i token. E per questo la lunghezza di quello che gli dai ha un costo: più token in ingresso, più calcolo. Chi integra un modello paga a token, non a richiesta, ed è la prima voce che finisce nel preventivo di un progetto con l'AI dentro.

Il modello non esegue nessun task: scrive, e un programma attorno agisce

Questa è la parte che chi non sviluppa fraintende di più, e la capisco: quando un assistente cerca sul web o manda una mail sembra che lo faccia lui. Non lo fa. Il modello scrive un pezzo di testo in un formato concordato, qualcosa come «chiama la funzione cerca con la parola X», e si ferma. Il programma intorno, scritto da uno sviluppatore, legge quel testo, esegue davvero la ricerca, e rimette il risultato dentro la conversazione. Poi il modello continua a scrivere.

Si chiama tool calling , ed è il motivo per cui quando lavoro su un'integrazione passo più tempo sul codice attorno che sul modello. Decidere quali strumenti dargli, come descriverglieli, cosa fare quando chiede una cosa che non esiste, come fermarlo se gira a vuoto: quello è il lavoro. Il modello è il pezzo più intelligente del sistema, e anche il meno controllabile.

Un agente è esattamente questo ciclo ripetuto: il modello scrive, il programma esegue, il risultato torna al modello, finché il modello scrive «ho finito». Niente di magico, e molto da progettare.

Non sa niente della tua azienda finché non glielo metti davanti

Il modello ha in memoria quello che ha letto in addestramento, compresso nei parametri, e nient'altro. Dei tuoi prezzi, delle tue procedure, dei tuoi ordini non sa nulla. Caricarglieli una volta per tutte vorrebbe dire riaddestrarlo, e quasi nessuno lo fa.

Quello che si fa è metterglieli davanti ogni volta: la domanda dell'utente arriva insieme ai documenti pertinenti, pescati da un archivio con una ricerca normale, e il modello risponde leggendo quelli. Si chiama RAG , retrieval augmented generation, e nella pratica il risultato dipende più dalla qualità dell'archivio e della ricerca che dal modello. Un chatbot aziendale che risponde male di solito ha un problema di documenti, non di intelligenza.

Lo spazio in cui il modello legge, la finestra di contesto , è limitato. E quello che c'è dentro sparisce a fine conversazione: la memoria degli assistenti è un altro programma attorno che salva e rimette.

Perché sbaglia con tanta sicurezza

Perché il suo lavoro è continuare un testo in modo plausibile. Se gli chiedi la sentenza che ha deciso un certo caso, produce la continuazione più probabile di quella frase, e una citazione con numero, anno e tribunale è una continuazione molto probabile. Il modello non ha un posto dove andare a controllare se quella sentenza esiste.

Le allucinazioni non sono un difetto che prima o poi verrà sistemato: sono lo stesso meccanismo visto dal lato sbagliato. Si riducono dandogli i documenti giusti, facendogli citare da dove ha preso la risposta, mettendo un controllo a valle. Non si eliminano chiedendogli nel prompt di essere accurato.

La prima cosa che faccio quando metto in piedi un sistema così è cercare le domande fuori archivio, perché è lì che inventa con lo stesso tono con cui risponde giusto. E lì va detto, nel prompt e nel codice, di rispondere che non lo sa.

Cosa cambia quando ne compri uno dentro un prodotto

Tre cose, per chi deve decidere.

Il modello si affitta, non si costruisce: si paga a token a chi lo fornisce, oppure se ne usa uno aperto sui propri server. Quello che compri davvero è il sistema attorno: strumenti, archivio, controlli, interfaccia. È lì che si distingue un progetto con l'AI fatto bene da una demo.
Il risultato dipende dai dati che gli metti davanti. Se le procedure della tua azienda stanno nella testa di due persone, non c'è modello che le sappia.
Va messo dove sbagliare costa poco o dove un umano rilegge: riassumere, classificare, preparare bozze, rispondere a domande su documenti che esistono. Non dove una risposta inventata finisce in un contratto.

Secondo me a chi ti propone un progetto con l'AI conviene chiedere una cosa sola: cosa succede quando sbaglia. Chi ha una risposta a quella domanda ha capito come funziona. Chi ti parla di quanto è intelligente il modello, di solito no.

Come analizzare la reputazione del dominio e del sito? Si perde in fretta e si ricostruisce piano

Dimitri Sohonov — Thu, 01 Oct 2026 00:00:00 +0000

Prima di mettere mano a un sito che non ho costruito io, c'è una cosa che controllo ancora prima del codice: che reputazione ha il dominio. Mi è capitato di ereditare progetti in cui il problema non era il tema lento o il plugin vecchio, ma il fatto che Google e i server di posta avevano già deciso di non fidarsi di quel nome.

La risposta breve: la reputazione di un dominio si analizza in tre posti, e in mezz'ora hai un quadro onesto. Search Console per quello che Google pensa del sito, un controllo su autenticazione e liste nere per quello che pensano i server di posta, e la cronologia del dominio per quello che è successo prima di te. Il resto dell'articolo è il perché, e cosa fare quando uno dei tre dà un risultato brutto.

Reputazione del dominio vuol dire due cose diverse, e si controllano in posti diversi

Il dominio ha due reputazioni, non una: quella davanti ai motori di ricerca e quella davanti ai server di posta. Condividono il nome, e quando una va male l'altra prima o poi ne risente.

La prima è quella di cui si parla quando si fa SEO: Google valuta se il sito è sicuro da visitare, se ha ricevuto azioni manuali per spam, che storia hanno i link che puntano a quel nome. La seconda è la reputazione di mittente: ogni volta che il tuo sito spedisce una mail, che sia la conferma di un ordine o una newsletter, Gmail e Outlook decidono se metterla in posta in arrivo o nello spam, e lo decidono guardando il dominio.

Il primo controllo: Search Console e Safe Browsing

Search Console dice in due pagine se Google ha un problema con te: «Azioni manuali» e «Problemi di sicurezza». Se entrambe sono vuote, la parte peggiore è esclusa. Se non sono vuote, lì c'è scritto il motivo, e di solito è una delle cose che vediamo più avanti: contenuti spam che qualcuno ha iniettato nel sito, oppure link comprati in passato.

Il secondo controllo è il rapporto sulla trasparenza di Google Safe Browsing : si inserisce il dominio e si legge se risulta pericoloso. È lo stesso elenco che fa comparire la schermata rossa in Chrome. Un sito che finisce lì dentro perde i visitatori prima ancora di perdere posizioni, perché il browser li ferma sulla porta.

Il terzo lo faccio a mano: cerco su Google site:nomedominio.it e scorro i risultati. Se tra le pagine compaiono titoli in giapponese, farmaci, scommesse, orologi di marca, il sito è stato bucato e ospita pagine che tu non hai mai scritto. Il proprietario di solito non ne sa niente, perché dal menu non si vedono.

Per la posta: autenticazione e liste nere

Un server di posta si fida di un dominio se riesce a verificare che la mail arriva davvero da lì, e questo passa da tre record DNS: SPF, DKIM e DMARC. Senza quei tre, le mail del sito partono già con un sospetto addosso. Con DMARC impostato su «reject», invece, chiunque provi a spedire a tuo nome viene scartato prima di fare danni.

Come si controlla: un servizio come MXToolbox verifica i record e dice se il dominio o il suo IP di invio compaiono nelle liste nere pubbliche, Spamhaus in testa. Per Gmail, che riceve buona parte della posta che un sito italiano spedisce, Google Postmaster Tools mostra la reputazione del dominio come la vede Gmail, su quattro livelli da «cattiva» ad «alta». È gratuito e quasi nessuno lo apre.

Una cosa che ho imparato a chiedere subito: da dove partono le mail del sito. Se il modulo di contatto spedisce con la funzione mail del server, senza un servizio di invio autenticato, quelle mail finiscono nello spam a intermittenza, e nessuno capisce perché. È una delle prime cose che sistemiamo quando prendiamo in carico un sito.

Il passato del dominio conta anche se non è tuo

Un dominio si compra con la sua storia, e la storia non si vede sul listino del registrar. Prima di consigliare un nome a un cliente lo passo sulla Wayback Machine : se anni fa quel dominio ospitava un sito di scommesse o una pagina parcheggiata piena di link, i motori se lo ricordano, e qualche lista nera pure.

Lo stesso vale per i domini scaduti che qualcuno ricompra perché «hanno già autorevolezza»: più spesso quell'autorevolezza viene da link di pessima qualità lasciati dal proprietario precedente, e ti ritrovi a ereditare un'azione manuale che non hai meritato. Prima di comprare: cronologia, liste nere, una ricerca del nome tra virgolette su Google. Se uno dei tre dà risultati strani, si cambia nome.

Come si perde: quasi sempre senza accorgersene

La reputazione di un dominio si perde per trascuratezza molto più che per malizia. I casi che ho visto più spesso sono tre.

Il sito viene bucato e usato per ospitare pagine spam o per spedire posta. Succede attraverso un plugin non aggiornato o una password debole, e il proprietario lo scopre quando Google gli manda l'avviso, o quando un cliente gli dice che il sito «mostra cose strane».
Il modulo di contatto o la registrazione senza protezione vengono usati dai bot per inviare migliaia di mail dal tuo dominio. Dopo qualche giorno l'IP e il dominio sono in lista nera, e le mail vere, quelle con le conferme degli ordini, smettono di arrivare.
Qualcuno, in buona fede, compra una lista di indirizzi e manda una newsletter dal dominio aziendale. Le segnalazioni come spam salgono, Gmail abbassa la reputazione del dominio, e con lei scende anche la posta ordinaria di tutta l'azienda.

Nessuno di questi danni fa rumore quando avviene. Si notano dopo, dai sintomi: meno traffico, clienti che dicono di non aver ricevuto la mail.

Come si ricostruisce: pulizia, richiesta di riesame e tempo

Si ricostruisce nell'ordine inverso in cui si è persa: prima si toglie la causa, poi si chiede a chi ti ha bollato di riguardare, poi si aspetta. Non esiste il passo che salta l'attesa.

Per la parte web: si rimuove il contenuto iniettato, si chiudono le falle, si cambiano gli accessi, e solo dopo si invia la richiesta di riesame da Search Console spiegando cosa è stato fatto. Per i link comprati in passato Google oggi tende a ignorarli, ma dopo un'azione manuale la richiesta di riesame va fatta e va documentata.

Per la posta: si mettono a posto SPF, DKIM e DMARC, si chiede la rimozione dalle liste nere (ognuna ha la sua procedura, e alcune si puliscono da sole se il flusso di spam si ferma), e si riparte spedendo poco, a chi ha chiesto di ricevere, aumentando con calma. Un consiglio che do sempre: le newsletter partono da un sottodominio dedicato, così se una campagna va male non trascina giù la posta di tutta l'azienda.

Quanto ci vuole non te lo so dire in giorni, perché cambia da caso a caso. Quello che so è che la risalita è sempre più lenta della caduta.

Cosa decidere, se il sito è tuo

Chiedi a chi ti segue il sito tre cose: se Search Console è attiva e qualcuno la guarda, da dove partono le mail del sito e se sono autenticate, e se è previsto un controllo periodico sulle liste nere. Se la risposta a una delle tre è un silenzio, quello è il punto da cui partire.

La reputazione del dominio è il patrimonio più lento da costruire di tutto il progetto, e il più facile da rovinare con una password riciclata. Per questo da noi il controllo di Search Console e dei record di posta sta nella checklist di ogni sito che consegniamo, e nella manutenzione che viene dopo.

Vendere su ChatGPT: cosa serve perché i tuoi prodotti compaiano? Nove campi compilati bene, non una campagna

Dimitri Sohonov — Mon, 21 Sep 2026 00:00:00 +0000

Da qualche mese, quando consegno un e-commerce, una delle prime domande del cliente è «e su ChatGPT ci finiamo?». La risposta che do non piace mai, perché non c’è niente da comprare e nessuno da chiamare.

Per comparire su ChatGPT servono due cose: pagine prodotto che il crawler di OpenAI riesce a leggere, e un feed con nove campi obbligatori compilati per ogni articolo, da inviare al programma per merchant di OpenAI, che oggi accetta partner approvati. Il pagamento dentro la chat non c’entra più: OpenAI lo ha ritirato a marzo 2026 e adesso, quando l’utente vuole comprare, lo manda sul tuo sito.

Quindi il lavoro è sui dati del catalogo. Tutto il resto è contorno.

Il checkout in chat è durato sei mesi, il catalogo è rimasto

Instant Checkout, presentato a fine settembre 2025 con Etsy come primo partner, permetteva di pagare senza uscire da ChatGPT. A marzo 2026 OpenAI lo ha tolto: oggi l’assistente mostra i prodotti e, al momento dell’acquisto, apre il negozio in una scheda del browser o dentro l’app. Ne avevo accennato nel confronto tra WooCommerce e Shopify, e la conclusione non è cambiata: il negozio serve, e serve che funzioni.

Quello che è rimasto in piedi è la parte meno vistosa: l’Agentic Commerce Protocol, lo standard aperto scritto con Stripe, e soprattutto la specifica del feed prodotti. È lì che si decide se i tuoi articoli compaiono. Ed è un lavoro sui dati, non sulla comunicazione.

I nove campi obbligatori sono facili da elencare, difficili da avere

La specifica del feed di OpenAI chiede, per ogni articolo o per ogni variante, questi campi: item_id, title, description, url, brand, seller_name, image_url, availability e price. Nessuno è esotico. Il problema non è capirli, è averli compilati su tutto il catalogo e non solo sui venti prodotti di punta.

I vincoli che contano, perché è lì che i cataloghi veri si inceppano:

title: massimo 150 caratteri, e deve includere la variante («Felpa grigia, taglia M», non «Felpa»).
description: testo semplice, senza HTML, massimo 5.000 caratteri, e descrittivo. La frase del fornitore incollata su trenta prodotti uguali passa la validazione ma non aiuta nessuno.
availability: uno di cinque valori fissi, in_stock, out_of_stock, pre_order, backorder o unknown. «Disponibile su ordinazione» non è un valore.
price: nel formato «79.99 EUR», numero con il punto e codice valuta. Non «€ 79,99».
url: pubblica e con la variante già selezionata, così chi arriva vede la taglia che ha chiesto.
brand e seller_name: veri. La specifica vieta i segnaposto come «n/a» o «unknown» dove non sono previsti.

Una riga del feed nel formato JSONL di OpenAI ha questo aspetto:

{"item_id":"felpa-grigia-m","title":"Felpa in cotone grigia, taglia M","description":"Felpa girocollo in cotone 100%...","url":"https://negozio.it/felpa-grigia?taglia=M","brand":"Nome Marchio","seller_name":"Nome Negozio","image_url":"https://negozio.it/img/felpa-grigia.jpg","availability":"in_stock","price":"79.99 EUR"}

I campi facoltativi (gtin, raggruppamento delle varianti, prezzo scontato, spese di spedizione, condizioni di reso, recensioni) servono al posizionamento e alla fiducia, e li aggiungi dopo. Poi ci sono due interruttori: is_eligible_search, che di default è acceso, e is_eligible_checkout, che di default è spento. Il secondo oggi lo lasci spento e non ci pensi.

Il feed va rifatto ogni giorno, quindi lo deve fare una macchina

OpenAI chiede uno snapshot completo del catalogo almeno una volta al giorno, caricato via SFTP in JSONL o CSV compressi, e consiglia di partire con un campione di un centinaio di articoli per farlo validare prima di automatizzare. Tradotto: non è un file che esporti una volta dal pannello e dimentichi. È un job che gira, che legge i dati dal CMS, li traduce nel formato giusto e si rompe quando qualcuno rinomina un attributo.

Su Shopify questa parte la fa la piattaforma: dal 24 marzo 2026 gli Agentic Storefronts espongono il catalogo a ChatGPT e ad altri assistenti, partendo dai merchant statunitensi, e si gestiscono dal pannello come un canale di vendita. Su WooCommerce il quadro è meno finito: l’MCP è nel core, il feed passa da estensioni di terze parti e il checkout agentico tramite Stripe è ancora annunciato sulla pagina ufficiale. In entrambi i casi il feed è una fotografia del catalogo: se la scheda è vuota, il feed è vuoto.

Anche senza feed, ChatGPT legge le tue pagine prodotto

Il programma per merchant oggi è riservato ai partner approvati: si compila il modulo su chatgpt.com/merchants e si aspetta. ChatGPT Shopping è nato negli Stati Uniti e OpenAI non pubblica un elenco di paesi, quindi non so dirti quando un negozio italiano entra. Ma ChatGPT ha anche un crawler, OAI-SearchBot, che legge le pagine pubbliche per la sua ricerca e cita quello che trova. Questa strada è aperta a tutti, e chiede la stessa igiene.

In pratica: un robots.txt che non lo blocca, un HTML che contiene già prezzo e disponibilità quando la pagina arriva, non montati dopo dal JavaScript, e i dati strutturati Product che dicono le stesse cose del feed. Non ho misure su quanto JavaScript esegua OAI-SearchBot, e non ne ho viste pubblicate; lo tratto come trattavo Googlebot prima che imparasse a renderizzare: quello che conta sta nell’HTML. Un negozio che fa questo lavoro compare comunque, ed è pronto per il feed il giorno in cui la domanda viene accettata.

Chi ha il catalogo sporco resta invisibile, e non se ne accorge

Questa è la parte che mi preoccupa di più. Un catalogo con le descrizioni copiate dal listino del fornitore, le disponibilità che si aggiornano a mano, i brand compilati a metà: sul sito si nota appena, perché chi compra guarda la foto e il prezzo. In un feed è un articolo scartato in silenzio. Nessuno ti manda una mail, gli ordini continuano ad arrivare dai canali soliti, e l’assenza da ChatGPT non compare in nessun report.

Quando eredito un e-commerce la prima cosa che faccio è esportare il catalogo in un foglio e contare le celle vuote, colonna per colonna. Il risultato sorprende sempre chi lo gestisce da anni, perché dal pannello si vede un prodotto alla volta e in tabella si vedono tutti insieme. Quel foglio è il preventivo: dice quante ore di dati ci sono prima di qualsiasi integrazione.

Cosa decidere, se il negozio lo stai commissionando adesso

Le cose da mettere in chiaro con chi ti sviluppa il sito sono tre, e nessuna è una funzione da aggiungere dopo:

Chi è responsabile dei dati di catalogo. Una persona, non un plugin: i campi obbligatori li compila qualcuno che conosce i prodotti, e li tiene aggiornati.
Come è fatto il template della scheda prodotto: HTML completo già dal server, dati strutturati Product, e un URL per variante. È il lavoro che rende leggibile la pagina al crawler oggi e al feed domani.
Che l’esportazione del catalogo nel formato di un feed sia nel preventivo, con la sua automazione, e non un «lo vediamo poi».

La mia posizione è che vendere su ChatGPT, oggi, sia una conseguenza di come tieni i dati, più che un canale da aprire. Chi ha il catalogo in ordine ci arriverà con poco sforzo quando il programma si aprirà anche qui, e nel frattempo compare già nelle risposte. Chi non lo ha in ordine può fare tutto il marketing che vuole. Se stai per aprire o rifare un e-commerce, la prima domanda da fare a chi lo costruisce è questa: come esce il catalogo, e chi lo tiene pulito?

WooCommerce o Shopify nel 2026? Scegli per chi ci metterà le mani, non per l’AI che compra

Dimitri Sohonov — Thu, 17 Sep 2026 00:00:00 +0000

Da quando facciamo e-commerce, la domanda con cui si apre quasi ogni primo incontro è la stessa: «WooCommerce o Shopify?». Da un anno circa ne arriva una seconda subito dopo: «ma ha ancora senso, se la gente compra chiedendo a ChatGPT?». Rispondo a tutte e due, in ordine.

Shopify se il negozio deve funzionare senza che nessuno ci metta le mani, e accetti un canone e le regole di casa sua. WooCommerce se hai già WordPress, qualcuno che lo mantiene, e regole di vendita che una piattaforma chiusa non ti lascia scrivere. L’AI che compra non cambia il criterio: cambia cosa deve essere in ordine nel catalogo, e quello va fatto su entrambe.

Gli e-commerce che abbiamo in portfolio girano tutti su WooCommerce, quindi la mia simpatia è dichiarata. Ed è proprio per questo che a una buona parte dei clienti consiglio Shopify.

Shopify affitta un negozio finito, WooCommerce ti consegna i pezzi

La differenza vera è una sola e viene prima di tutte le altre: su Shopify affitti un negozio già costruito, su WooCommerce lo assembli dentro un WordPress che è tuo. Da qui discende tutto il resto: chi paga cosa, chi ripara cosa, cosa puoi cambiare e cosa no.

Su Shopify non esiste il server, non esistono gli aggiornamenti di PHP, non esiste il plugin di pagamento che smette di funzionare il sabato sera. Esistono un pannello, un tema, un catalogo di app e un checkout che è lo stesso per tutti, con le personalizzazioni che Shopify decide di concederti. In cambio paghi ogni mese, paghi le app che aggiungi, e se non usi il loro sistema di pagamento paghi una commissione in più su ogni vendita.

Su WooCommerce il plugin è gratuito e il resto è tutto tuo: hosting, aggiornamenti, sicurezza, compatibilità fra le estensioni, e la libertà di toccare qualunque riga del checkout. È un cantiere, non un prodotto. A me il cantiere piace, ma va detto a chi lo compra.

Il costo vero non è il canone, sono le ore di chi ci mette le mani

Quando un cliente mi dice «WooCommerce è gratis» gli metto in fila le voci che gratis non sono: un hosting decente, un tema serio, le estensioni a pagamento che servono quasi sempre per spedizioni, pagamenti e fatturazione, e soprattutto le ore di manutenzione in un anno. Non dico che costi più di Shopify: dico che il conto va fatto tutto, e i due totali si avvicinano più di quanto sembri il primo giorno.

La voce che sbilancia il conto è chi risponde quando qualcosa si rompe. Ogni WooCommerce che ho ereditato aveva la stessa storia: estensioni ferme da mesi perché chi c’era prima aveva paura di toccare il checkout, e il cliente convinto che il sito andasse da solo. Non va da solo, e ho scritto a parte cosa si rompe in un sito che nessuno tocca. Su Shopify quel rischio è compreso nel canone: è il motivo per cui il canone esiste.

Per questo la prima domanda che faccio non riguarda il prodotto: è «chi si occupa del sito dopo il lancio?». Se la risposta è «nessuno, deve andare da solo», la risposta è Shopify, e discuterne oltre è tempo perso.

WooCommerce vince quando le regole del negozio sono le tue

Il caso in cui WooCommerce resta senza rivali è il negozio che non vende come vendono tutti. Listini diversi per cliente, un configuratore che calcola il prezzo, un gestionale che deve leggere e scrivere gli ordini, una fatturazione con regole particolari. Su WordPress ognuna di queste cose è codice che posso scrivere; su Shopify è un’app che qualcun altro ha scritto, se esiste, dentro i limiti di un checkout chiuso.

Il secondo caso è il negozio che vive dentro un sito che fa soprattutto altro. Per Paola Boni il sito è prima di tutto un portfolio di opere in alta risoluzione, e lo shop sta nello stesso percorso: si guarda e si compra senza cambiare contesto. Per NNB Upcycling ogni capo esiste in un pezzo solo, e il catalogo va gestito di conseguenza. In tutti e due i casi WooCommerce ci ha lasciato decidere come doveva funzionare il negozio, invece di adattare il negozio a come funziona la piattaforma.

Il prezzo di questa libertà è che ogni riga scritta va mantenuta, e va mantenuta a ogni aggiornamento di WooCommerce. Se il progetto non ha nessuna di queste esigenze, la libertà la paghi senza usarla.

Shopify vince su tutto quello che non vuoi più dover riparare

Pagamenti, sicurezza, tenuta nei picchi, aggiornamenti: su Shopify sono problemi di Shopify. Per un negozio che vende prodotti standard con spedizioni standard, gestito da chi non ha e non vuole un tecnico a disposizione, è la scelta giusta, e non mi metto a difendere WooCommerce per principio.

Le cose che mi fanno storcere il naso restano. Il checkout lo tocchi solo nei limiti previsti, il tema va comprato o scritto su misura in Liquid, e ogni funzione in più è un’app in abbonamento che si somma alle altre. Per la fatturazione elettronica italiana serve un’app di terze parti. Ma sono fastidi, non blocchi. Per un negozio senza regole particolari li accetto volentieri, in cambio di non ricevere più la telefonata del sabato sera.

E se ormai comprano tutti dall’AI?

Non comprano tutti dall’AI, e anche chi chiede a ChatGPT poi compra quasi sempre sul sito del negozio. Il checkout dentro ChatGPT che OpenAI aveva presentato a fine 2025 è stato ridimensionato dalla stessa OpenAI pochi mesi dopo: oggi l’assistente consiglia e rimanda, e l’acquisto si chiude sullo storefront del venditore. Quindi il negozio serve ancora, e serve che funzioni.

Quello che cambia è chi legge il catalogo. Un agente che consiglia prodotti legge dati: nome, prezzo, disponibilità, varianti, spedizione, tutti compilati e aggiornati. Su Shopify questa esposizione la fa la piattaforma, con un canale che si attiva da solo e si regola dal pannello. Su WooCommerce le basi ci sono, le ultime versioni espongono il negozio agli assistenti tramite MCP, e per i protocolli di OpenAI e Google si passa da estensioni, alcune ancora annunciate. In entrambi i casi il lavoro vero è lo stesso: un catalogo con i campi compilati. Un negozio con le schede a metà è invisibile agli agenti su qualunque piattaforma , e non se ne accorge.

Quindi l’AI non cambia la scelta. La rende più severa su un punto che valeva già: i dati.

Le domande da farsi prima di scegliere

Se stai commissionando un e-commerce, le domande da farti sono queste:

Chi tiene il sito dopo il lancio, e quante ore l’anno può dedicargli?
Il negozio vende come tutti, o ha regole sue su prezzi, prodotti o fatturazione?
Il negozio è tutto il sito, o un pezzo di un sito che fa soprattutto altro?
Preferisci un canone fisso, o costi iniziali più alti e ore di manutenzione dopo?
Chi deve leggere il tuo catalogo: solo persone, o anche gli assistenti AI?

La mia posizione è che nel 2026 la scelta si è fatta più facile, non più difficile, perché le due piattaforme sono diventate più diverse. Shopify è sempre più un prodotto chiuso e sempre più affidabile; WooCommerce è sempre più uno strumento per chi vuole costruire. Se ti ritrovi a scegliere WooCommerce per risparmiare, stai scegliendo male. Se scegli Shopify e poi chiedi tre personalizzazioni al checkout, anche. Se il dubbio resta, parlane con chi il negozio dovrà mantenerlo: è il lavoro che facciamo, e la domanda su chi ci metterà le mani gliela faremo comunque.

Come farsi citare da ChatGPT e da AI Overview? La risposta va scritta prima della premessa

Dimitri Sohonov — Tue, 15 Sep 2026 00:00:00 +0000

Da qualche mese la domanda che mi arriva più spesso dopo «perché non siamo primi su Google» è un'altra: «perché ChatGPT non ci nomina?». Il cliente ha chiesto al chatbot chi fa quella cosa nella sua zona, e nella risposta ci sono tre concorrenti e lui no. Lo stesso con l'AI Overview in cima a Google: c'è la sintesi, ci sono le fonti in piccolo, e il suo sito non è fra quelle.

La risposta breve: ti citano quando una tua pagina contiene un passaggio che risponde alla domanda da solo , in due o tre frasi, senza bisogno del resto della pagina; e quando quel passaggio è verificabile e attribuibile a qualcuno con un nome. Tutto il resto, dati strutturati compresi, serve alla macchina per trovare quel passaggio e capire di chi è. Non lo sostituisce.

I motori generativi non linkano, citano

La differenza con la ricerca classica è questa. Google, quello di prima, ordina pagine intere e ti manda lì. Un motore generativo lavora al contrario: prima scrive la risposta, poi ci appende le fonti da cui ha preso i pezzi. L'unità di lavoro diventa il passaggio, non la pagina: un paragrafo, una riga di tabella, un punto di un elenco.

Da qui una conseguenza che all'inizio mi ha sorpreso: una pagina posizionata bene può non essere mai citata, e una in seconda schermata può comparire fra le fonti di ChatGPT o Perplexity. Quando controllo cosa rispondono questi strumenti sui temi dei nostri clienti, le pagine citate hanno quasi sempre la stessa forma: un titolo che è una domanda, una risposta secca sotto, l'argomentazione dopo. Non sono le pagine più belle. Sono quelle che si lasciano tagliare a pezzi senza perdere senso.

La risposta diretta va in apertura, non in fondo

È il punto che vale più di tutti gli altri, e nei testi che ricevo dai clienti manca quasi sempre. Il testo tipico apre con la premessa, spiega il contesto e arriva alla risposta al quinto paragrafo. Per un lettore è faticoso. Per una macchina che deve estrarre una risposta è inutile: nella prima metà non c'è niente di citabile.

La forma che funziona è quella di questo articolo. Titolo con la domanda, e nel primo o nel secondo paragrafo una o due frasi che rispondono e si leggono da sole. Poi le condizioni, le eccezioni, i casi in cui non vale. Se la risposta onesta è «dipende», si dice da cosa dipende, in una riga: «dipende da molti fattori» non contiene informazione, ed è la frase che una macchina scarta per prima.

Dati che qualcuno possa controllare

Un motore generativo deve decidere a chi credere, e lo fa con criteri banali: la fonte dice cose specifiche, quelle cose tornano anche altrove, la fonte ha un nome. Un testo pieno di «leader di settore» e «soluzioni su misura» non offre niente da controllare, quindi niente da citare.

In pratica, quello che chiedo di scrivere nelle pagine di servizio: un intervallo di prezzo dichiarato come intervallo, i tempi tipici di un progetto, i passi di una procedura nell'ordine in cui avvengono, gli strumenti con il loro nome. E se un numero non lo puoi sostenere, la frase si riscrive senza. Un dato inventato che finisce citato da ChatGPT torna indietro con il tuo nome sopra.

La pagina si deve leggere senza CSS

Questa è la parte mia, quella del codice, e viene dopo apposta: se il testo non risponde, il markup pulito non serve. La prova che faccio è banale: apro la pagina in modalità lettura, oppure con gli stili disattivati, e guardo cosa resta. Deve restare un documento con un solo h1, h2 che dicono una cosa, elenchi fatti con elementi di lista e tabelle fatte con elementi di tabella. Se una tabella è un'immagine, per la macchina non esiste. Se le risposte delle FAQ vengono caricate solo al clic, non esistono nemmeno quelle.

Il caso che trovo più spesso è la pagina costruita interamente lato client: l'HTML che arriva dal server è quasi vuoto e il contenuto compare dopo, da JavaScript. Google in parte lo gestisce, gli altri crawler molto meno. Su un sito statico o con rendering lato server il problema non si pone, ed è uno dei motivi per cui le pagine che devono farsi trovare le costruiamo così.

Poi il file robots.txt. Mi è capitato di trovare siti che bloccavano tutti i bot con un nome legato all'AI per paura dell'addestramento, e poi si chiedevano perché ChatGPT non li citasse. Quale bot addestra e quale bot cerca sono due cose distinte, e vanno decise separatamente leggendo la documentazione di ciascun motore.

Entità dichiarate: la macchina deve sapere chi parla

Citare vuol dire attribuire. Se una pagina non dice in modo leggibile chi l'ha scritta e per conto di chi, il passaggio può essere ottimo ma la fonte è debole. Qui i dati strutturati hanno senso: come modo per dichiarare le entità, niente di più.

Un'entità Organization sul sito, con nome, indirizzo, contatti e i profili ufficiali collegati con sameAs, così che il nome sul sito, su LinkedIn e nelle directory coincida.
Una Person per ogni autore che firma, con la sua pagina e i suoi profili, collegata agli articoli con il campo author.
Article o BlogPosting sui contenuti, con data di pubblicazione e di aggiornamento vere: la data è una delle poche cose che questi motori mostrano accanto alla fonte.

L'errore che vedo più spesso è la coerenza. Tre varianti dello stesso nome aziendale, un autore che sul sito è un nickname e su LinkedIn ha nome e cognome, la pagina «chi siamo» senza nessuno dentro. Per una macchina che deve risolvere un'entità sono tre fonti diverse, tutte deboli.

Cosa si misura e cosa per ora no

Qui è il punto su cui mi tocca raffreddare le aspettative. Le visite che arrivano dai chatbot si vedono: nel referral dell'analytics compaiono i domini di ChatGPT, Perplexity e simili, e si possono raggruppare in un canale a parte. Sono ancora poche rispetto a Google, ma sono clic di chi ha già letto una risposta e ha voluto approfondire.

Quello che non si misura, al momento in cui scrivo: quante volte sei stato citato senza che nessuno cliccasse, in che posizione fra le fonti, con quale frase. Search Console non separa le impression dell'AI Overview dal resto della ricerca: vedi il totale, non la parte. L'unico metodo che ho trovato è artigianale: una lista di domande per ogni cliente, riprovata ogni tanto sui vari motori, annotando chi viene citato. Non è una metrica, è un campione. Ma per ora è l'unico che c'è.

Cosa cambia per chi commissiona il sito

Secondo me la notizia buona è che non c'è un lavoro nuovo da comprare. Farsi citare da un motore generativo e scrivere pagine utili a una persona di fretta sono la stessa cosa vista da due lati: rispondere subito, dire cose controllabili, firmare quello che si scrive, e costruire la pagina in modo che il contenuto stia nell'HTML e non solo sullo schermo.

Quello che cambia è la priorità. Il tempo che prima andava nel decimo articolo generico vale di più speso a riscrivere le cinque pagine che rispondono alle domande vere, con un nome sotto e un dato dentro. È da lì che partiamo quando lavoriamo sulla SEO e la GEO di un sito, e di solito è la parte che pesa di più.

A cosa serve lo sviluppatore se posso fare un sito da solo? Uso gli stessi strumenti anch'io

Dimitri Sohonov — Tue, 08 Sep 2026 00:00:00 +0000

«Se l'AI mi fa il sito in un pomeriggio, tu a cosa servi?» Questa domanda me la sento fare sempre più spesso, e ha perfettamente senso. È anche la domanda giusta, se la fai prima di aprire il portafoglio.

Rispondo subito, perché la risposta onesta è più corta di quanto ti aspetti. Se il tuo sito è una vetrina di poche pagine e il tuo lavoro non dipende da quelle pagine, fallo da solo: risparmi soldi e settimane, e te lo dice uno che i siti li costruisce per mestiere. Se invece da quel sito passano ordini, appuntamenti o richieste di preventivo, quello che ti serve non è qualcuno che scriva il codice. È qualcuno che sappia cosa chiedere.

La domanda non è nata con l'AI

Cinque anni fa era identica, solo con altri strumenti. I costruttori visuali e i template esistono da un pezzo: con trenta euro compravi un tema completo, ci mettevi dentro i tuoi testi e la sera dopo eri online.

In certi casi era anche più veloce di adesso. Un template lo scegli guardandolo, mentre far convergere un modello su quello che hai in testa richiede giri di richieste e correzioni.

Quindi l'AI non ha creato la domanda. Ha abbassato ancora la barriera, e con essa la quota di persone che si fermano a chiedersi se il risultato regge.

Anch'io uso gli stessi strumenti

Questa è la parte che secondo me toglie l'ambiguità: non c'è nessuna gara fra me e l'AI, perché la uso tutti i giorni. Mi scrive porzioni di codice, mi fa da rubber duck quando un bug non torna, mi risparmia le parti noiose.

La differenza non sta nell'attrezzo. Sta nel fatto che io so cosa deve uscire dall'altra parte, e quindi so cosa chiedergli e, soprattutto, riconosco quando la risposta è sbagliata.

Chi ti segue un progetto oggi userà gli stessi strumenti che useresti tu. Non stai pagando l'accesso a un attrezzo che non hai: stai pagando il fatto che qualcuno sappia dove sta andando.

Il problema non è produrre, è sapere cosa chiedere

Un modello è compiacente per costruzione: ti dà quello che gli chiedi, non quello che ti serve. Se una cosa non la sai, non la chiedi. E se non la chiedi, quella cosa non c'è.

Queste sono domande che in un progetto salgono da sole, e che chi non fa questo mestiere non ha motivo di conoscere:

I titoli della pagina seguono una gerarchia, o sono solo testo scritto grande?
I bottoni sono bottoni, o div che ci somigliano?
Cosa succede a chi naviga solo con la tastiera?
Questa immagine da quattro megabyte la vogliamo servire così a chi arriva da rete mobile?
Il form manda l'email, ma controlla quello che riceve? E dove finiscono quei dati?

Nessuna di queste si vede guardando la pagina. Tutte si pagano dopo.

Somiglia a quello che avevi chiesto, ma non lo è

Qui sta la trappola vera, e non è colpa dell'AI: è come funziona il chiedere. Tu descrivi un risultato visivo, e ottieni un risultato visivo.

Un div stilizzato come bottone sembra un bottone in tutto, tranne che non lo è: non risponde all'invio, non entra nella navigazione da tastiera, uno screen reader non lo annuncia come comando. Sullo schermo è identico.

Vale per mezza pagina. Il menu che si apre ma non si chiude con Esc. Il testo che sta dentro un contenitore finché non arriva un cliente con un nome lungo. Il layout che a occhio è responsive perché è tutto rimpicciolito.

Sono cose che non vedi, e che scopri il giorno in cui da quel sito ti serve qualcosa.

Il conto si paga al primo cambiamento

Il risparmio si misura il primo giorno. Il costo si misura la prima volta che devi cambiare qualcosa.

A quel punto arrivano le domande scomode. Dove sta il codice? Chi ha le chiavi degli accessi? Esiste un backup, o l'unica copia è quella online? Se tocco questa cosa, cosa si rompe altrove?

Se il sito l'hai messo insieme senza sapere com'è fatto, tutte queste risposte le dovrai comprare più tardi. E costano più che averle previste, perché prima di sistemare qualcosa bisogna capire cosa c'è.

Quando ti dico di farlo da solo

Non è una concessione per sembrare onesto. Ci sono casi in cui rivolgersi a qualcuno è spendere per un controllo che non ti serve.

La vetrina di poche pagine. Il curriculum online. La pagina dell'attività che serve a farsi trovare con indirizzo, orari e un numero di telefono. La landing per un evento che fra due mesi non esiste più.

In tutti questi casi il sito non è il tuo prodotto: è un biglietto da visita. Se sbagli qualcosa lo rifai in un pomeriggio e non hai perso niente. Apri l'AI, o compra un template, e divertiti.

Le quattro domande da farti prima di decidere

Non servono competenze tecniche per rispondere, e la risposta ti dice da sola cosa fare:

Se questa pagina resta offline due giorni, perdo lavoro?
Ci passano dati di altre persone (ordini, pagamenti, dati personali)?
Fra un anno qualcuno ci dovrà mettere mano, e non sarò io?
So dire cosa deve fare il sito, o so dire solo come deve sembrare?

Tre no e un sì: fallo da solo, davvero. Anche un solo sì fra le prime tre: il sito è diventato uno strumento di lavoro, e gli strumenti di lavoro conviene che qualcuno li segua.

La mia posizione

Il confine non passa fra chi sa scrivere codice e chi no. Quello lo scrive anche l'AI, e lo scrive in fretta.

Passa fra chi sa cosa deve venire fuori e chi lo scopre dopo, a cose fatte. L'AI ha reso quasi gratis la parte che costava, cioè produrre. Ha lasciato intatta quella che costa davvero, cioè decidere.

Se dal tuo sito passa il lavoro e la seconda parte non la vuoi fare da solo, quello è il punto in cui serve qualcuno accanto.

Landing page con molti video: 36 clip in una pagina, senza rallentarla

Dimitri Sohonov — Sun, 06 Sep 2026 00:00:00 +0000

Quando è arrivata la richiesta per la landing di SNACK, la nuova unit di Social Content Factory, la parte che mi preoccupava non era il design. Era il conto della spesa.

Trentasei riquadri video sulla stessa pagina, che scorrono in due nastri orizzontali, più il video grande in apertura. Caricati come viene naturale caricarli, sono diciassette megabyte che partono prima che il visitatore abbia letto una riga.

Poi ho misurato i file davvero, e il rapporto era più brutale di quanto pensassi.

Diciassette megabyte di video, o trecento kilobyte di immagini

I file video della pagina, sommati, fanno 17,2 MB. Le anteprime degli stessi video, in WebP, ne fanno 301 KB in tutto. Cinquantanove volte meno.

Questa non è una micro ottimizzazione da fine progetto. È la differenza fra una pagina che si apre e una che non si apre.

E quei megabyte non li paga chi guarda i video fino in fondo: li paga chiunque atterri sulla pagina, compreso chi legge due righe e se ne va. Che poi è la maggioranza.

Da qui la prima decisione, facile da dire e scomoda da accettare: all'apertura non deve partire nessun video. Nemmeno quello grande in cima.

Un video senza src non è un video, è un segnaposto

Il browser scarica un video perché glielo dici tu. Se l'indirizzo non sta in src ma in un attributo che lui non conosce, non parte niente.

<video
  data-src="/media/video/loop/promo.mp4"
  poster="/media/posters/hero.webp"
  preload="none"
  muted loop playsinline
></video>

Tre cose in quel frammento fanno il lavoro.

data-src invece di src: per il browser lì non c'è nessun video da scaricare, solo una stringa qualsiasi.
poster: quello che vedi mentre il video non c'è. L'anteprima dell'apertura pesa 14 KB contro i 4,6 MB del video che sostituisce.
preload="none": quando più tardi il src arriverà davvero, il browser non si metterà comunque a scaricare in anticipo per conto suo.

Il risultato è che la pagina, appena aperta, è fatta di immagini. Diciassette anteprime da pochi kilobyte l'una al posto di altrettanti file da mezzo megabyte abbondante.

Il video entra in scena ottocento pixel prima di servire

Il src glielo diamo dopo, e lo decide un IntersectionObserver:

const io = new IntersectionObserver(
  (entries) => {
    entries.forEach((entry) => {
      const video = entry.target;
      if (entry.isIntersecting) {
        if (!video.src && video.dataset.src) {
          video.src = video.dataset.src;
        }
        video.muted = true;
        video.play().catch(() => {});
      } else {
        video.pause();
      }
    });
  },
  { rootMargin: '800px' },
);

document.querySelectorAll('video[data-src]').forEach((v) => io.observe(v));

Il pezzo che conta è rootMargin: '800px'. Non aspettiamo che il riquadro sia visibile: lo carichiamo quando manca ancora quasi uno schermo intero. Chi scorre normalmente trova il video già pronto e non vede nessun caricamento; chi non arriva mai fin lì non lo scarica mai.

L'altro dettaglio è quel controllo su !video.src. Senza, ogni volta che il riquadro rientra nello schermo riassegneresti l'indirizzo, e riassegnare src a un video significa ricominciare da capo. Con il controllo, ogni file viene chiesto una volta sola in tutta la vita della pagina.

La riga che quasi tutti dimenticano è la pausa

Guarda il ramo else: video.pause().

Un video che è uscito dallo schermo, se nessuno lo ferma, continua a decodificare fotogrammi. Non è più un problema di rete, è un problema di processore.

Trentasei video in riproduzione simultanea su un portatile fanno partire la ventola e rendono lo scorrimento a scatti, anche quando la rete ha finito il suo lavoro da un pezzo. Su un telefono si mangiano la batteria.

È una riga sola, ed è quella che tiene lo scorrimento fluido.

I nastri duplicano i riquadri, e la duplicazione va nascosta

I due nastri scorrono all'infinito, e per farlo clonano i riquadri finché non coprono tutta la larghezza. Ecco perché i diciassette video di partenza diventano trentasei elementi nella pagina.

I cloni però non aggiungono informazione, la ripetono. Quindi ricevono aria-hidden="true": chi naviga con uno screen reader si sente leggere l'elenco dei lavori una volta, non tre.

Stesso ragionamento per le animazioni: se il sistema operativo dichiara prefers-reduced-motion, le entrate allo scorrimento non partono proprio. Chi ha bisogno di quella impostazione di solito ha un buon motivo.

Cosa dice il punteggio, e cosa dice la pagina

Il risultato è 100 su 100 su tutti i parametri di PageSpeed Insights, che era l'obiettivo dichiarato all'inizio.

Ma il numero che guardo io è un altro: il documento HTML pesa 28 KB e il server risponde in poco più di due decimi di secondo. Il punteggio è una conseguenza, non un traguardo.

Lo dico perché il rapporto con quel 100 è ambiguo. Un punteggio pieno non certifica che la pagina sia bella o che converta. Certifica che non stai facendo pagare a chi arriva il costo di cose che non ha chiesto.

Se stai commissionando una pagina piena di video

Il ragionamento vale ben oltre SNACK. Ogni volta che un progetto mette molti media sulla stessa schermata, le domande da fare in fase di preventivo sono sempre queste tre:

I video partono tutti all'apertura o solo quando servono? Se la risposta è vaga, è la prima.
Cosa vede l'utente prima che il video sia pronto? Se la risposta è "un rettangolo nero", manca il poster.
Cosa succede ai video che sono usciti dallo schermo? Se nessuno li ferma, la pagina resta pesante anche dopo che ha finito di caricare.

Sono tre domande che chiunque può fare senza sapere una riga di codice, e che separano una pagina costruita da una pagina assemblata.

La mia posizione

La landing di SNACK mi piace perché è il caso in cui il vincolo tecnico e l'idea creativa spingono nella stessa direzione. Volevano una pagina che si comportasse come i contenuti short-form che l'unit produce: parte subito, non fa aspettare, non chiede pazienza.

Quella promessa non la mantiene il design. La mantiene la decisione di non scaricare diciassette megabyte a un visitatore che ancora non sa se gli interessi.

Se hai un progetto con molti video e non sai da che parte prenderlo, di questo ci occupiamo tutti i giorni.

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

Dimitri Sohonov — Tue, 25 Aug 2026 00:00:00 +0000

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 Sohonov — Mon, 24 Aug 2026 00:00:00 +0000

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.

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

Dimitri Sohonov — Mon, 02 Mar 2026 00:00:00 +0000

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.