SEO tecnico Magento: checklist per performance e vendite

A chi serve questa checklist (e quando Magento diventa “troppo”)

• Microimprese green che usano l’e-commerce come canale principale e vogliono una lista di controlli pratici per non perdere vendite per lentezza, errori tecnici o pagine duplicate.
• Team piccoli con un developer esterno: ti serve capire cosa verificare, cosa chiedere e cosa non toccare “a caso”.
• Store già online su Adobe Commerce (Magento) che vedono cali di traffico, indicizzazione instabile, o prodotti che non compaiono bene su Google.
• Chi sta migrando o rifacendo tema e vuole evitare di portarsi dietro problemi strutturali (URL, filtri, performance).
• Quando Magento diventa “troppo”: se il sito è lento per tema ed estensioni, se non hai supporto tecnico continuativo, o se ogni modifica richiede giorni e rischi SEO, serve un piano di semplificazione e priorità (non “aggiungere un altro Plugin”).

Le 5 priorità SEO tecniche che muovono davvero vendite e visibilità

1. Velocità e stabilità: se le pagine caricano lentamente o “saltano”, peggiorano conversioni e scansione. In un e-commerce, questo è spesso il primo collo di bottiglia.

2. Crawl efficiente: Google deve trovare categorie e prodotti senza perdersi in pagine inutili. Se sprechi percorsi di scansione, indicizzi meno (o peggio) quello che conta.

3. Duplicazioni: varianti, URL rewrite e percorsi alternativi possono generare più versioni della stessa pagina. Risultato: segnali SEO “diluiti” e confusione per i motori.

4. Dati strutturati prodotto: aiutano Google a capire prezzo, disponibilità e attributi. Oggi servono anche per essere “leggibili” nelle esperienze di ricerca guidate dall’AI.

5. Filtri e paginazione: la navigazione a faccette può creare migliaia di URL sottili o duplicati. Va gestita per proteggere categorie strategiche e mantenere la scansione sotto controllo.

Velocità e stabilità (Core Web Vitals)

Per una microimpresa green, la velocità non è “solo tecnica”: è anche sostenibilità operativa. Un sito lento costa tempo, budget e vendite. Con Adobe Commerce (Magento) la performance dipende molto da Hosting, cache, tema ed estensioni.

Priorità operative:

• mettere in sicurezza caching e asset (immagini e script) prima di ottimizzare “a mano” le singole pagine
• ridurre il peso di Javascript e dei moduli non indispensabili
• verificare che su mobile il contenuto chiave sia completo e rapido (Google scansiona in logica mobile-first)

Crawl efficiente (Google deve “trovare” il catalogo)

Immagina Google come un corriere che entra in magazzino: se trova corridoi infiniti (filtri, parametri, duplicati), impiega più tempo e visita meno scaffali utili. L’obiettivo è far emergere categorie e prodotti principali con percorsi chiari.

• struttura categorie semplice e coerente
• link interni che portino davvero alle aree più importanti del catalogo
• contenuti e link principali disponibili su mobile, senza dipendere da caricamenti “solo via script”

Duplicazioni (canonicals, URL rewrite, varianti prodotto)

In Magento le duplicazioni sono frequenti: varianti indicizzate, URL diversi per lo stesso prodotto, percorsi con categorie e senza categorie. La regola è: una pagina ufficiale per ogni entità importante (prodotto o categoria), le altre versioni devono consolidare segnali verso quella principale.

• usare canonical coerenti e renderizzati lato server
• gestire rewrite e redirect per impedire che riemergano percorsi “fantasma”
• decidere una strategia chiara su varianti (semplici vs configurabili)

Dati strutturati prodotto (schema)

Magento offre una base, ma spesso non basta. I dati strutturati sono una “scheda prodotto leggibile dalle macchine”: prezzo, stock, marca, identificativi, varianti. Questo aumenta chiarezza per Google e migliora l’idoneità a risultati arricchiti e a sistemi di ricerca che estraggono e riassumono informazioni.

Filtri e paginazione (faceted navigation)

I filtri aiutano le persone a trovare rapidamente (taglia, materiale, prezzo), ma possono generare un numero enorme di URL. Nel 2026 il punto non è “nascondere tutto”, ma gestire i percorsi di scansione: far indicizzare ciò che ha valore stabile e bloccare o de-enfatizzare ciò che crea duplicazione o pagine sottili.

Performance: cosa controllare prima di “toccare il sito”

• Fai prima una fotografia: una o due pagine prodotto, una categoria, home e checkout. Se misuri dopo ogni cambiamento, capisci cosa ha funzionato e cosa no.

• Non iniziare dai dettagli (micro-ottimizzazioni) se mancano basi come cache o immagini moderne: rischi di perdere giorni senza risultati.

• Ogni estensione in più è potenzialmente più JavaScript, più richieste e più complessità. In Magento è una delle cause più comuni di rallentamenti.

Hosting e stack minimo consigliato (PHP/MySQL, CDN)

Magento 2 può andare forte, ma pretende uno stack adeguato. A livello pratico, chiedi al tuo Provider o developer di confermare:

• runtime aggiornato (ad esempio PHP 8+) e database moderno (ad esempio MySQL 8) per performance e sicurezza
• CDN attivo per servire immagini, CSS e JavaScript velocemente anche fuori dalla tua area geografica
• risorse e configurazione coerenti con il traffico (soprattutto in campagne o picchi stagionali)

Frase copiabile per il developer: “Confermi stack PHP 8+ e MySQL 8, CDN per asset statici e configurazione pronta per picchi, senza degradare TTFB e stabilità su mobile?”

Caching: Full Page Cache, Varnish, Redis (in parole semplici)

Il caching è come preparare in anticipo i contenuti più richiesti, invece di ricucinarli ogni volta. Su Adobe Commerce le leve tipiche sono:

• Full Page Cache: salva pagine complete per servirle più rapidamente
• Varnish: accelera la consegna delle pagine cache, utile per prestazioni costanti
• Redis: velocizza la gestione di cache e sessioni, riducendo carichi inutili

Frase copiabile per il developer: “Abbiamo Full Page Cache correttamente attiva e coerente con Varnish e Redis? Possiamo verificare che le pagine categoria e prodotto vengano servite da cache dove possibile?”

“Sito pesante”: tema e extension che rallentano

Spesso non è “Magento lento”, ma una combinazione di tema ricco e troppi moduli. Alcune verifiche pratiche:

• elenca estensioni attive e chiedi quali sono davvero indispensabili al business
• controlla se alcune funzioni sono duplicate (due moduli per la stessa cosa)
• riduci elementi che aumentano complessità della pagina (slider multipli, pop-up invasivi, widget ovunque)

Frase copiabile per il developer: “Possiamo fare un audit delle estensioni per impatto su JavaScript e complessità della pagina, e disattivare ciò che non è critico per vendite o compliance?”

Immagini e asset: WebP/AVIF + lazy load

Le immagini sono spesso la parte più “pesante” di un catalogo. Interventi ad alto impatto:

• convertire in formati moderni come WebP o AVIF dove possibile
• attivare lazy loading per immagini e contenuti sotto la piega, così la prima schermata si carica prima
• verificare che le immagini non vengano caricate più grandi del necessario (dimensioni coerenti con il layout)

Come misurare senza essere tecnici (Lighthouse/PageSpeed)

Per non perdersi nei dettagli, misura sempre le stesse pagine e guarda tendenze, non “il voto perfetto”. Azioni semplici:

• usa Lighthouse o PageSpeed Insights su: home, una categoria, un prodotto, una pagina informativa
• ripeti dopo ogni intervento importante (tema, nuove estensioni, nuove funzioni)
• se i risultati peggiorano dopo un rilascio, fai rollback o correggi subito (non aspettare settimane)

Catalogo prodotti: come evitare doppioni tra varianti (semplici vs configurabili)

• Se vendi varianti (taglia, colore, stile), il rischio è creare molte pagine simili. Questo disperde segnali SEO e rende più difficile per Google capire qual è la pagina “ufficiale”.

• Obiettivo: una pagina principale forte e completa, e varianti gestite senza creare duplicazioni inutili.

Regola pratica: “pagina principale = prodotto configurabile”

In generale, la pagina che deve avere autorità è il prodotto configurabile. Le varianti (prodotti semplici) servono per gestione stock e opzioni, non per competere tra loro nei risultati di ricerca.

• la pagina configurabile raccoglie contenuti, recensioni e link interni
• le varianti evitano di creare pagine quasi identiche che si rubano visibilità

Canonical: cosa deve succedere (e cosa NON deve dipendere da JavaScript)

Il canonical è un’indicazione per dire a Google quale versione è quella principale. In Magento è fondamentale che:

• le varianti puntino in canonical alla pagina del configurabile, quando la variante non ha un intento di ricerca davvero distinto
• il canonical sia presente nel codice HTML servito dal server (non affidato a script che potrebbero non essere interpretati come previsto)
• ci sia coerenza tra canonical, link interni e Sitemap (tutti devono “spingere” la stessa versione ufficiale)

Avvertenza: modifiche a canonical, noindex o redirect possono far sparire pagine dall’indice. Se non sei sicuro, fai validare al developer e controlla in Search Console dopo il rilascio.

Quando indicizzare una variante (rari casi)

Indicizzare una variante ha senso solo quando esiste un intento di ricerca distinto e stabile. Esempi generici:

• la variante cambia la natura del prodotto in modo significativo (non solo colore), e le persone cercano proprio quella specifica versione
• la variante ha contenuto davvero diverso (specifiche, utilizzo, compatibilità) e non una descrizione copia-incolla
• la variante è disponibile in modo continuativo e non come micro-lotto temporaneo che genera pagine che diventano presto “esaurite”

Caveat: se scegli di indicizzare varianti, devi garantire che non esplodano in centinaia di pagine sottili. Serve una regola chiara e applicata in modo coerente su tutto il catalogo.

Titoli e contenuti on-page: template scalabili senza keyword stuffing

In Magento i titoli predefiniti sono spesso generici. Un buon lavoro on-page non significa “riempire di parole chiave”, ma creare titoli chiari e utili che scalano su molte schede prodotto, lasciando spazio a ottimizzare manualmente le pagine più importanti.

Template consigliato per title (con esempio pronto)

Un template semplice e scalabile:

[Tipo] [Attributo chiave] [Brand] [Variante]

Esempio pronto (adattalo al tuo catalogo):

Maglione lana blu navy da uomo Brand X taglia M

Indicazioni operative:

• usa attributi che aiutano davvero la scelta (materiale, taglia, uso, fit, certificazioni se pertinenti e verificabili)
• ottimizza manualmente i prodotti che portano più margine o hanno più domanda
• mantieni titoli leggibili: chiarezza prima di tutto

H1/H2: struttura pulita (utile anche per accessibilità)

Una struttura chiara aiuta utenti, Google e sistemi che “riassumono” contenuti:

• H1 unico: nome prodotto
• H2 per blocchi: descrizione, dettagli tecnici, materiali, cura e manutenzione, spedizione e resi, recensioni

Questo migliora anche l’accessibilità e riduce confusione nei temi che duplicano intestazioni o usano header per elementi grafici.

Dati strutturati prodotto: cosa includere per Google e per la ricerca “AI-driven”

• I dati strutturati rendono il tuo prodotto comprensibile: cosa è, quanto costa, se è disponibile, quali attributi lo definiscono.

• Quando i dati sono completi e coerenti, aumenti le probabilità di apparire con informazioni arricchite e riduci ambiguità per sistemi che estraggono e confrontano prodotti.

Campi “must-have” (prezzo, stock, brand, GTIN/SKU, attributi)

• Prezzo e valuta
• Disponibilità (in stock, out of stock)
• Brand
• SKU e, quando disponibili, identificativi come GTIN
• attributi utili e reali (materiale, taglia, colore), coerenti con ciò che l’utente vede in pagina

Nota operativa: controlla che i dati strutturati riflettano la realtà. In un brand green, la coerenza è anche reputazione: descrizioni e attributi devono essere verificabili, non promesse vaghe.

Perché serve anche se non fai “SEO avanzata”

Perché non è un “trucco”: è igiene informativa. Se la scheda prodotto è chiara e strutturata, Google la interpreta meglio, i comparatori e i sistemi di risposta estraggono dati in modo più affidabile, e gli utenti trovano più velocemente quello che cercano. Questo crea migliori condizioni tecniche per ranking e conversioni, senza promesse irrealistiche.

URL prodotti: puliti, stabili, un’unica versione “ufficiale”

• Un prodotto dovrebbe avere un solo URL principale. Se esistono più strade per arrivare allo stesso contenuto, rischi duplicazioni e segnali divisi.

• La stabilità è un investimento: cambiare URL spesso significa moltiplicare redirect e complessità.

Perché evitare URL basati sulle categorie (quando possibile)

Gli URL che cambiano in base al percorso categoria possono creare più versioni dello stesso prodotto. In molti casi è preferibile un URL di primo livello per il prodotto, sostenuto da:

• buon linking interno dalle categorie corrette
• canonical coerenti
• sitemap pulite

Questo riduce duplicazioni e rende più facile associare in modo stabile il prodotto alla sua “identità” online.

Duplicate path tipici (rewrite, /catalog/, numerazioni) e cosa chiedere al dev

Problemi frequenti:

• percorsi alternativi che riemergono dopo import massivi o configurazioni errate di riscrittura
• versioni di sistema che diventano accessibili (ad esempio percorsi tipo /catalog/)
• duplicati con numerazioni o URL quasi identici

Cosa chiedere al developer (brief copiabile):

• “Possiamo fare un audit delle rewrite per individuare duplicati e definire redirect permanenti verso l’URL canonico?”
• “Possiamo bloccare l’emersione di percorsi di sistema e mantenere una sola versione indicizzabile per prodotto?”
• “Confermi che canonical, sitemap e linking interno puntano tutti alla stessa versione?”

Filtri (faceted navigation): come non creare migliaia di pagine inutili

• I filtri sono utilissimi per l’utente, ma possono generare molte pagine sottili. L’obiettivo è proteggere le categorie importanti e non far “esplodere” l’indice.

• Strumenti diversi hanno effetti diversi: togliere dalla sitemap non equivale a noindex e noindex non equivale a bloccare via robots.

Regola pratica: i filtri aiutano gli utenti, ma non sempre Google

Regola semplice: fai in modo che i filtri funzionino bene per chi compra, ma non lasciare che Google sprechi tempo su combinazioni infinite. Alcuni filtri possono avere valore SEO, ma solo se rappresentano una selezione stabile e richiesta (non ogni combinazione possibile).

Cosa fare: sitemap, canonical, noindex/follow (quando serve)

Buone pratiche operative:

• Blocca gli URL filtro dalle sitemap XML: la sitemap deve contenere soprattutto categorie e prodotti ufficiali, non combinazioni
• Canonical verso la categoria principale quando il filtro non rappresenta una pagina che vuoi posizionare
• noindex, follow per pagine filtro che devono restare accessibili agli utenti ma non vuoi in indice
• evita di creare combinazioni infinite di parametri che generano pagine quasi vuote

Avvertenza: robots.txt, noindex e canonical non sono intercambiabili. Un errore può de-indicizzare aree importanti. Se non hai esperienza, fai validare la logica dal developer e controlla gli effetti in Search Console.

Parametri URL oggi: cosa usare al posto del vecchio “tool parametri” di GSC

Il vecchio strumento parametri in Search Console non è più la strada. Oggi la gestione passa soprattutto da:

• logica di canonical coerente
• regole di indicizzazione (noindex dove serve)
• controllo di link interni e sitemap (cosa spingi davvero a Google)
• regole robots con cautela, solo quando hai chiaro l’impatto

Filtri AJAX: ok, ma con fallback crawlable

I filtri in AJAX possono andare bene per l’esperienza utente, ma Google deve poter raggiungere i prodotti e, se decidi che alcune viste filtrate sono importanti, deve esistere un URL stabile e accessibile.

• prevedi pagine di fallback navigabili (link) per rendere il catalogo esplorabile ai bot
• se una vista filtrata è strategica (ad esempio una taglia molto cercata), assicurati che abbia un URL coerente e una gestione SEO dedicata

Paginazione e infinite scroll: come far scoprire tutto il catalogo

• La paginazione serve a far scoprire prodotti oltre la prima pagina. Se la gestisci male, rischi categorie invisibili in profondità.

• L’infinite scroll è comodo, ma va accompagnato da pagine accessibili anche ai bot.

Titoli/H1 unici e self-canonical per ogni pagina

Ogni pagina di una categoria paginata dovrebbe comunicare chiaramente che è una sezione distinta:

• title e H1 unici per pagina (ad esempio includendo il numero pagina in modo pulito)
• self-canonical su ogni pagina paginata, per evitare consolidamenti sbagliati

Questo aiuta Google a scoprire prodotti più in profondità e riduce rischio di pagine considerate duplicati.

Infinite scroll con pagine accessibili ai bot

Se usi infinite scroll:

• mantieni una paginazione tradizionale come fallback (pagine raggiungibili con link)
• assicura che i prodotti non siano visibili solo dopo interazioni che un bot potrebbe non eseguire come un utente

Controlli rapidi mensili (per non “perdere” SEO nel tempo)

• Magento cambia spesso perché si aggiungono prodotti, estensioni e contenuti. Senza controlli ricorrenti, è facile introdurre duplicazioni o rallentamenti.

• Questa mini-routine mensile ti aiuta a mantenere stabile la SEO tecnico Magento senza trasformarla in un progetto infinito.

Cosa guardare in Search Console (copertura, scansione, duplicati)

• Indicizzazione: pagine escluse, motivi ricorrenti (duplicati, canonical scelto da Google, soft 404)
• Scansione: segnali di aumento di URL con parametri o percorsi strani
• Sitemap: verifica che contenga solo URL ufficiali (prodotti e categorie principali)
• Core Web Vitals: trend e peggioramenti dopo rilasci o nuove estensioni

Quando fare log analysis (e quando no, per microimprese)

La log analysis è leggere i “registri” del server per capire cosa fa davvero Googlebot. È potente, ma non sempre necessaria per microimprese.

Ha senso farla (magari con un tecnico) quando:

• hai un catalogo ampio e noti che Google indicizza lentamente
• vedi scansione sprecata su filtri e parametri e non capisci da dove nascono
• hai cali improvvisi e sospetti che Googlebot incontri errori o percorsi duplicati

Puoi evitarla per ora quando:

• il catalogo è piccolo o medio e i problemi sono evidenti (performance, duplicati noti, filtri in sitemap)
• non hai risorse tecniche: meglio prima sistemare cache, immagini, canonical e controllo filtri

Piano d’azione in 14 giorni (cosa fare subito + cosa delegare)

1. Obiettivo: creare una base tecnica solida senza bloccare l’operatività dell’e-commerce.

2. Regola: cambia poche cose per volta e misura. Evita interventi “grandi” senza controllo (robots, noindex, redirect) se non hai revisione tecnica.

Giorni 1–3: misurazione e triage

1. Seleziona 4 URL campione: home, categoria principale, prodotto tipo, pagina informativa.

2. Misura con Lighthouse o PageSpeed Insights e annota cosa è più critico (caricamento lento, instabilità, risorse pesanti).

3. Controlla Search Console: esclusioni, duplicati, anomalie in scansione e sitemap.

4. Fai inventario: tema attivo, estensioni principali, presenza di CDN, presenza di caching avanzato (Varnish, Redis).

Giorni 4–10: fix ad alto impatto (performance + duplicazioni)

1. Con il developer: verifica stack e caching (Full Page Cache, Varnish, Redis) e che siano configurati in modo coerente.

2. Riduci peso: disattiva o sostituisci estensioni non critiche che aggiungono script e blocchi pesanti.

3. Immagini: attiva WebP o AVIF dove possibile e lazy loading per contenuti sotto la piega.

4. Strategia varianti: definisci prodotto configurabile come pagina principale e verifica canonical Server-side.

5. Audit URL: individua percorsi duplicati e concorda redirect e regole per mantenere una sola versione ufficiale.

Giorni 11–14: filtri/paginazione + schema

1. Filtri: rimuovi URL filtro dalle sitemap, definisci canonical verso categoria e valuta noindex, follow dove serve (con revisione tecnica).

2. AJAX e infinite scroll: assicurati che esistano fallback crawlable e pagine accessibili ai bot.

3. Paginazione: imposta title e H1 unici per pagine paginated e self-canonical per ogni pagina.

4. Dati strutturati: completa campi must-have (prezzo, stock, brand, SKU e GTIN quando disponibili, attributi chiave) e verifica coerenza con ciò che l’utente vede.