SEO per ecommerce: dove si perde davvero traffico (e in che ordine si ripara)

Un ecommerce che non prende traffico organico ha quasi sempre un problema di URL in eccesso: il catalogo ne sforna a migliaia e le poche pagine che vendono finiscono in fondo alla coda. Di contenuti mancanti si parla troppo, e il buco raramente sta lì. Questa guida alla SEO per ecommerce mette sette problemi in

AUTHOR: Donato Pirolo
PUBLISHED: Agosto 27, 2026
MODIFIED: Agosto 28, 2026
SEO per ecommerce: dove si perde davvero traffico (e in che ordine si ripara)

Un ecommerce che non prende traffico organico ha quasi sempre un problema di URL in eccesso: il catalogo ne sforna a migliaia e le poche pagine che vendono finiscono in fondo alla coda. Di contenuti mancanti si parla troppo, e il buco raramente sta lì.

Questa guida alla SEO per ecommerce mette sette problemi in fila per impatto, dal più grosso al più piccolo. Ognuno apre con il modo di capire se ce l’hai davvero: una soglia ufficiale, una voce di Search Console, un conteggio che puoi fare stasera prima di cena. Dove serve c’è il link alla documentazione Google, che per l’ecommerce ha una sezione tutta sua. Delle cinque guide lette per preparare questo pezzo, quattro non linkano una sola pagina ufficiale e la quinta ne linka due, su un percorso che Google ha dismesso nel 2022. La sezione ecommerce non la nomina nessuna delle cinque.

I filtri e la navigazione a faccette hanno un pezzo tutto loro, quali pagine filtro far indicizzare e quali bloccare: qui li nomino e tiro dritto.

Dove la SEO per ecommerce perde il traffico

Il traffico si perde nel rapporto fra le URL che il catalogo genera e quelle che meritano di esistere, e su uno shop quel rapporto peggiora da solo ogni volta che apri il gestionale.

Ogni prodotto che carichi porta con sé la sua pagina, le sue varianti, gli ordinamenti della categoria in cui finisce e le pagine 2, 3 e 4. Aggiungi il parametro di sessione che il tema attacca ai link, la ricerca interna che indicizza ogni stringa digitata dai visitatori, e i prodotti morti che nessuno ha tolto. Un catalogo è una fotocopiatrice che qualcuno ha lasciato accesa in magazzino: continua a stampare anche di notte, e tu la mattina trovi la stanza piena.

A Google questa roba costa tempo, e la documentazione lo mette giù asciutto: la guida alla struttura delle URL per ecommerce chiede di ridurre al minimo le URL alternative che restituiscono lo stesso contenuto, per non far spendere più richieste del necessario, e di non linkare internamente parametri temporanei come gli ID di sessione.

La metrica è quel rapporto: quante URL genera lo shop, quante ne vorresti in indice. Se il primo numero è dieci volte il secondo, hai trovato il motivo per cui non cresci, e nessuna delle sette riparazioni qui sotto chiede di scrivere un articolo nuovo.

Prima di toccare qualcosa: quante URL ha davvero il tuo shop

I tre conteggi da confrontare prima di qualunque intervento: le URL dichiarate nella sitemap, quelle che un crawler trova partendo dalla home e quelle che Google conosce in Search Console. La distanza fra le colonne è già mezza diagnosi.

Ti servono tre numeri, e la distanza fra loro è già mezza diagnosi.

Il primo: quante URL dichiari nella sitemap. Il secondo: quante ne trova un crawler lanciato sul dominio partendo dalla home. Il terzo: quante ne conosce Google, nel rapporto Indicizzazione delle pagine di Search Console, sommando indicizzate e non indicizzate.

Su uno shop sano i tre numeri si somigliano. Quando il crawler ne trova il triplo della sitemap, la piattaforma sta generando URL che nessuno ha dichiarato e che nessuno controlla. Quando è Search Console ad averne il triplo, quelle URL Google le ha già trovate e ci sta spendendo richieste. È il momento in cui conti le sedie di casa e ne vengono fuori quaranta.

Fallo prima di qualunque intervento: decide quali delle sette sezioni qui sotto ti riguardano.

Il crawl budget è un problema tuo? Le soglie ufficiali

Probabilmente no, e Google dice quando lo diventa. La guida alla gestione del crawl budget sui siti grandi indica tre casi da gestire: siti oltre il milione di pagine uniche con contenuto che cambia circa una volta a settimana, siti oltre le 10.000 pagine uniche con contenuto che cambia ogni giorno, siti con molte URL segnalate come «Rilevata, ma attualmente non indicizzata».

Google li dichiara come stime approssimative, non come soglie esatte: nessuno ti manda una lettera al pezzo 1.000.001.

Il terzo caso è quello che frega gli shop piccoli, perché non ha una soglia dimensionale. Fai il conto su un catalogo da 800 prodotti che, fra ordinamenti e ricerca interna, arriva a 60.000 URL: ci finisce dentro benissimo. Fuori da quelle tre condizioni il tempo lo spendi meglio sulle categorie, che è la sezione dopo.

Le sei sorgenti di URL parassite

Le prime cinque le genera il tema senza che nessuno gliel’abbia chiesto; la sesta la lasci lì tu.

  • Ordinamenti e viste. Prezzo crescente, griglia o lista, 24 o 48 elementi per pagina: stesso identico set di prodotti, URL diverse. Sintomo in Search Console: la voce «Pagina duplicata senza URL canonico selezionato dall’utente» nel rapporto Indicizzazione delle pagine.
  • Parametri di sessione e tracking. Te ne accorgi dalle Statistiche di scansione, quando il grosso delle richieste finisce su URL con parametri.
  • Varianti. Sintomo: «Pagina duplicata, Google ha scelto una pagina canonica diversa da quella specificata dall’utente».
  • Paginazione. Sintomo: «Pagina scansionata, ma attualmente non indicizzata» sulle pagine dalla seconda in poi.
  • Ricerca interna. Le URL con /cerca? o ?q= che si accumulano in «Rilevata, ma attualmente non indicizzata».
  • Prodotti fuori catalogo. Il picco di 404 nelle Statistiche di scansione, oppure le schede esaurite ancora in «Pagina indicizzata» mesi dopo che il fornitore ha chiuso.

La settima sorgente è la navigazione a faccette, che secondo Google moltiplica le combinazioni fino a generare un numero enorme di URL, con sovrascansione e ritardo nella scoperta dei contenuti nuovi. Quali combinazioni tenere e con che strumento bloccare le altre le ho separate qui: quali pagine filtro far indicizzare e quali bloccare.

L’ordine in cui li ripari

Categorie, schede prodotto, varianti, duplicati strutturali, prodotti esauriti, paginazione, filtri. In quest’ordine.

BloccoImpatto attesoSforzoChi ci mette le mani
Architettura delle categorieAltoAltoChi decide il catalogo
Schede prodottoAltoAlto (ricorrente)Chi scrive
Varianti e canonicalMedio-altoMedioSviluppo
Duplicazioni strutturaliMedioBassoSviluppo
Prodotti esauritiMedioBasso (poi automatico)Sviluppo
PaginazioneBasso-medioBassoSviluppo
FiltriVariabileMedioSviluppo

Il criterio: impatto stimato sul traffico organico, sforzo tecnico per arrivare in fondo. È una scala di giudizio costruita su quello che vedo sugli shop, non un dato misurato, e su un catalogo da 200.000 referenze l’ordine cambia.

Categorie: quante ne servono davvero

Quante ne nomina la domanda di ricerca, e non una di più.

Le categorie ecommerce sono le pagine che intercettano la domanda commerciale, quella di chi cerca «scarpe da running per pronazione» e non un modello preciso. Sugli shop sono anche le pagine più trascurate: un titolo, una griglia, un blocco di testo appiccicato in fondo l’anno scorso.

La documentazione Google sulla struttura del sito ecommerce chiede un flusso di link preciso: dal menu alle categorie, dalle categorie alle sottocategorie, dalle sottocategorie a tutte le pagine prodotto. Se linkare tutto non è possibile, usa una sitemap o un feed Merchant Center. Sulla stessa pagina c’è la conseguenza che quasi nessuno ne trae: più link interni riceve una pagina, maggiore è la sua importanza relativa rispetto alle altre pagine del sito.

Tradotto: il tuo albero di categorie è anche il modo in cui distribuisci autorità dentro il dominio. Se il menu linka 40 sottocategorie e non linka le 6 che portano soldi, hai spalmato tutto in modo uniforme, e uniforme vuol dire irrilevante. Quali nodi devono esistere lo decide la ricerca, con il metodo che sta nella guida alla keyword research.

Quando una categoria non deve esistere

Quando nessuno cerca il suo nome, o quando dentro ci stanno due prodotti.

Tre casi da cercare stasera nel menu. La categoria thin, con tre referenze e un titolo che nessuno ha mai digitato in vita sua. Le due categorie sorelle che dividono la stessa domanda, tipo «zaini scuola» e «zaini scolastici», che si tolgono forza a vicenda e vanno fuse tenendo la URL più vecchia. La sottocategoria da un prodotto solo, che è una scheda travestita e va sciolta nel livello sopra.

Ogni nodo che togli è autorità che smetti di disperdere. Ogni nodo che tieni deve rispondere a una domanda che qualcuno pone davvero, altrimenti stai costruendo corridoi in una casa dove non entra nessuno.

Il testo di categoria: a cosa serve, dove va

Serve se aiuta a scegliere. Il blocco di 400 parole a fondo pagina scritto per il motore non aiuta nessuno, e Google lo dice a modo suo: nella guida introduttiva c’è scritto che la lunghezza del contenuto da sola non conta ai fini del ranking.

Dentro una categoria ci va come si sceglie: quale sottocategoria prendere in base a cosa, che differenza c’è fra la A e la B, quali sono i due o tre criteri che contano davvero in quel comparto. Poi i link alle sottocategorie, che fanno anche il lavoro strutturale del paragrafo sopra.

Il posto giusto è dove serve a chi legge. Due righe sopra la griglia che orientano la scelta, e il resto sotto per chi vuole capirci di più. Il test onesto sono le domande di autovalutazione ufficiali: questo testo offre informazioni o analisi originali, oppure si limita a riassumere quello che dicono gli altri senza aggiungere molto?

Breadcrumb: il markup che vale ancora la pena

BreadcrumbList è fra i tipi che Google raccomanda esplicitamente per un ecommerce, insieme a LocalBusiness per i punti vendita fisici, Organization per i dati aziendali e le politiche di reso, Product e ProductGroup, Review e VideoObject.

Costa dieci minuti una volta sola, perché il template della categoria è uno.

{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    {
      "@type": "ListItem",
      "position": 1,
      "name": "Scarpe",
      "item": "https://esempio.it/scarpe/"
    },
    {
      "@type": "ListItem",
      "position": 2,
      "name": "Scarpe da running",
      "item": "https://esempio.it/scarpe/running/"
    },
    {
      "@type": "ListItem",
      "position": 3,
      "name": "Modello A4"
    }
  ]
}

L’ultimo elemento resta senza item: è la pagina corrente, non serve linkarla a se stessa.

Schede prodotto: il problema non è la lunghezza

Google dichiara che non esiste un numero di parole minimo o massimo e che la lunghezza da sola non conta ai fini del ranking. Lo scrive la guida introduttiva, aggiornata a dicembre 2025, e smonta metà dei consigli che trovi sulle schede prodotto.

Il problema vero della scheda prodotto ecommerce è un altro. La descrizione che ti passa il fornitore sta identica su duecento negozi, spesso da prima che tu aprissi il tuo. Puoi allungarla a 800 parole con il generatore che preferisci: resta la stessa descrizione di duecento negozi, solo più lunga.

La domanda giusta è cosa sai tu che il fornitore non ha scritto.

Cosa scrivere quando la descrizione la dà il fornitore

Scrivi quello che hai visto tu con il prodotto in mano.

  • Misure vere. Non quelle della scheda tecnica: quelle prese con il metro, comprese le tolleranze che i clienti scoprono da soli.
  • Compatibilità. Con cosa funziona, con cosa no, quale adattatore serve, quale versione precedente monta lo stesso attacco.
  • Limiti d’uso. Fino a che temperatura, fino a che peso, quante ore, dopo quanto si consuma.
  • Abbinamenti. Cosa comprano insieme, e perché quel secondo pezzo serve davvero.
  • Cosa cambia rispetto al modello vecchio. Compreso quello che è peggiorato.
  • Per chi non va bene. La riga che nessuno scrive e che riduce i resi.

Il motivo per cui la copia pura è un rischio sta nelle spam policy. Attenzione alla portata: la voce sull’affiliazione superficiale parla di contenuti con link affiliati in cui descrizioni e recensioni sono copiate dal merchant originale senza contenuto originale o valore aggiunto, quindi se vendi in proprio non ci rientri. Il criterio del valore aggiunto però è lo stesso, e la mia lettura è che sia lo stesso metro con cui viene scelta quale delle duecento schede identiche vale la pena mostrare. Questa è una mia inferenza, non una riga della policy.

Sull’AI generativa la posizione onesta è questa: usala per riordinare quello che hai raccolto tu, non per riempire il vuoto. La stessa pagina definisce abuso di contenuti scalati la generazione di molte pagine senza valore aggiunto, e include esplicitamente l’uso di strumenti generativi. Riscrivere quattromila volte la stessa scheda con quattromila sinonimi diversi ci rientra in pieno. Lo strumento è identico, il materiale in ingresso no.

Il markup che serve davvero

Google distingue due tipi di risultato prodotto: il product snippet per le pagine dove il prodotto non si acquista direttamente, che ha più opzioni per le informazioni di recensione, e il merchant listing per le pagine dove si compra, che ha più opzioni per taglie, spedizione e reso. La distinzione la fa la pagina sui dati strutturati Product, dove Google scrive anche che aggiungere le proprietà richieste per il merchant listing rende la pagina idonea a entrambi i tipi.

Obbligatorie: name, image, offers con priceCurrency in codice ISO 4217 e il prezzo, indicato come price oppure dentro priceSpecification.price. L’elenco completo lo pubblica la documentazione merchant listing.

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Scarpa da running Modello A4",
  "image": ["https://esempio.it/img/a4-nero-1.jpg"],
  "sku": "A4-NERO-42",
  "brand": { "@type": "Brand", "name": "Esempio" },
  "offers": {
    "@type": "Offer",
    "url": "https://esempio.it/scarpe/running/a4/?colore=nero&taglia=42",
    "price": "129.00",
    "priceCurrency": "EUR",
    "availability": "https://schema.org/InStock",
    "itemCondition": "https://schema.org/NewCondition",
    "shippingDetails": {
      "@type": "OfferShippingDetails",
      "shippingRate": {
        "@type": "MonetaryAmount",
        "value": "4.90",
        "currency": "EUR"
      },
      "shippingDestination": {
        "@type": "DefinedRegion",
        "addressCountry": "IT"
      }
    },
    "hasMerchantReturnPolicy": {
      "@type": "MerchantReturnPolicy",
      "@id": "https://esempio.it/#resi"
    }
  }
}

I campi che si vedono in SERP sono availability, shippingDetails e la politica di reso. Su quest’ultima Google consiglia di dichiararla a livello Organization per tutto il negozio, e di sovrascriverla a livello prodotto solo quando quel prodotto fa eccezione. Nell’esempio sopra il reso è un riferimento all’oggetto Organization dichiarato altrove: un posto solo da aggiornare quando cambi le condizioni.

Recensioni e contenuto sopra la piega

Le recensioni sono l’unico contenuto che il concorrente non può copiarti, perché arrivano da persone che hanno comprato da te.

Sopra la piega di una scheda vanno tre cose: prezzo, disponibilità, e la differenza rispetto al modello vicino, che è la domanda con cui la gente arriva. La descrizione lunga può stare sotto senza drammi, purché sopra ci sia quello che serve a decidere.

Non ho un numero da darti sull’effetto delle stelle in SERP, e i numeri che girano su questo di solito non hanno una fonte.

Varianti: una URL per ogni taglia o una pagina sola?

Vanno bene entrambe: la documentazione sulle varianti prodotto riconosce due architetture, tutte le varianti selezionabili su una pagina sola (di norma via query parameter, senza ricaricare) oppure varianti su pagine distinte.

Il markup è lo stesso in tutti e due i casi. ProductGroup raccoglie le proprietà comuni a tutte le varianti, hasVariant elenca i singoli prodotti, variesBy dichiara gli assi lungo cui la variazione avviene, e gli assi supportati sono sei in tutto: colore, taglia, materiale, pattern, fascia d’età suggerita e genere suggerito.

Due requisiti tecnici che sbagliano quasi tutti. Ogni variante preselezionabile deve avere una URL distinta ottenuta con un query parameter: la documentazione lo scrive come requisito, in quei termini. Il fragment dopo il cancelletto non è un’alternativa, ed è Google a dirlo nella pagina sulla paginazione: quello che sta dopo il # non fa una pagina diversa. E nel modello a pagina singola resta una sola URL canonica per l’intero ProductGroup: canonicalizzare ogni variante verso se stessa lì dentro non ha senso.

Il criterio per decidere: la variante ha una domanda propria?

Se la variante viene cercata per nome, merita una URL indicizzabile con contenuto, title e meta propri. Altrimenti è una selezione dentro la pagina.

«iphone 15 verde» lo cerca gente vera, quindi quella variante è una pagina. «Maglietta bianca taglia M» non lo cerca nessuno, quindi è un menu a tendina. Il volume di ricerca decide l’architettura, e questo è uno dei punti in cui la keyword research smette di essere un esercizio da SEO e diventa una decisione di sviluppo.

È la stessa domanda che ti fai sui filtri, in un contesto diverso: quella combinazione soddisfa una richiesta che la pagina madre non soddisfa già?

Gli errori di canonical SEO che si ripetono su ogni shop

Quattro errori tornano con una regolarità che fa quasi tenerezza.

Il canonical incrociato fra varianti, dove tutte puntano su una sola che poi va fuori catalogo e si porta giù l’intero gruppo. Il canonical a catena, che rimbalza da A a B a C mentre Google si stanca a metà. Il canonical dalla scheda verso la categoria madre, che è un modo elegante di dire a Google «questa scheda non mi serve». Il canonical mancante o non autoreferenziale, che lascia decidere alla piattaforma.

Ultima cosa, la più importante. Il canonical che dichiari resta una preferenza, per quanto pesante: la documentazione lo chiama «a strong signal that the specified URL should become canonical», e mette il caso opposto in chiaro: se non ne dichiari nessuno, è Google a individuare da sé quale versione della URL è la migliore da mostrare. Il corollario pratico lo vedi in Search Console, dove esiste la voce «Pagina duplicata, Google ha scelto una pagina canonica diversa da quella specificata dall’utente»: la scelta finale resta sua.

Contenuto duplicato: quello che costa e quello che non costa niente

Non esiste una penalizzazione per contenuti duplicati. Nella guida introduttiva Google scrive che se lo stesso contenuto è accessibile da più URL va bene e non è il caso di preoccuparsene.

Rileggilo, perché due delle cinque guide che ho letto affermano il contrario, e chi le legge passa settimane a riscrivere descrizioni per evitare una punizione che non arriva.

Il costo c’è comunque, e si paga in due valute. La prima: i segnali si spezzano su più URL, quindi i link e l’autorità che una pagina avrebbe raccolto tutta insieme finiscono divisi in tre tronconi. La seconda: la scansione viene spesa due volte sulla stessa cosa, che è il discorso della sezione diagnostica qui sopra.

Le tre duplicazioni strutturali di uno shop

Nessuna delle tre nasce da un copia-incolla: le genera la piattaforma da sola, mentre tu carichi prodotti.

Stesso prodotto raggiungibile da più categorie. Se la URL prodotto include il path della categoria, la stessa scheda esiste in tre copie: /scarpe/running/a4/, /offerte/a4/, /nike/a4/. Rimedio: URL prodotto unica e piatta, tipo /p/a4/, con le categorie che ci linkano dentro.

Ordinamenti e viste. Prezzo crescente, griglia o lista, 24 o 48 per pagina restituiscono lo stesso identico set di prodotti a URL diverse. Rimedio: canonical dalla vista ordinata verso la categoria pulita, e non linkare internamente le combinazioni che non servono a nessuno. Con l’avvertenza della sezione sulla paginazione: la documentazione, su questo caso, indica noindex o robots.txt.

Residui storici. Le versioni print mai smantellate, il sottodominio m. che doveva morire nel 2016, l’AMP che nessuno guarda più da tre anni. Rimedio: spegnerli, con un 301 verso la versione buona.

Su tutti e tre vale la regola già citata: ridurre al minimo le URL alternative che restituiscono lo stesso contenuto. Il duplicato che nasce dalle combinazioni di filtri segue un’altra logica, e l’ho trattato a parte nel pezzo sui filtri e la navigazione a faccette.

Prodotti esauriti: 404, 410, redirect o lascio la pagina?

L'albero decisionale per un prodotto fuori catalogo: se rientra la pagina resta online con lo stato aggiornato, se ha un sostituto reale va in 301 verso l'erede, se non torna e non ha eredi il 404 chiude la URL e libera la coda di scansione.

I prodotti esauriti in SEO si risolvono con una domanda sola: quel prodotto tornerà oppure no.

Se torna, la pagina resta online e cambia stato. Se non torna e hai un sostituto vero, 301 verso il sostituto. Se non torna e sostituti non ce ne sono, 404 o 410. Fine dell’albero, e sono tre rami che si distinguono con una domanda che puoi fare al magazzino.

Nella mia esperienza è il problema che genera più errori reali sugli shop, e una risposta decente in giro non c’è: quattro delle cinque guide che ho letto non lo nominano proprio.

Esaurito temporaneo e stagionale: la pagina resta

La pagina resta online, con lo stato aggiornato nel markup.

I valori di disponibilità accettati da Google sono dieci: BackOrder, Discontinued, InStock, InStoreOnly, LimitedAvailability, OnlineOnly, OutOfStock, PreOrder, PreSale, SoldOut. La documentazione merchant listing li elenca tutti e dieci, e quasi ogni situazione di magazzino ne ha uno che la descrive.

Sulla pagina, oltre allo stato, metti le alternative dentro la stessa categoria e la data di rientro se la conosci. Chi arriva ha una domanda a cui puoi ancora rispondere.

Il costume da bagno che a settembre restituisce 404 e a maggio torna con una URL nuova butta via ogni anno la storia della URL: link, età, segnali accumulati. Dodici mesi di lavoro cancellati per fare ordine nel gestionale.

Fine vita: 301 se c’è un erede, 404 o 410 se non c’è

301 verso il sostituto reale quando esiste, 404 o 410 quando non esiste.

Sul 301 la documentazione sugli errori HTTP e di rete, aggiornata a febbraio 2026, dice che viene usato come segnale forte per la destinazione del redirect, mentre il 302 vale come segnale debole: mettere un 302 su un prodotto che non torna più è chiedere a Google di non prenderti sul serio.

Sulla scelta fra 404 e 410 la stessa pagina toglie il dubbio: tutti gli errori 4xx tranne il 429 vengono trattati allo stesso modo, i crawler comunicano al sistema successivo che il contenuto non esiste. Puoi usare il 410 se ti fa sentire più preciso, ma per Google la differenza è marginale. Nel markup, intanto, il valore che descrive la situazione è Discontinued.

Il redirect verso il sostituto ha una condizione: il sostituto deve essere davvero l’erede di quel prodotto, stesso uso e stessa fascia. Il modello A4 va sull’A5, non sulla categoria «running» e nemmeno sulla home. Chi arriva non trova quello che cercava, e Google mette in guardia proprio da questo: reindirizzare molte URL vecchie verso una singola destinazione irrilevante come la home confonde gli utenti e può essere trattato come un soft 404. La frase sta nella guida ai cambi di URL e parla di migrazioni di sito, ma la meccanica è la stessa: cento schede morte che finiscono tutte in home sono cento promesse non mantenute.

Il beneficio collaterale: 404 pulisce la coda di scansione

Un 404 è un segnale forte a non riscansionare quella URL, e lo scrive la stessa guida sul crawl budget citata all’inizio.

Una URL solo bloccata, invece, resta in coda molto più a lungo, perché Google sa che esiste e non sa cosa contiene. Restituire correttamente i 404 sui prodotti morti è il modo più economico che hai per liberare richieste e rimandarle sulle pagine che vendono.

Fra le sei sorgenti di URL parassite, i prodotti morti sono quella che spegni con meno fatica.

Paginazione delle categorie: cosa fare oggi

Sulla paginazione SEO le regole ufficiali stanno in una pagina sola della sezione ecommerce, paginazione e caricamento incrementale, e sono tre famiglie di regole.

  • Lascia stare rel=next e rel=prev. Google non li usa più. Altri motori potrebbero, ma non è un buon motivo per implementarli male, e chi te li consiglia ammettendo nello stesso paragrafo che Google li ha abbandonati ti sta consigliando per inerzia.
  • Ogni pagina della serie tiene il proprio canonical. Mai canonicalizzare pagina 2, 3 e 4 verso pagina 1: quelle pagine contengono prodotti diversi, e dichiararle copie della prima è il modo più efficace per farle sparire.
  • Il numero di pagina va in query parameter, nella forma ?page=2, mai nel fragment dopo il cancelletto.
  • Ogni pagina linka alla successiva con un vero tag a href. Un onclick su un div non è un link, e Googlebot non lo segue.
  • Le varianti ordinate non vanno indicizzate. È la terza regola di quella pagina, ed è quella che quasi nessuno cita: per evitare che finiscano in indice tutte le versioni della stessa lista, Google indica il noindex oppure il robots.txt sui pattern di URL. Sugli ordinamenti io scelgo il canonical, perché consolida i segnali invece di buttarli, ma è una divergenza dalla lettera della documentazione e preferisco dichiararla che nasconderla.

Se dal conteggio iniziale ti sono uscite migliaia di pagine categoria in «Pagina scansionata, ma attualmente non indicizzata», guarda quanti prodotti mostri per pagina: quaranta pagine da 12 prodotti sono un problema di soglia, prima che di paginazione.

Scroll infinito e pulsante carica altro

Si possono usare, a una condizione: ogni blocco caricato deve avere una URL persistente e unica.

La documentazione sul lazy loading, aggiornata a dicembre 2025, chiede numerazione assoluta (?page=12) e non relativa (?date=yesterday), aggiornando la URL mostrata con la History API mentre l’utente scorre. Il motivo tecnico lo dichiara Google stessa: la Ricerca non interagisce con la pagina, non scrolla e non clicca. Il lazy loading deve scattare sulla visibilità nel viewport, non su un gesto.

Uno scroll infinito senza URL è una fisarmonica che suona solo se qualcuno la tira: Googlebot non ha le mani.

I filtri: questa pagina la voglio in indice o no?

La vuoi in indice solo se esiste una domanda di ricerca che quella combinazione soddisfa meglio della categoria madre, e se puoi darle contenuto, title e meta propri. In tutti gli altri casi no.

La navigazione a faccette è la principale sorgente di URL infinite su uno shop: tre filtri da cinque valori fanno 125 combinazioni, e i filtri su uno shop non sono mai tre. Google segnala che la moltiplicazione porta sovrascansione e ritardo nella scoperta dei contenuti nuovi.

È la settima sorgente della lista qui sopra e su quasi ogni shop è la più grossa: quando il conteggio iniziale ti restituisce un crawl dieci volte la sitemap, il grosso della differenza arriva da qui.

Il modo di decidere combinazione per combinazione, e gli strumenti per bloccare il resto, l’ho messo tutto nel pezzo dedicato: quali pagine filtro far indicizzare e quali bloccare.

Come capisci se sta funzionando: Search Console per tipo di pagina

Segmenta le performance per tipo di pagina, poi leggi il rapporto Indicizzazione delle pagine per stato. Sono due analisi, e nessuna delle cinque guide che ho letto le spiega.

La prima si fa nel rapporto Prestazioni, con il filtro «URL contiene». Tre viste salvate: /categoria/, il pattern delle schede prodotto, /blog/. Guardando i tre numeri insieme capisci dove il traffico si perde davvero, e la sorpresa tipica è uno shop convinto di avere un problema di blog che invece ha categorie senza impressioni.

La seconda si fa nel rapporto Indicizzazione delle pagine, leggendo tre stati come sintomi:

  • «Rilevata, ma attualmente non indicizzata»: Google conosce la URL e non è ancora passato. Su grandi numeri è coda di scansione intasata, e ti riporta dritto alle sei sorgenti di URL parassite.
  • «Pagina scansionata, ma attualmente non indicizzata»: c’è passato e ha deciso di lasciarla fuori. È un giudizio sul valore percepito, e sulle schede prodotto significa quasi sempre descrizione fornitore.
  • «Pagina alternativa con tag canonical appropriato»: qui Google ti sta dando ragione. Se cresce dopo che hai sistemato ordinamenti e varianti, i consolidamenti stanno funzionando.

Poi apri le Statistiche di scansione e guardi su cosa Googlebot spende davvero le richieste. Se il grosso va su URL con parametri, sai già cosa fare lunedì.

Un numero di riferimento buono per tutti non te lo do, perché non esiste: il benchmark sei tu di tre mesi fa.

E la ricerca AI cambia qualcosa per uno shop?

Quasi certamente no, almeno sul lato tecnico. Per comparire come link di supporto in AI Overviews o AI Mode una pagina deve essere indicizzata e mostrabile in Google Search con uno snippet, rispettando i requisiti tecnici della Ricerca. Lo scrive Google nella pagina sulle funzionalità AI, aggiornata a dicembre 2025.

Sulla stessa pagina c’è la parte che smonta metà del mercato: non servono nuovi file leggibili dalle macchine, non servono file di testo dedicati all’AI, non esiste uno structured data speciale per le funzionalità generative. I controlli sono quelli di sempre, nosnippet, data-nosnippet, max-snippet e noindex. Il resto del ragionamento sta nel pillar su cosa cambia davvero nella SEO per le AI.

Per un ecommerce, però, una differenza c’è, e riguarda le superfici. La documentazione su dove possono comparire i dati ecommerce elenca Ricerca, Immagini, Lens, scheda Shopping, profilo dell’attività e Maps, e ognuna si alimenta in modo diverso: per la scheda Shopping e per Lens si caricano i prodotti su Google Merchant Center, per la Ricerca si usa lo structured data supportato, per Maps servono i prodotti caricati su Merchant Center con i dati di inventario locale; il profilo dell’attività, che la stessa pagina tratta come superficie a sé, va rivendicato e collegato a Merchant Center.

Qui finisce il dato ufficiale e comincia quello che penso io. Nell’ultimo anno, sugli shop che guardo, la roba che porta risultati nelle risposte generate è la stessa che porta risultati in SERP classica: schede con informazione che non sta da nessun’altra parte, categorie che rispondono a una domanda vera, markup pulito. Non è una misurazione, è un’impressione, e la tratto come tale.

Da dove cominci, in ordine

Ecco i sette passi con cui si rimette in piedi la SEO per ecommerce di uno shop già online e si torna ad aumentare il traffico, nell’ordine in cui conviene affrontarli.

  1. Conta le URL. Sitemap, crawl, Search Console. La distanza fra i tre numeri è la diagnosi.
  2. Sistema l’albero delle categorie. Fondi le sorelle, sciogli le thin, controlla che il menu linki le pagine che contano. Il criterio per decidere quali nodi tenere l’ho dato nella sezione sulle categorie.
  3. Aggiungi alle schede quello che il fornitore non ha scritto. Misure, compatibilità, limiti, per chi non va bene.
  4. Decidi l’architettura delle varianti in base alla domanda di ricerca, poi dichiarala con ProductGroup e variesBy.
  5. Chiudi le duplicazioni strutturali. URL prodotto piatta, canonical sugli ordinamenti, residui storici spenti.
  6. Metti a posto i prodotti morti. Stato aggiornato se tornano, 301 al vero erede se hanno un erede, 404 se non ce l’hanno.
  7. Controlla paginazione e filtri. Canonical propri sulle pagine della serie, e la scelta su cosa far indicizzare fra le combinazioni.

Poi torni in Search Console fra sei settimane e guardi gli stessi tre stati.

Se il tuo albero di categorie ti sembra un labirinto, mandamelo: mi diverto a smontarli, e due occhi esterni su una tassonomia non hanno mai fatto male a nessuno. Se invece hai un caso in cui una di queste regole non ha funzionato, quello mi interessa ancora di più, perché è così che si aggiornano i pezzi.

Domande frequenti

Perché il mio ecommerce è online da mesi e non prende traffico organico? Da dove comincio?+

Comincia contando le URL. Nella quasi totalità dei casi il catalogo genera molte più pagine di quante Google ne possa tenere, e quelle che vendono restano in coda. Confronta tre numeri: URL nella sitemap, URL trovate da un crawler, URL note a Search Console. Se il crawler ne trova il triplo della sitemap, hai trovato il buco prima di scrivere una riga di contenuto nuovo. Nella SEO per ecommerce il conteggio delle URL viene prima di tutto il resto.

Il crawl budget è un problema anche per il mio shop o solo per i cataloghi enormi?+

Dipende da tre condizioni che Google elenca nella guida dedicata: oltre un milione di pagine uniche con contenuto che cambia circa settimanalmente, oltre 10.000 pagine uniche con contenuto che cambia ogni giorno, oppure molte URL segnalate come «Rilevata, ma attualmente non indicizzata». Google le dà come stime approssimative, non come soglie esatte. La terza condizione riguarda anche shop piccoli, perché non ha una soglia dimensionale.

Quanto deve essere lunga una descrizione di prodotto?+

Non c’è una lunghezza giusta. Google scrive nella guida introduttiva che la lunghezza del contenuto da sola non conta ai fini del ranking e che non esiste un numero di parole minimo o massimo. Conta cosa contiene: se aggiungi misure reali, compatibilità e limiti d’uso, duecento parole bastano; se allunghi la descrizione del fornitore, ottocento non servono a niente.

Posso generare le descrizioni prodotto con l’AI? Google se ne accorge, e quando diventa un problema?+

Sì, con un limite. Le spam policy definiscono abuso di contenuti scalati la generazione di molte pagine senza valore aggiunto, e includono esplicitamente l’uso di strumenti generativi. Se dai al modello le misure che hai preso tu e i difetti che hai visto, stai riordinando informazione tua. Se gli chiedi quattromila varianti della stessa scheda vuota, il problema arriva. La differenza la fa quello che metti dentro il prompt, non il modello che usi.

Ogni variante (taglia, colore, formato) deve avere la sua URL o basta una pagina con il selettore?+

Vanno bene entrambe: la documentazione sulle varianti riconosce sia la pagina singola con tutte le varianti selezionabili sia le pagine distinte. Il criterio pratico è la domanda di ricerca: se «iphone 15 verde» viene cercato, quella variante merita una pagina propria; se «maglietta bianca taglia M» non lo cerca nessuno, è una selezione. In entrambi i casi ogni variante preselezionabile deve avere una URL distinta via query parameter, mai via fragment.

Il canonical è un ordine o un suggerimento? Perché Google a volte ne sceglie un altro?+

È una preferenza che dichiari, non un ordine che impartisci. La documentazione sul consolidamento delle URL duplicate parla del caso in cui il canonical non lo dichiari affatto: lì la versione da mostrare la sceglie Google. Che possa scegliere diversamente anche quando gliela indichi tu lo vedi da una voce di Search Console, «Pagina duplicata, Google ha scelto una pagina canonica diversa da quella specificata dall’utente». Il primo motivo lo dichiara Google stessa, e più secco di come lo direi io: «Se il contenuto canonico dichiarato dall’utente non è simile alla pagina corrente, Google non sceglierà mai quell’URL come canonico. Una pagina duplicata deve essere simile alla pagina canonica.» Il secondo lo aggiungo io, da quello che vedo sugli shop: catene di canonical incoerenti, dove la pagina A punta a B che punta a C. Per sapere quale ha scelto lui usa lo strumento di ispezione URL, non il sorgente della tua pagina.

Google penalizza i contenuti duplicati?+

No. Non esiste una penalizzazione per contenuti duplicati. Nella guida introduttiva Google scrive che se lo stesso contenuto è accessibile da più URL va bene e non è il caso di preoccuparsene. Il costo esiste lo stesso, e sono due voci: i segnali si dividono su più URL invece di sommarsi su una, e la scansione viene spesa due volte sulla stessa cosa.

Un prodotto esaurito: lo lascio online, lo redirigo o restituisco 404? E fra 404 e 410 cambia qualcosa?+

Se torna, la pagina resta online con lo stato aggiornato nel markup. Se non torna e c’è un sostituto vero, 301 verso quel sostituto. Se non torna e sostituti non ce ne sono, 404 o 410, e fra i due la differenza per Google è marginale: la documentazione sugli errori HTTP dice che tutti i 4xx tranne il 429 vengono trattati allo stesso modo. Quello che non va fatto è il redirect di massa verso la home o la categoria generica, che Google avverte può essere trattato come un soft 404.

Le pagine 2, 3, 4 di una categoria vanno canonicalizzate verso pagina 1? E rel=next/prev serve ancora?+

No a entrambe. La guida ufficiale sulla paginazione dice di non usare la prima pagina come canonica per tutta la serie: ogni pagina tiene la propria URL canonica. Su rel=next e rel=prev Google non li usa più, altri motori potrebbero usarli ancora, ma non è un motivo sufficiente per implementarli male.

Cosa significa «Rilevata, ma attualmente non indicizzata» su un ecommerce e cosa devo cambiare?+

Significa che Google conosce quelle URL e non ci è ancora passato. Su uno shop, quando il numero è grande, è il sintomo di una coda di scansione intasata da URL che non dovevano esistere: ordinamenti, parametri di sessione, ricerca interna, combinazioni di filtri. Non serve chiedere l’indicizzazione a mano di quelle pagine, serve togliere di mezzo le altre.

Serve un markup particolare per finire citato in AI Overviews o AI Mode?+

No. Google scrive nella pagina sulle funzionalità AI che per essere idonea a comparire come link di supporto una pagina deve essere indicizzata e mostrabile in Search con uno snippet, rispettando i requisiti tecnici della Ricerca. Niente nuovi file leggibili dalle macchine, niente file di testo per l’AI, nessuno structured data dedicato. I controlli restano nosnippet, data-nosnippet, max-snippet e noindex.

Che differenza c’è fra quello che passo con il feed Merchant Center e quello che marco sul sito?+

Alimentano superfici diverse. Secondo la documentazione Google, per la scheda Shopping e per Lens i prodotti si caricano su Merchant Center, per la Ricerca si usa lo structured data supportato sulle pagine, per Maps servono i prodotti su Merchant Center con i dati di inventario locale; il profilo dell’attività, che la stessa pagina tratta come superficie a sé, va rivendicato e collegato a Merchant Center. Feed e markup convivono: uno non sostituisce l’altro, e su uno shop serio servono tutti e due.

Donato Pirolo

Donato Pirolo

Consulente SEO & AI

Aiuto aziende e professionisti a crescere nei risultati organici e generativi, unendo SEO tecnica, strategia dei contenuti e ottimizzazione per i motori AI (GEO).

Lascia un commento