Immagina un negozio in cui ogni dashboard sembra a posto. La homepage è indicizzata, Lighthouse è verde e il validatore dei dati strutturati non mostra errori. Ma nello stesso momento, il prezzo su Google Shopping non corrisponde al prezzo nel carrello, il pannello dei filtri mobile intrappola gli utenti da tastiera e ogni acquisto viene registrato due volte.
Niente di tutto questo emerge da un rapido controllo di salute. Il motivo è che un negozio online è un sistema interconnesso, non una semplice raccolta di pagine. I dati di prodotto confluiscono nella pagina, nei dati strutturati e nei feed shopping. Script e tag di terze parti determinano la velocità di caricamento. Il checkout trasforma l’interesse in ricavi e l’analytics dovrebbe registrare accuratamente l’intero percorso. Quando una parte si rompe, può distorcere silenziosamente tutto il resto.
Ecco perché un audit e-commerce utile segue l’acquirente, non la sitemap. La checklist che segue inizia dalla scoperta del negozio e termina con un ordine completato. Ti darà un elenco ordinato per priorità di problemi reali, ognuno con prove, un responsabile e un test chiaro per stabilire quando è risolto.
Quando eseguire questo audit e perché l’ordine conta
Esegui l’audit completo quando prendi in carico un nuovo cliente e-commerce, dopo un restyling o una migrazione di piattaforma, prima di una grande spinta alla crescita, o quando un controllo di routine fa emergere un peggioramento su tutto il negozio. Metti da parte da tre a sei ore per un passaggio leggero, oppure da uno a due giorni per un audit standard che testa adeguatamente ogni template importante. Le indagini approfondite su log, feed o analytics di solito richiedono tempo separato.
L’ordine è deliberato. Non ha senso giudicare l’attrito nella conversione se Google non riesce a indicizzare le pagine di categoria, e non ha senso fidarsi del report sul funnel se il tag di acquisto viene attivato due volte.
Un evento di acquisto duplicato non è prova di più vendite, e una pagina prodotto veloce non è sana se il prezzo che vede Google è diverso dal prezzo nel carrello. Ecco perché l’audit procede per fasi. Inizia dalla prima scoperta, poi passa alla veridicità dei dati di prodotto, alla velocità e all’acquisto stesso, e solo alla fine passa alla misurazione.
Prima di iniziare, raccogli ciò che ti serve. Ovvero l’accesso a:
- Search Console,
- Analytics,
- Tag manager,
- Catalogo o sorgente del feed,
- Merchant Center,
- un elenco delle modifiche recenti al sito.
Fase 1: i motori di ricerca riescono a trovare il catalogo?
1. Costruisci un campione che rappresenti l’intero negozio
La maggior parte dei bug e-commerce si annida nei template condivisi e negli stati di prodotto insoliti. Una homepage pulita non ti dice nulla sulle categorie filtrate, sulla logica delle varianti, sui prodotti esauriti o sul checkout. Per questo dovresti iniziare confermando di stare testando il sito di produzione live nel mercato, nella valuta e nella lingua corretti. Poi scegli almeno un URL per ciascuno di questi:
- la homepage
- una categoria prioritaria
- una categoria più profonda o una pagina di filtro approvata
- un prodotto tipico
- un prodotto con varianti
- un prodotto esaurito o fuori produzione
- una pagina di risultati della ricerca interna, inclusa una che non restituisce risultati
- il carrello, il checkout e la pagina di conferma dell’ordine
Aggiungi un esempio problematico o insolito per ogni template che sembra a rischio. Il report delle landing page in analytics e un export del catalogo ti aiuteranno a scegliere.
Hai finito quando ogni template importante e ogni stato del checkout ha un URL di test assegnato, e tutto ciò che non hai potuto testare è contrassegnato come “non testato”.
2. Controlla scansionabilità, indicizzazione, canonical e sitemap
Se il percorso di scansione è rotto, pubblicare altri prodotti non farà altro che moltiplicare il numero di URL interessati. I segnali contrastanti rendono anche i problemi più difficili da diagnosticare. Le regole robots.txt possono dire una cosa, mentre i tag canonical e la sitemap possono dirne una completamente diversa.
Rivedi robots.txt, le sitemap XML, i codici di risposta, i meta tag e gli header robots, i tag canonical, la paginazione e i link interni. Usa URL Inspection in Search Console per vedere quale canonical Google ha effettivamente scelto per le tue pagine campione. Poi confronta la sitemap con la realtà. Dovrebbe elencare pagine attive e indicizzabili che restituiscono uno stato 200, non redirect, errori, pagine con noindex o duplicati.
Hai finito quando le tue landing page previste restituiscono 200, sono scansionabili, seguono una politica coerente di canonical e indicizzazione e compaiono nella sitemap. Ogni esclusione significativa dovrebbe avere una spiegazione o un responsabile.
3. Segui i link: redirect, errori e JavaScript
Un negozio può sembrare completo in un browser mentre i crawler e le tecnologie assistive vedono una versione molto più scarna. Esegui un crawler per trovare link interni rotti, catene di redirect, loop e soft 404. Poi confronta la pagina renderizzata con l’HTML grezzo. Le card prodotto, la paginazione, i breadcrumb e i link di categoria dovrebbero essere reali e scansionabili, e i contenuti importanti non dovrebbero dipendere solo dal JavaScript.
Hai finito quando i link interni puntano direttamente alla loro destinazione finale, le pagine di errore restituiscono il codice di stato corretto e i prodotti prioritari sono raggiungibili senza dipendere dallo scroll infinito.
4. Testa categorie, filtri, paginazione e ricerca interna
I sistemi di categorie e filtri possono creare trappole di scansione per i motori di ricerca e frustrazione per gli acquirenti allo stesso tempo. Una pagina può essere tecnicamente indicizzabile e restare una landing page debole se metà dei prodotti che contiene è irrilevante.
Prova i filtri su desktop e mobile. Controlla selezione multipla, “cancella tutto”, conteggi dei risultati, ordinamento, paginazione o “carica altro” e combinazioni di filtri che non restituiscono nulla. Guarda gli URL che i filtri generano e confrontali con la politica di indicizzazione del negozio. Nota anche se un lungo blocco di testo di categoria spinge la griglia dei prodotti sotto la piega.
Hai finito quando i controlli si comportano in modo coerente, le combinazioni casuali di filtri non diventano landing page accidentali e gli acquirenti possono annullare un filtro senza perdere la loro posizione.
Pronto a far crescere il tuo business?
Inizia oggi la tua prova gratuita e vedi i risultati in pochi giorni.
Fase 2: i dati di prodotto dicono la verità?
5. Riconcilia identità del prodotto, prezzo, disponibilità e varianti
Un campo sbagliato non solo può fuorviare un acquirente, ma può arrivare a causare una discrepanza al checkout. Allo stesso tempo, i dati possono essere formattati perfettamente e comunque essere sbagliati.
Per una manciata di prodotti rappresentativi, confronta nome, marca, SKU, GTIN o EAN, variante selezionata, prezzo, valuta, disponibilità, immagini e specifiche chiave ovunque compaiano. Controlla ciò che viene mostrato nella pagina, nei dati strutturati, nel feed merchant, nel carrello e al checkout. Includi articoli in saldo, varianti, prodotti esauriti, preordini e prodotti fuori produzione.
Hai finito quando i dati campionati coincidono su ogni superficie e ogni differenza intenzionale, come marca contro produttore, è esplicita nel modello dati.
6. Convalida i dati strutturati rispetto a ciò che vedono gli acquirenti
I dati strutturati aiutano solo quando descrivono la pagina con precisione. Un validatore accetterà senza problemi “InStock” mentre la pagina e il checkout dicono entrambi che il prodotto non è disponibile. Ecco perché dovresti far passare ogni stato di prodotto attraverso il Google Rich Results Test o lo Schema.org Validator. Poi confronta i valori del markup con il contenuto visibile e il feed di origine. Per i prodotti con varianti, verifica che il tuo approccio di markup e la configurazione dei canonical corrispondano a come le pagine sono effettivamente costruite.
Hai finito quando le pagine campione idonee non hanno proprietà obbligatorie mancanti, il markup corrisponde a ciò che è visibile e recensioni e valutazioni sono marcate solo quando gli acquirenti possono vederle su quel prodotto.
Fase 3: il negozio è veloce per gli acquirenti reali?
7. Misura prima i Core Web Vitals dai dati sul campo
I dati degli utenti reali e una singola esecuzione di Lighthouse rispondono a domande diverse. Lighthouse ti aiuta a riprodurre un problema, ma non può dirti se gli acquirenti reali superano o falliscono la prova.
Inizia con PageSpeed Insights e il report Core Web Vitals in Search Console. Annota se esistono dati sul campo per l’URL esatto o solo per l’intero sito. Le soglie “buone” di Google, misurate al 75° percentile, sono:
- LCP (caricamento): 2,5 secondi o meno
- INP (reattività): 200 millisecondi o meno
- CLS (stabilità visiva): 0,1 o meno
Guarda separatamente mobile e desktop. Se non ci sono dati sul campo, registra il risultato come sconosciuto e considera i risultati di laboratorio come provvisori. Sconosciuto non è la stessa cosa di verde.
Hai finito quando ogni template prioritario ha un verdetto sul campo per dispositivo, o un’assenza di dati dichiarata chiaramente, con fonte e intervallo di date registrati.
8. Trova la causa, non solo il punteggio
Consigli generici come “comprimi le immagini” o “riduci il JavaScript” spesso mancano il vero collo di bottiglia e creano lavoro che non sposta la metrica in difficoltà. Trova l’elemento, la richiesta o lo script specifico responsabile.
Identifica l’elemento LCP e cosa lo ritarda. Poi controlla i sospetti abituali, come il dimensionamento delle immagini, il lazy-loading sulle immagini above-the-fold, il CSS che blocca il rendering, il caricamento dei font, gli script di terze parti, i long task, la cache, il tempo di risposta del server, le fonti di layout shift e i tag caricati due volte.
Esegui test ripetuti nelle stesse condizioni e confronta una statistica coerente, non la tua esecuzione migliore. Ricorda che il Total Blocking Time è un segnale di laboratorio utile, ma non è l’INP.
Hai finito quando ogni risultato significativo sulle prestazioni indica la metrica in difficoltà, il template interessato, una causa riproducibile e un responsabile.
Iscriviti alla nostra newsletter
Ricevi gratuitamente gli ultimi consigli, tendenze e offerte.
Fase 4: le persone riescono davvero a comprare qualcosa?
9. Testa usabilità e accessibilità mobile sui controlli di acquisto reali
I punteggi automatici non coprono ogni interazione. Un negozio può superare una scansione mentre il pannello dei filtri intrappola il focus da tastiera, il banner dei cookie copre il pulsante aggiungi al carrello o il selettore di taglia non ha un’etichetta accessibile.
Testa a larghezze telefono da 360 a 390 pixel, ingrandisci il testo e prova l’intero percorso solo con la tastiera. Osserva l’ordine e la visibilità del focus in menu, pannelli e finestre di dialogo. Verifica che etichette, pulsanti, errori dei form e aree toccabili abbiano ancora senso.
Hai finito quando un acquirente riesce a completare il percorso principale senza controlli nascosti o trappole di focus, e nulla su mobile nasconde prezzo, disponibilità, scelta della variante, pulsante aggiungi al carrello o checkout.
10. Esegui carrello e checkout come test controllato
Un pulsante checkout visibile non prova che il checkout funzioni. I bug del checkout sono incidenti commerciali e minano anche la tua analytics.
Per testarlo, aggiungi al carrello un prodotto normale e una variante. Cambia la quantità, rimuovi un articolo e applica un coupon (o uno volutamente non valido) se ne hai uno. Poi testa il checkout come ospite e con account, le opzioni di spedizione, la selezione del pagamento, gli errori di validazione, il pulsante indietro e il layout mobile. Usa un ordine di test o un percorso approvato che non addebita nulla. Non effettuare mai un ordine reale senza autorizzazione.
Hai finito quando l’acquisto si completa o raggiunge il confine di test concordato, i totali restano corretti, i messaggi di errore dicono alle persone cosa fare e ogni percorso bloccato è documentato con prove e impatto sul business.
Fase 5: stai misurando correttamente il percorso?
11. Verifica analytics, tag duplicati e consenso
I tag duplicati gonfiano le visualizzazioni di pagina, gli eventi di aggiunta al carrello e gli acquisti. Valori mancanti o malformati rendono i report sui ricavi poco sicuri su cui basare le decisioni. L’obiettivo è semplice: un’azione dell’acquirente dovrebbe produrre un evento, con il prodotto, il valore, la valuta, l’ID transazione e lo stato di consenso corretti.
Elenca ogni contenitore del tag manager, Google tag, pixel pubblicitario, script di affiliazione e integrazione server-side. Poi, in una sessione controllata, traccia view_item, add_to_cart, begin_checkout e purchase. Confronta ciò che invia il browser con GA4 DebugView e il record dell’ordine nel backend. Testa prima e dopo che l’acquirente esprime una scelta di consenso.
Hai finito quando ogni azione attiva il suo evento esattamente una volta, gli acquisti portano un ID transazione stabile, valori e valuta si riconciliano con il backend e i tag non essenziali rispettano la politica di consenso.
12. Riconcilia Search Console e Merchant Center con quanto hai trovato
Un test locale della pagina non può mostrarti ogni canonical indicizzato, avviso della sitemap, prodotto disapprovato o query di ricerca persa. Un avviso nella dashboard, d’altro canto, potrebbe descrivere un problema già risolto.
Ispeziona i tuoi URL prioritari in Search Console, rivedi i report sui prodotti e sui merchant listing e confronta la diagnostica di Merchant Center con ciò che hai visto sul sito live. Annota le date, perché la nuova scansione e l’elaborazione dei feed sono in ritardo rispetto ai deploy.
Hai finito quando ogni problema significativo della dashboard corrisponde a prove live o è contrassegnato come in attesa di propagazione, e ogni problema aperto ha un responsabile.
Fase 6: un acquirente si fiderebbe di questo negozio?
13. Controlla i segnali di fiducia, i dettagli di contatto, la spedizione e i resi
Informazioni commerciali nascoste o contrastanti fanno esitare gli acquirenti e aumentano i ticket di assistenza. Confronta header e footer, pagina contatti, checkout e pagine delle policy.
Hai finito quando l’identità dell’azienda è chiara, le dichiarazioni su spedizione, resi e pagamenti concordano lungo tutto il percorso e nessun badge di fiducia è non verificabile.
14. Controlla HTTPS, mixed content e igiene del front-end
Non è un penetration test, ma una questione di igiene di base dei dati. Conferma che HTTP reindirizzi a HTTPS in un solo salto, che il certificato sia valido, che non ci sia mixed content e che i form vengano inviati correttamente. Controlla la console per errori gravi. Se qualcosa sembra una vera vulnerabilità di sicurezza, passalo a uno specialista invece di diagnosticarlo da un avviso generico.
Hai finito quando le pagine prioritarie e il checkout si caricano in modo sicuro, i redirect richiedono un solo salto e i form si comportano come previsto.
Dai risultati alle correzioni
15. Trasforma i risultati in una coda di correzioni con responsabili
Un audit che si conclude con screenshot o un punteggio non riduce il rischio. Cinquanta sintomi causati da un singolo template rotto non dovrebbero diventare cinquanta ticket scollegati. Raggruppa i risultati per causa radice. Annota se si tratta del componente, del template, della regola del feed o della configurazione del tracking. Conserva gli URL interessati come prova. Poi assegna le priorità:
- P0: un guasto attivo che blocca il business, o un problema critico su tutto il sito
- P1: un difetto significativo di cui sei sicuro
- P2: un problema importante con ambito limitato
- P3: un miglioramento da monitorare
Hai finito quando ogni risultato significativo ha un responsabile, una data di scadenza, un test per “risolto” e una data per ricontrollarlo dopo il rilascio.
Il documento finale
Consegna un documento o un foglio di calcolo versionato con una riga per ogni risultato e un breve riepilogo in cima. Ogni riga dovrebbe coprire:
- Il comportamento,
- il comportamento atteso,
- gli URL interessati,
- le prove e quando le hai raccolte,
- gravità e livello di confidenza,
- la probabile causa,
- la correzione consigliata,
- il responsabile e il test che prova che è fatto.
Ma ricorda che non dovresti segnare un problema come risolto solo perché qualcuno ha chiuso il ticket. Segnalo come verificato quando il test passa in produzione.
Strumenti per il lavoro
Non hai bisogno di alcun abbonamento per eseguire con successo un primo passaggio solido. Ti servono solo questi strumenti gratuiti:
- Google PageSpeed Insights per i dati sul campo (dove disponibili) e la diagnostica di Lighthouse
- Google Search Console per indicizzazione, sitemap, URL Inspection, Core Web Vitals e report sui dati strutturati
- Google Rich Results Test e lo Schema.org Validator per i dati strutturati
- Chrome DevTools e Lighthouse per controlli su rete, prestazioni, layout shift, accessibilità e console
- Google Tag Assistant e GA4 DebugView per il tracciamento degli eventi
- SSL Labs Server Test per la configurazione TLS
Se vuoi una scorciatoia, AmICited ti permette di riunire tutte queste prove e conservare la baseline per dopo. La vista Performance Impact confronta i template per LCP, INP, CLS e tempo di risposta del server. URL Inspection e Sitemaps and Indexing monitorano l’indicizzazione degli URL prioritari. Products e Assortment mostrano quali parti del catalogo hanno il maggior peso commerciale. Le annotazioni nel Reports Hub collegano ogni rilascio a ciò che è accaduto dopo. Gli strumenti forniscono le prove. Il titolare del negozio, lo sviluppatore o l’analista decide comunque cosa è corretto e quali compromessi sono accettabili.
Dopo l’audit
Invia ogni problema confermato al flusso di lavoro specialistico che può chiuderlo: problemi di scansione e rendering a un audit SEO tecnico , fallimenti di prestazioni sul campo alla correzione dei Core Web Vitals , problemi di facet e stato delle scorte a una revisione di categorie e prodotti , e i problemi di tracciamento a chi si occupa di analytics.
Non serve rieseguire l’intero audit dopo ogni correzione. Ritesta l’area interessata, annota il rilascio per poter vedere cosa è cambiato dopo e lascia che il controllo di salute periodico intercetti il prossimo peggioramento.
Torniamo al negozio dove tutto sembrava a posto
Ricordi il negozio dell’inizio? La sua homepage era indicizzata, Lighthouse era verde e il validatore era pulito. Eppure Google Shopping mostrava il prezzo sbagliato, il pannello dei filtri intrappolava gli utenti da tastiera e ogni vendita veniva contata due volte.
Nessuna dashboard segnalava nulla di tutto ciò. Questa checklist avrebbe intercettato tutti e tre i problemi: la discrepanza di prezzo al punto 5, la trappola di focus al punto 9 e l’acquisto contato due volte al punto 11. Ognuno si rompe da qualche parte lungo il percorso dell’acquirente, ed è esattamente lì che guarda l’audit.
Ecco cosa ottieni seguendo l’acquirente invece della sitemap. Smetterai di chiederti “il sito sembra sano?” e inizierai a porti quattro domande più difficili. Le persone riescono a trovare il prodotto? È vero ciò che il negozio dice al riguardo? Riescono davvero a comprarlo? E riesci a vedere che l’hanno fatto? Un negozio che può rispondere sì a tutte e quattro è in forma migliore di uno con un punteggio perfetto.
Quindi scegli i tuoi URL campione, ritagliati il tempo necessario e inizia dalla Fase 1. Il primo passaggio è il più lento. Dopo, il lavoro consiste soprattutto nell’assicurarsi che ciò che hai corretto resti corretto.
