SEO su Magento: la guida tecnica per i cataloghi grandi

Su un catalogo Magento di poche decine di prodotti, quasi nessuna impostazione SEO della piattaforma fa una differenza visibile: qualunque configurazione scegli, Google riesce comunque a scansionare tutto in poco tempo. Il problema emerge quando il catalogo cresce a migliaia di SKU, perché a quel punto ogni scelta di configurazione smette di essere un dettaglio e diventa il fattore che decide quante pagine reali il crawler riesce a vedere prima di esaurire il budget che gli hai assegnato implicitamente.

Questo articolo non tratta la SEO ecommerce in generale, ma i meccanismi specifici di Magento e Adobe Commerce: come la navigazione a faccette genera URL parametrici in quantità, come i prodotti configurabili creano contenuto quasi duplicato tra le varianti, come il percorso di categoria negli URL prodotto interagisce con gli URL rewrite, cosa fanno davvero le impostazioni canonical della piattaforma e come gestire un'installazione multi-store view senza produrre copie indicizzabili dello stesso catalogo.

La navigazione a faccette e la moltiplicazione degli URL

Ogni attributo impostato come "Filterable" in Stores > Attributes diventa un filtro nella navigazione a faccette delle pagine categoria. Ogni filtro applicato aggiunge un parametro alla query string, e i filtri si combinano tra loro: colore più taglia più fascia di prezzo più marchio genera combinazioni che crescono moltiplicativamente. Immagina una categoria con qualche centinaio di prodotti e quattro attributi filtrabili: anche con pochi valori possibili per attributo, le combinazioni teoricamente raggiungibili si contano a decine di migliaia, quasi tutte varianti quasi identiche della stessa pagina categoria di base.

Google non deve seguirle tutte per capire che c'è un problema: gliene bastano poche per instradare lì una parte non banale del budget di scansione, a scapito delle pagine che contano davvero. La domanda giusta non è "come blocco tutto", ma quali combinazioni hanno una vera domanda di ricerca dietro (una categoria "scarpe da corsa" filtrata per "nero" può averla) e quali sono solo rumore combinatorio da tenere fuori dall'indice senza rompere il link interno per l'utente.

• Per ogni attributo, decidere se renderlo "Filterable (with results)", "Filterable (no results)" o "No": non tutto ciò che è utile all'utente deve generare un URL indicizzabile
• Bloccare via robots.txt i pattern di query string dei filtri, oppure lasciarli scansionabili con canonical verso la categoria pulita, mai le due cose insieme
• Per le combinazioni con reale interesse di ricerca, creare una landing page di categoria dedicata e stabile invece di affidarsi all'URL generato dal filtro

Prodotti configurabili e contenuto quasi duplicato

Un prodotto configurabile non ha stock proprio: aggrega prodotti semplici, uno per ogni combinazione di opzioni. Nei temi standard la pagina del prodotto semplice non è raggiungibile via link interno e il configurabile è l'unica entità con cui utente e crawler interagiscono. Il problema nasce con temi o estensioni che danno un URL proprio a ogni prodotto semplice: descrizione, metadati e spesso immagini sono identici tra le varianti, e Google le tratta come contenuto quasi duplicato che compete con se stesso invece di consolidare autorità sul configurabile.

Caso più subdolo: con "Display Out of Stock Products" attivo, un prodotto semplice esaurito resta raggiungibile e indicizzabile con una pagina praticamente vuota, perché il contenuto reale vive sul configurabile padre. Sono pagine sottili che il crawler continua a visitare senza più portare alcun valore.

• Verificare che ogni prodotto semplice reindirizzi (301) o abbia canonical verso il configurabile padre, senza essere l'URL condiviso con l'utente
• Escludere dalla sitemap i prodotti semplici esauriti che non hanno più contenuto proprio
• Applicare i dati strutturati Product e Offer al configurabile con l'elenco delle varianti, non duplicarli su ogni prodotto semplice

Percorso di categoria negli URL prodotto e URL rewrite

L'opzione "Use Categories Path for Product URLs", in Stores > Configuration > Catalog > Catalog > Search Engine Optimization, decide se l'URL di un prodotto include il percorso della categoria (per esempio /uomo/scarpe/prodotto.html) o resta piatto. Il percorso di categoria rende l'URL più leggibile, ma ha un costo su un catalogo grande: se un prodotto è assegnato a più categorie, Magento crea una regola di rewrite per ciascun percorso, e lo stesso prodotto diventa raggiungibile da più URL distinti.

Il vero rischio emerge quando il catalogo viene riorganizzato: spostare un prodotto tra categorie rigenera le regole di rewrite e può lasciare orfane quelle vecchie se non vengono pulite. Con "Create Permanent Redirect for URLs if URL Key Changed" attiva, Magento crea un redirect dal vecchio URL al nuovo, ma se un prodotto viene spostato più volte (stagionale, poi outlet, poi di nuovo in catalogo) si accumulano redirect concatenati - A che punta a B che punta a C - invece di un singolo salto diretto. Ogni hop in più diluisce il segnale e allunga il tempo di risposta per chi arriva da un link vecchio.

• Decidere consapevolmente tra percorso di categoria (più leggibile) e URL piatto (più stabile su categorizzazioni che cambiano spesso)
• Dopo ogni riorganizzazione del catalogo, controllare la tabella delle URL rewrite per catene di redirect e collassarle in un salto diretto
• Assegnare a ogni prodotto una categoria "primaria" quando ne ha più di una, per avere un percorso di riferimento univoco su cui costruire canonical e link interni

Le impostazioni canonical: categorie, prodotti e paginazione

Nello stesso pannello vivono due interruttori spesso ignorati: "Use Canonical Link Meta Tag For Categories" e "...For Products". Attivati, ogni pagina categoria filtrata o paginata dichiara canonical la versione pulita della categoria, e ogni prodotto raggiungibile da più percorsi dichiara canonical verso un unico URL scelto. Senza questi interruttori, ogni variante generata dalla navigazione a faccette o dall'assegnazione multipla compete a pieno titolo per l'indicizzazione: è esattamente lo scenario che porta Google a scansionare migliaia di varianti quasi identiche di poche decine di pagine reali.

La paginazione merita una nota: dopo che Google ha smesso di dare peso a rel=next/prev, molti siti hanno puntato tutte le pagine paginate al canonical della pagina 1, come se le successive non contenessero nulla di indicizzabile. In realtà ogni pagina di una serie elenca prodotti diversi ed è corretto che dichiari canonical verso se stessa: puntare tutto a pagina 1 rischia di far deindicizzare prodotti che compaiono solo più avanti nella lista.

• Attivare entrambi gli interruttori canonical su qualsiasi catalogo sopra poche centinaia di SKU
• Verificare che il canonical dichiarato non punti mai a un URL che a sua volta redirige: canonical e redirect in conflitto sprecano il segnale di entrambi
• Verificare che, anche con il canonical di categoria attivo, ogni pagina paginata dichiari canonical verso se stessa e non verso la pagina 1, correggendo il template se necessario

Multi-store view: lingue, valute e duplicazione tra store

Magento gestisce lingue e valute diverse tramite store view distinti sotto lo stesso website. L'architettura degli URL tra store view va decisa prima di popolare il catalogo, perché cambiarla dopo significa rigenerare tutte le regole di rewrite: dominio distinto per store view via le Base URL (scope store view), unico dominio con codice store nel percorso ("Add Store Code to Urls"), oppure - la scelta più rischiosa - stesso URL condiviso, differenziato solo per valuta a livello di sessione.

La terza opzione sembra più semplice ma genera i problemi reali: se due store view in lingue diverse condividono URL e root category, Google vede un solo contenuto indicizzabile, quindi il mercato secondario non riesce a raggiungerlo. Quando ogni store view ha un URL proprio, il contenuto tradotto diventa indicizzabile separatamente, ma senza hreflang - che Magento non genera nativamente - Google può leggere le versioni linguistiche come duplicati invece che come alternative per mercati diversi.

• Scegliere l'architettura degli URL per store view (dominio, percorso con codice store, o nessuna distinzione) prima del lancio, non dopo
• Se gli store view usano URL distinti, implementare hreflang tra le versioni linguistiche dello stesso prodotto o categoria
• Verificare che due store view non condividano per errore la stessa root category con la stessa struttura di URL

Sitemap XML e allineamento con ciò che è davvero indicizzabile

Il generatore in Marketing > SEO & Search > Site Map produce automaticamente un indice di più file quando il catalogo supera le decine di migliaia di URL, pianificabile via cron. Priorità e frequenza di aggiornamento sono in gran parte ignorate da Google in fase di scansione: il valore della sitemap sta nell'elenco degli URL, non nei metadati che li accompagnano.

Il vero lavoro è allineare cosa entra nella sitemap con cosa è realmente pensato per essere indicizzato. Un prodotto semplice figlio di un configurabile, una pagina categoria generata da un filtro, un prodotto disabilitato o non visibile individualmente non dovrebbero mai comparirvi: se ci compaiono, la sitemap dice a Google di scansionare pagine che le stesse impostazioni di visibilità del catalogo considerano non pubbliche.

• Generare la sitemap solo per prodotti realmente "visibili individualmente" nel catalogo, non per ogni riga della tabella prodotti
• Escludere i prodotti disabilitati, non visibili o esauriti da tempo, allineando la sitemap alla visibilità reale
• Programmare la rigenerazione via cron dopo ogni import massivo, senza affidarsi a una sitemap generata una volta e mai più aggiornata

Gli errori tecnici che si ripetono più spesso negli audit

Chi ha fatto audit su più installazioni Magento riconosce le stesse cause dietro sintomi diversi: posizionamento che non decolla, pagine indicizzate molto più numerose di quelle reali, crawl stats che mostrano il bot concentrato su URL che nessun umano visiterebbe mai.

• Lasciare i redirect impostati come temporanei quando cambia una URL key, disperdendo il segnale di posizionamento già accumulato
• Attivare il percorso di categoria negli URL prodotto e poi riorganizzare senza pulire le regole di rewrite obsolete, creando catene di redirect
• Non attivare i due interruttori canonical, lasciando che decine di varianti della stessa pagina competano tra loro per l'indicizzazione
• Rendere filtrabile ogni attributo disponibile senza mai decidere quali combinazioni meritano di essere indicizzabili
• Lasciare indicizzabili i prodotti semplici figli di un configurabile, duplicando lo stesso contenuto su più URL
• Condividere lo stesso URL tra store view in lingue diverse senza hreflang, o assegnare per errore la stessa root category a store view distinti
• Generare la sitemap da tutta la tabella prodotti invece che dai soli elementi realmente indicizzabili

Da dove iniziare su un catalogo già online

Su un'installazione già in produzione, con uno storico di posizionamento da non perdere, l'ordine in cui si interviene conta quasi quanto gli interventi stessi. I due interruttori canonical sono la modifica con il rapporto più alto tra impatto e rischio: è una configurazione, non una migrazione, e agisce da subito su ogni variante URL già esistente senza toccare la struttura del sito.

Solo dopo aver messo in ordine i canonical ha senso intervenire sulla navigazione a faccette, perché a quel punto qualunque URL parametrico che il crawler continui a trovare avrà già una via di consolidamento. L'audit della tabella di URL rewrite per catene di redirect e la verifica dell'indicizzabilità dei prodotti semplici vengono per terze, perché richiedono di guardare dati specifici del catalogo. La revisione dell'architettura multi-store view, se il sito ne ha una, va trattata come un progetto a parte: cambiare dominio o struttura degli URL tra store view dopo il lancio impone una migrazione di URL sull'intero catalogo, non una semplice modifica di configurazione.