Glossario Shopify & GEO

La Generative Engine Optimization (GEO) è l'insieme di pratiche tecniche e di contenuto che rendono un sito più facile da leggere, citare e raccomandare per i motori di ricerca generativi e gli assistenti conversazionali basati su intelligenza artificiale (ChatGPT, Perplexity, Gemini, Claude), a differenza della SEO tradizionale che ottimizza per il posizionamento nelle pagine di risultati di un motore di ricerca (SERP). Mentre la SEO classica lavora soprattutto su parole chiave e backlink, la GEO lavora su entità riconoscibili (chi sei, cosa fai, con dati coerenti in tutto il sito), su dati strutturati (schema.org/JSON-LD) che rendono espliciti fatti altrimenti impliciti nel testo, e su contenuto scritto in modo che un modello linguistico possa estrarne un passaggio corretto senza fraintendimenti. Include anche l'accessibilità tecnica ai crawler AI (un robots.txt che non blocca i bot conosciuti, file come llms.txt o agents.md) e l'eliminazione di contenuto nascosto o contraddittorio, che un motore generativo tende a penalizzare o ignorare. Per una PMI su Shopify, applicare la GEO significa in pratica: markup coerente su ogni pagina, un'unica versione dei fatti aziendali, e contenuti che rispondono subito alla domanda dell'utente invece di arrivarci dopo molte righe di introduzione.

llms.txt è una convenzione emergente (non uno standard ufficiale del web) che propone di pubblicare, nella root di un sito, un file di testo in formato Markdown pensato per orientare i modelli linguistici (LLM) verso i contenuti più rilevanti di quel sito, in modo simile a come robots.txt orienta i crawler tradizionali sulle regole di scansione. Non sostituisce la sitemap né i dati strutturati: è un indice sintetico, leggibile da una macchina, che elenca le pagine o le sezioni che un sito considera più significative da citare. Su Shopify, dal cambio di piattaforma di fine maggio 2026, la root /llms.txt è servita nativamente dalla piattaforma stessa per ogni negozio, e fa anche da fallback per /agents.md e /llms-full.txt; l'unico modo per un merchant di intervenire su questo contenuto è tramite un file di tema dedicato, non più tramite un proxy applicativo. È quindi un tassello della GEO, non l'unico: un llms.txt ben curato non compensa dati strutturati assenti o contenuto contraddittorio altrove sul sito.

agents.md è il file, servito alla root del dominio, con cui Shopify descrive in modo testuale e strutturato — pensato per essere letto da un agente AI più che da una persona — chi gestisce un negozio, quali servizi offre e dove trovare le fonti di verifica (recensioni, profili, contatti). Dal 28 maggio 2026 è il meccanismo ufficiale della piattaforma anche per rispondere alle richieste su /llms.txt e /llms-full.txt: se questi percorsi non hanno un contenuto proprio, la risposta arriva comunque da agents.md. Il contenuto tipico è una lista puntuale di link (servizi offerti con i relativi URL, profili dove la reputazione è verificabile da terzi, contatti): un agente AI estrae con più affidabilità una lista di riferimenti diretti che un paragrafo discorsivo di presentazione. Per un merchant, mantenerlo aggiornato e coerente con il resto del sito (stessi servizi, stessi link, stesso modo di descrivere l'attività) è più utile che cercare canali alternativi per parlare ai crawler AI: è il canale già presidiato dalla piattaforma stessa, non serve duplicarlo altrove.

Lo Schema Markup è un vocabolario standardizzato (schema.org) che si aggiunge al codice di una pagina per descrivere in modo esplicito, in un formato leggibile dalle macchine, cosa rappresenta quel contenuto: un prodotto, il suo prezzo, un articolo con il suo autore e la data di pubblicazione, un'azienda con il suo indirizzo. Su Shopify si implementa quasi sempre con JSON-LD, uno script dedicato inserito nella pagina, separato dal markup visivo HTML. Senza Schema Markup, un motore di ricerca o un assistente AI deve dedurre il significato del contenuto solo dal testo e dalla struttura visiva; con lo Schema Markup, quell'informazione è dichiarata una volta sola, in modo non ambiguo. È la base tecnica sia dei rich snippet nei risultati di ricerca sia della citabilità di un sito da parte dei motori di ricerca generativi: un'entità (persona, azienda, prodotto) descritta con un identificativo coerente in tutte le pagine evita che lo stesso fatto venga interpretato in modo diverso da pagina a pagina. Va usato per descrivere solo ciò che è realmente visibile e verificabile in pagina: dichiarare nello schema un dato che non compare a video, o un valore diverso da quello mostrato, è considerato dalle linee guida di Google una pratica scorretta.

Un rich snippet è il risultato di ricerca arricchito che un motore come Google mostra grazie ai dati strutturati (schema markup) presenti su una pagina: stelle di valutazione, prezzo, disponibilità di un prodotto, o la struttura a domande e risposte di una FAQ. Non è il markup in sé, ma il suo effetto visibile nella pagina dei risultati: un annuncio normale mostra solo titolo, URL e una descrizione testuale; un rich snippet aggiunge elementi visivi che occupano più spazio e comunicano più informazione prima ancora del click. Ottenere un rich snippet non è garantito dall'aggiunta dello schema markup: è il motore di ricerca a decidere se e quando mostrarlo, e può smettere di farlo se rileva un disallineamento tra il dato dichiarato nello schema e il contenuto realmente visibile in pagina. Per questo un rich snippet va trattato come una conseguenza possibile di dati corretti e coerenti, non come un obiettivo da forzare con valori non verificabili.

I Core Web Vitals sono le metriche ufficiali che Google usa per misurare l'esperienza utente reale di una pagina web, e sono anche un fattore di posizionamento SEO. Le tre metriche attuali sono: LCP (Largest Contentful Paint, il tempo impiegato a caricare l'elemento più grande visibile nella prima schermata), INP (Interaction to Next Paint, la reattività del sito alle interazioni dell'utente per l'intera durata della sessione — ha sostituito il First Input Delay come metrica ufficiale nel marzo 2024), e CLS (Cumulative Layout Shift, quanto la pagina si sposta visivamente mentre carica). Google definisce una soglia di giudizio 'buona' per ciascuna metrica, misurata sui dati reali di navigazione degli utenti, non solo in un test di laboratorio. Su Shopify, le cause più comuni di Core Web Vitals scarsi sono temi non ottimizzati, troppe app di terze parti che caricano script aggiuntivi, e immagini non dimensionate correttamente. Migliorare i Core Web Vitals è un lavoro tecnico sul codice del tema e sul numero di script caricati, non un intervento estetico.

Il Largest Contentful Paint (LCP) è una delle tre metriche Core Web Vitals di Google e misura il tempo che intercorre tra l'inizio del caricamento della pagina e la comparsa a schermo dell'elemento visibile più grande nella prima schermata (tipicamente un'immagine hero o un titolo di grandi dimensioni). Google considera 'buono' un LCP entro 2,5 secondi; oltre i 4 secondi la pagina è classificata come 'scarsa'. Su un e-commerce Shopify, un LCP lento è spesso causato da immagini troppo pesanti o non ottimizzate, dal caricamento di font non critici prima del contenuto principale, o da script di terze parti che occupano il thread principale del browser prima che l'elemento chiave venga renderizzato. Un LCP alto non è solo un problema tecnico: diversi studi indipendenti collegano ritardi di caricamento a un aumento del tasso di abbandono, specialmente su mobile. Le tecniche principali per migliorarlo sono il precaricamento delle risorse critiche, la compressione e il dimensionamento corretto delle immagini, e la riduzione del codice JavaScript non essenziale caricato prima del rendering.

L'Interaction to Next Paint (INP) è la metrica Core Web Vitals di Google che misura la reattività di una pagina alle interazioni dell'utente (click, tap, pressione di un tasto) durante l'intera visita, non solo alla prima interazione. Ha sostituito ufficialmente il First Input Delay (FID) a marzo 2024, perché il FID misurava solo il ritardo della primissima interazione, mentre l'INP osserva tutte le interazioni della sessione e ne registra la più lenta. Google considera 'buono' un INP entro 200 millisecondi. Su un e-commerce, un INP alto si percepisce come un sito che sembra 'incastrato': un click su un menu, l'apertura del carrello o la selezione di una variante prodotto che risponde con un ritardo percepibile. Le cause più comuni sono script JavaScript pesanti o mal ottimizzati (spesso introdotti da app di terze parti installate senza controllo), gestori di eventi che eseguono troppo lavoro sul thread principale del browser, e animazioni non ottimizzate. Ridurre il numero e il peso degli script caricati, ed evitare che il codice blocchi il thread principale durante un'interazione, sono gli interventi principali per migliorarlo.

Il debito tecnico è un concetto dell'ingegneria del software applicato anche allo sviluppo Shopify: indica l'accumulo di scelte tecniche rapide o poco strutturate — codice scritto in fretta, app installate senza verificarne l'impatto, personalizzazioni sovrapposte nel tempo senza un disegno coerente — che nel breve periodo fanno risparmiare tempo, ma nel medio-lungo periodo rendono lo store più lento, più fragile e più costoso da modificare. Il termine è preso in prestito dalla finanza per analogia: come un debito monetario, genera un 'interesse' che si paga nel tempo sotto forma di performance peggiori, bug più frequenti e maggiore difficoltà a introdurre nuove funzionalità senza rompere qualcosa che già funziona. Su Shopify il debito tecnico si manifesta tipicamente attraverso l'accumulo di app installate per necessità puntuali e mai rimosse, codice Liquid personalizzato non documentato, e la stratificazione di soluzioni diverse per lo stesso problema nel tempo. Non è un errore che si commette una volta sola: è un processo che si accumula gradualmente, e richiede una manutenzione periodica dedicata, non solo un intervento correttivo quando il problema diventa visibile agli utenti.

Per app reduction (riduzione delle app) si intende l'approccio che preferisce implementare una funzionalità con codice nativo del tema (Liquid, i blocchi del tema, le funzionalità già incluse in Shopify) invece di installare un'app di terze parti per ottenerla. Ogni app installata inietta tipicamente codice JavaScript e CSS aggiuntivo nel frontend dello store, che deve essere scaricato ed eseguito dal browser di ogni visitatore indipendentemente da quante funzionalità dell'app vengano effettivamente usate: è uno dei fattori più comuni di peggioramento dei Core Web Vitals (in particolare INP e LCP) e di aumento dei costi ricorrenti mensili. L'app reduction non significa 'zero app in assoluto' — per funzionalità complesse o che richiedono un backend proprio un'app resta spesso la scelta più sensata — ma valutare, funzionalità per funzionalità, se esiste già un modo nativo di ottenerla prima di aggiungere un ulteriore livello di dipendenza esterna. Per una PMI, il beneficio pratico è duplice: meno abbonamenti mensili da pagare e uno store più leggero e reattivo, perché ogni script di terze parti in meno è un carico in meno per il browser dell'utente.

Online Store 2.0 (spesso abbreviato OS 2.0) è l'architettura dei temi Shopify introdotta a partire dal 2021, basata su template in formato JSON invece che interamente su file Liquid statici. La caratteristica principale è che ogni sezione del tema (non solo quelle della home page, come nell'architettura precedente) può essere aggiunta, rimossa, riordinata e personalizzata dal commerciante direttamente nell'editor del tema, senza modificare codice: vale per le pagine prodotto, le collezioni, il blog, le pagine personalizzate. L'architettura introduce anche i 'blocchi app' (app blocks) e, nei temi più recenti, i 'blocchi di tema' (theme blocks), che permettono alle app di terze parti di aggiungere contenuto direttamente dentro le sezioni del tema tramite l'editor, invece di dover iniettare script tramite meccanismi meno controllabili. I metafield diventano nativamente collegabili ai blocchi tramite l'editor, senza scrivere codice. Per un merchant, il vantaggio pratico dell'OS 2.0 è una maggiore autonomia nel personalizzare il layout dello store senza dover coinvolgere uno sviluppatore per ogni piccola modifica strutturale, mantenendo però la possibilità di intervenire nel codice Liquid quando serve una personalizzazione più profonda.

Una Theme App Extension è il meccanismo ufficiale con cui un'app Shopify inserisce contenuto o funzionalità direttamente dentro un tema Online Store 2.0, sotto forma di 'app block' (un blocco che il commerciante aggiunge e posiziona dentro una sezione tramite l'editor del tema, come farebbe con un blocco nativo) o di 'app embed' (un blocco attivabile globalmente, per esempio un widget flottante visibile su tutte le pagine). Il codice dell'estensione vive in un pacchetto separato gestito dall'app, non modifica direttamente i file del tema del commerciante: quando l'app viene disinstallata, il suo blocco smette semplicemente di essere disponibile, senza lasciare codice orfano dentro il tema. È questo il motivo per cui è il meccanismo preferito da Shopify rispetto all'iniezione diretta di script nel tema: è isolato, reversibile e visibile al commerciante nell'editor, che decide dove posizionarlo e può rimuoverlo in qualsiasi momento. Le Theme App Extension hanno un limite tecnico di dimensione sul contenuto Liquid complessivo dei blocchi (100 KB), pensato per evitare che un'estensione appesantisca il tema in modo incontrollato.

Un metafield è un campo di dati aggiuntivo che si può collegare a una risorsa Shopify già esistente — un prodotto, una collezione, una pagina, un cliente, l'intero negozio — per memorizzare un'informazione che i campi nativi della piattaforma non prevedono: per esempio le specifiche tecniche di un prodotto o un testo di garanzia specifico per una categoria. Ogni metafield ha una definizione (il tipo di dato che contiene: testo, numero, immagine, riferimento a un'altra risorsa) e un valore per ogni singola risorsa a cui è applicato. Nei temi Online Store 2.0, i metafield si collegano ai blocchi del tema direttamente dall'editor, senza scrivere codice, oppure si richiamano da codice Liquid personalizzato per un controllo più fine sul rendering. È lo strumento nativo con cui evitare di installare un'app dedicata solo per aggiungere un campo dati aggiuntivo alle schede prodotto: la differenza pratica rispetto a un Metaobject è che il metafield resta sempre 'attaccato' a una risorsa esistente, mentre il Metaobject è un tipo di dato autonomo con una propria struttura.

Un Metaobject è un tipo di dato personalizzato e autonomo su Shopify, con una propria struttura e proprie voci (i record effettivi), che non dipende dall'essere collegato a una risorsa nativa preesistente come invece avviene per un metafield. È utile quando serve modellare un'entità che la piattaforma non prevede nativamente e che può essere collegata a più risorse contemporaneamente: per esempio la scheda di un designer o di un brand, collegabile a molti prodotti diversi, o le voci di una tabella di taglie condivisa da un'intera collezione. Il vantaggio pratico è la centralizzazione: se l'informazione cambia, si modifica una sola volta nel Metaobject e la modifica si riflette automaticamente ovunque quella voce sia referenziata, invece di dover aggiornare lo stesso dato ripetuto su ogni singola pagina prodotto. Come i metafield, i Metaobject possono essere collegati ai blocchi del tema dall'editor senza scrivere codice, oppure richiamati da Liquid personalizzato: sono spesso proposti come alternativa nativa alle app che gestiscono 'campi personalizzati' o piccoli database di contenuto per il tema.

Shopify Functions è il meccanismo con cui gli sviluppatori possono personalizzare la logica di backend di Shopify (per esempio sconti automatici, regole di validazione del carrello, opzioni di spedizione, personalizzazioni del metodo di pagamento) scrivendo codice eseguito direttamente sull'infrastruttura di Shopify, in un ambiente sandbox isolato e ad alte prestazioni (WebAssembly), invece che tramite script eseguiti nel browser del cliente o su un server esterno gestito dal merchant. Ha progressivamente sostituito Shopify Scripts, il precedente sistema (basato su un linguaggio derivato da Ruby) che permetteva personalizzazioni simili ma con meno garanzie di stabilità e prestazioni, ed era disponibile solo su piani Shopify Plus. Le Shopify Functions si scrivono tipicamente in linguaggi che compilano verso WebAssembly (per esempio Rust, AssemblyScript, o JavaScript tramite una toolchain dedicata) e vengono distribuite come parte di un'app. Per un merchant, il beneficio pratico è che la logica personalizzata gira in modo affidabile e verificato da Shopify stessa, invece che tramite codice iniettato manualmente e più fragile.

Checkout Extensibility è l'architettura con cui Shopify permette di personalizzare il checkout tramite estensioni (Checkout UI Extensions) sviluppate e distribuite come app, invece che modificando direttamente il file di layout del checkout (il precedente approccio, basato su checkout.liquid, oggi dismesso). Le personalizzazioni — per esempio un campo aggiuntivo nel form, un banner informativo, un upsell nella pagina di riepilogo — vengono eseguite in un ambiente isolato (sandbox) separato dal codice centrale del checkout: un errore in un'estensione non può bloccare l'intero processo di acquisto, e gli aggiornamenti che Shopify rilascia al checkout non rischiano di rompere le personalizzazioni esistenti, perché restano su binari separati. Per i merchant che in passato avevano investito nella personalizzazione diretta del vecchio checkout.liquid, la migrazione verso Checkout Extensibility ha comportato la necessità di ricostruire quelle personalizzazioni sotto forma di estensioni, un lavoro di sviluppo puntuale ma non evitabile, dato che Shopify ha dismesso il vecchio meccanismo. Il beneficio è un checkout più stabile nel tempo e meno esposto a conflitti tra script di provenienza diversa nello stesso punto critico del funnel di vendita.

Con 'B2B nativo' si indicano le funzionalità di vendita all'ingrosso — cataloghi dedicati per singole aziende clienti, listini prezzi differenziati, termini di pagamento posticipati, regole di quantità minima e price break per volume — integrate direttamente nella piattaforma Shopify, senza dover ricorrere ad app di terze parti o a una piattaforma separata per gestire le vendite all'ingrosso accanto a quelle al dettaglio. Storicamente queste funzionalità erano riservate al piano Shopify Plus; nel tempo Shopify le ha rese disponibili in modo crescente anche sui piani standard (Basic, Shopify, Advanced), riducendo la necessità per una PMI di passare a un piano enterprise solo per attivare un canale B2B. Dal punto di vista tecnico, il modo corretto di verificare se applicare prezzi o regole B2B a un cliente non è controllare genericamente 'se il cliente è un'azienda', ma controllare se sono effettivamente presenti dati di prezzo o regole di quantità configurati per quel cliente: è il dato configurato, non il tipo di cliente in astratto, a determinare cosa mostrare.

Per Agentic Commerce si intende l'insieme di transazioni in cui un assistente basato su intelligenza artificiale (un 'agente AI', per esempio integrato in ChatGPT o in un altro assistente conversazionale) opera per conto di una persona: cerca un prodotto secondo criteri specifici, confronta alternative tra più negozi, e in alcuni scenari arriva a completare l'acquisto, con l'utente che interviene solo per confermare o definire i vincoli iniziali della richiesta. È un cambiamento nel modo in cui un potenziale cliente può raggiungere uno store: non solo un visitatore umano che naviga pagine e clicca bottoni, ma anche un agente automatico che deve poter leggere ed estrarre correttamente le informazioni di un catalogo (disponibilità, prezzo, caratteristiche del prodotto) in modo affidabile, di solito tramite dati strutturati e API, non tramite l'interpretazione visiva di una pagina pensata per un umano. Per un merchant Shopify, prepararsi all'Agentic Commerce significa in pratica avere dati di prodotto corretti e strutturati (schema markup, feed, metafield coerenti), più che progettare un'interfaccia visiva dedicata. È un'area ancora in evoluzione, non uno standard tecnico consolidato in ogni sua parte.

Con AI Search (o ricerca generativa) si indicano le funzionalità dei motori di ricerca che, invece di restituire un semplice elenco di link, generano una risposta sintetica scritta a partire da più fonti, spesso citando o linkando alcune di esse: l'esempio più noto è Google AI Overviews (in precedenza in fase sperimentale come SGE — Search Generative Experience), oltre ai motori di risposta conversazionali come Perplexity o alla funzione di ricerca integrata in ChatGPT. Per un sito, essere citato in una risposta generativa non dipende dagli stessi segnali della ricerca tradizionale: conta meno il posizionamento in classifica e conta di più la chiarezza e verificabilità del contenuto, la presenza di dati strutturati che rendono espliciti i fatti chiave, e la coerenza dell'informazione su tutto il sito. Una parte crescente delle ricerche degli utenti, specialmente quelle con intento informativo, si conclude oggi senza un click verso nessun sito (le cosiddette ricerche 'zero-click'), perché la risposta generata è già sufficiente: questo rende ancora più importante che, quando un motore generativo cita una fonte, quella fonte sia corretta e riconoscibile come autorevole sull'argomento.

Consent Mode v2 è la versione aggiornata del meccanismo di Google che permette a un sito di comunicare a Google Ads, Google Analytics e agli altri tag Google lo stato del consenso espresso da un utente (per esempio tramite un banner cookie) rispetto al trattamento dei dati per la pubblicità e la personalizzazione. A differenza della versione precedente, Consent Mode v2 introduce due nuovi parametri di consenso dedicati, diventati un requisito per i merchant che operano nello Spazio Economico Europeo e usano gli strumenti pubblicitari di Google. Su Shopify, questo si integra tipicamente attraverso una piattaforma di gestione del consenso (per esempio Iubenda) che si collega ai tag Google installati sullo store: se l'integrazione non è configurata correttamente, i segnali di consenso non vengono trasmessi, e le piattaforme pubblicitarie ricevono dati incompleti o distorti sulle conversioni reali, il che può falsare le decisioni di ottimizzazione delle campagne pubblicitarie. È quindi un tema di compliance (in ambito GDPR/ePrivacy) con un impatto tecnico diretto sulla qualità dei dati di marketing, non solo un requisito legale isolato.