Ottimizzare WooCommerce significa lavorare in quest’ordine: prima si decide cosa i motori possono scansionare e indicizzare, poi si rendono utili le pagine di prodotto e categoria, infine si consolidano prestazioni e dati strutturati. La piattaforma genera più URL di quante ne servano. Quasi tutti i problemi di un negozio nascono da lì, non dalla mancanza di testo.
Questa guida raccoglie gli interventi tecnici che incidono su un catalogo costruito con questa piattaforma: struttura dei permalink, tassonomie, prodotti variabili, filtri e faccette, paginazione, gestione dell’esaurito, prestazioni, dati strutturati e visibilità nelle risposte generative. Ogni sezione risponde a una domanda operativa e indica cosa fare, cosa lasciare stare e in quale sequenza intervenire. Non troverai stime di miglioramento inventate: i numeri citati sono solo quelli rilevati e dichiarati alla fine.
Indice
- Cosa rende WooCommerce diverso dalle altre piattaforme dal punto di vista SEO?
- Come vanno impostati i permalink e le basi degli URL?
- Categorie, tag e attributi: cosa indicizzare e cosa no?
- I prodotti variabili creano contenuto duplicato?
- Filtri e faccette: cosa far scansionare e cosa bloccare?
- Come si gestiscono paginazione e archivi profondi?
- Cosa fare con i prodotti esauriti o eliminati?
- Quali interventi sulle prestazioni contano davvero?
- Come vanno impostati i dati strutturati di prodotto?
- Cosa cambia con le risposte AI sui prodotti?
- In che ordine affrontare gli interventi?
- Domande frequenti
Cosa rende WooCommerce diverso dalle altre piattaforme dal punto di vista SEO?
Non è un e-commerce chiuso: è uno strato applicativo montato su WordPress. Eredita quindi tassonomie, tipi di contenuto e regole di riscrittura del CMS, e vi aggiunge le proprie. Il risultato è una libertà quasi totale sulla struttura, accompagnata da un rischio proporzionale di proliferazione degli indirizzi.
Sulle piattaforme in hosting proprietario molte scelte sono già prese. La base del catalogo è fissa, gli archivi disponibili sono pochi, i parametri di filtro seguono uno schema noto. Qui si parte invece da un foglio quasi bianco: si decide se i prodotti vivono sotto una base dedicata o alla radice del dominio, se le categorie compaiono nel percorso, quali attributi diventano archivi pubblici.
Questa libertà si paga in due modi. Il primo è la responsabilità: nessuna configurazione predefinita protegge dagli errori, e una scelta sbagliata sulla struttura si porta dietro migliaia di redirect quando la si corregge. Il secondo è la stratificazione. Ogni estensione installata può aggiungere endpoint, parametri, tassonomie e varianti di indirizzo, spesso senza che nessuno se ne accorga finché il rapporto sulla scansione non mostra una crescita anomala.
Come vanno impostati i permalink e le basi degli URL?
La struttura corretta è quella piatta e stabile: una base di prodotto breve, senza categorie annidate nel percorso, e archivi di categoria raggiungibili da una base propria. Le categorie dentro l’indirizzo del prodotto sembrano ordinate, ma legano l’URL a una classificazione che cambia più spesso del prodotto stesso.
Il ragionamento è semplice. Un articolo può appartenere a più categorie e può essere riclassificato durante la vita del catalogo. Se la categoria è dentro l’indirizzo, ogni riorganizzazione merceologica produce una migrazione. Se invece l’indirizzo è indipendente, la riclassificazione resta un’operazione interna che non tocca nulla di ciò che è già indicizzato.
Sulle basi vale la stessa logica di sobrietà. Conviene una base di prodotto corta e in italiano, coerente con il resto del sito, e una base di categoria distinta da quella dei prodotti per evitare collisioni di slug. Le basi vanno scelte una volta e poi lasciate ferme: cambiarle a negozio avviato significa gestire redirect su tutto il catalogo, con perdita di segnali su un patrimonio di pagine che spesso è il più profittevole del sito.
Categorie, tag e attributi: cosa indicizzare e cosa no?
Le categorie sono le pagine che devono posizionarsi: rappresentano la domanda generica e raccolgono il traffico più ampio. I tag, nella quasi totalità dei casi, non vanno indicizzati. Gli attributi meritano archivi pubblici solo quando corrispondono a un modo reale in cui le persone cercano, non alla struttura interna del catalogo.
L’errore più comune è proprio l’indicizzazione dei tag. Nascono come strumento editoriale ereditato dal blog, vengono usati per etichettare gli articoli con parole ricorrenti e producono archivi quasi identici alle categorie, con meno contenuto e nessun testo introduttivo. Il risultato è un insieme di pagine deboli che competono con gli archivi principali sulle stesse chiavi e diluiscono i segnali interni.
Gli attributi vanno valutati caso per caso. Il materiale o la destinazione d’uso possono generare pagine con una domanda propria e un senso commerciale: chi cerca quel materiale vuole vedere tutto l’assortimento che lo impiega. La taglia o un codice colore interno non hanno alcuna domanda autonoma e producono solo archivi ridondanti.
La regola pratica è verificare se esiste una ricerca che corrisponde all’archivio. Se esiste, la pagina va trattata come una destinazione a tutti gli effetti: titolo dedicato, testo introduttivo utile, collegamenti dagli altri archivi. Se non esiste, va esclusa dall’indice e resa non raggiungibile dalla navigazione interna.
| Tipo di pagina | Domanda di ricerca autonoma | Trattamento consigliato |
|---|---|---|
| Categoria di primo livello | Ampia e costante | Indicizzata, con testo introduttivo e collegamenti interni |
| Sottocategoria | Specifica ma reale | Indicizzata se ha un assortimento proprio |
| Tag di prodotto | Quasi sempre assente | Esclusa dall’indice, link interni rimossi |
| Attributo con domanda propria | Presente | Indicizzata e curata come archivio di destinazione |
| Attributo strutturale (taglia, codice) | Assente | Esclusa dall’indice |
| Archivio autore o data | Assente | Disattivata |
I prodotti variabili creano contenuto duplicato?
Di per sé no: le varianti vengono servite sullo stesso indirizzo, con un parametro di selezione che non genera una pagina distinta. Il duplicato nasce quando si sceglie di pubblicare ogni variante come articolo autonomo, replicando descrizione, immagini e schede tecniche su decine di URL diverse.
La domanda da porsi è se la variante abbia una domanda di ricerca propria. Un colore o una taglia raramente ce l’hanno: chi cerca vuole il modello, poi sceglie in pagina. Un formato che cambia sostanzialmente l’oggetto, come una capacità diversa o una versione con dotazione differente, può invece meritare una pagina dedicata, purché abbia contenuto proprio e non una copia del fratello.
Quando si opta per l’articolo variabile, la scheda deve rendere visibili le informazioni di tutte le combinazioni anche prima della selezione. Prezzo minimo e massimo, disponibilità per variante, differenze rilevanti: se questi dati compaiono solo dopo un’interazione, la pagina risulta più povera di quanto sia in realtà, sia per chi la legge sia per chi la analizza.
Quando invece si separano le varianti, serve un collegamento esplicito e reciproco tra le pagine sorelle, testi che spieghino la differenza in modo sostanziale e attenzione a non far competere due indirizzi sulla stessa chiave. Ogni pagina indicizzata deve poter rispondere a una domanda che le altre non coprono.
Filtri e faccette: cosa far scansionare e cosa bloccare?
La navigazione a faccette va trattata come uno strumento per gli utenti, non come una fabbrica di pagine. In generale si lascia scansionabile una sola dimensione di filtro, quella che corrisponde a una domanda reale, e si escludono tutte le combinazioni multiple, gli ordinamenti e i parametri di sessione o tracciamento.
Il problema è combinatorio. Con poche decine di valori disponibili, l’incrocio libero produce un numero di indirizzi che supera di ordini di grandezza la dimensione del catalogo. Ognuno consuma risorse di scansione, richiede una query al database e restituisce quasi sempre un sottoinsieme già visibile altrove. È il modo più efficace per far spendere ai motori l’attenzione sulle pagine sbagliate.
Gli strumenti a disposizione sono tre e vanno usati insieme, non in alternativa. Il primo è il blocco della scansione per gli schemi di parametro privi di valore. Il secondo è l’esclusione dall’indice per le pagine che devono restare accessibili all’utente ma non comparire nei risultati. Il terzo, spesso trascurato, è la navigazione interna: se un filtro non deve essere seguito, i suoi collegamenti non devono essere link tradizionali nel codice della pagina.
Esiste una via alternativa per le combinazioni che hanno davvero una domanda dietro. In quel caso non si lascia lavorare il filtro, ma si crea una pagina stabile, con indirizzo pulito, testo dedicato e collegamenti dal resto del sito. Si guadagna una destinazione vera e si evita di aprire il rubinetto delle combinazioni.
| Schema di URL | Origine tipica | Scansione | Indicizzazione |
|---|---|---|---|
| Filtro singolo con domanda propria | Navigazione di categoria | Consentita | Valutata caso per caso |
| Combinazione di due o più filtri | Navigazione a faccette | Bloccata | Esclusa |
| Parametro di ordinamento | Selettore di ordine | Bloccata | Esclusa |
| Parametro di tracciamento campagne | Advertising e newsletter | Bloccata | Esclusa, con canonico alla pagina pulita |
| Risultati della ricerca interna | Modulo di ricerca | Bloccata | Esclusa |
| Carrello, cassa e area cliente | Flusso di acquisto | Bloccata | Esclusa |
Come si gestiscono paginazione e archivi profondi?
Le pagine successive alla prima vanno lasciate scansionabili e indicizzabili, con collegamenti in codice HTML e un canonico che punta a se stesse. L’errore da evitare è farle puntare tutte alla prima: gli articoli presenti solo in fondo alla serie diventerebbero irraggiungibili attraverso la navigazione.
La paginazione è il canale principale attraverso cui i motori raggiungono la parte profonda di un catalogo ampio. Se la serie si interrompe, o se il caricamento avviene solo tramite interazione senza indirizzi reali, una porzione dell’assortimento resta fuori dalla scansione. Vale anche per le soluzioni a scorrimento infinito, che vanno sempre accompagnate da una paginazione tradizionale funzionante.
Sugli archivi molto lunghi conviene poi ragionare sulla profondità. Se raggiungere un articolo richiede un numero elevato di passaggi dalla home, quella scheda riceve pochi segnali interni. Sottocategorie ben costruite accorciano il percorso meglio di qualsiasi intervento sulla paginazione, e producono nel frattempo pagine di destinazione utili.
Cosa fare con i prodotti esauriti o eliminati?
Un articolo temporaneamente esaurito va mantenuto online, con la disponibilità dichiarata in modo esplicito e alternative visibili in pagina. Un articolo eliminato definitivamente va reindirizzato verso la sostituzione più prossima, o verso la categoria di appartenenza quando una sostituzione non esiste.
Rimuovere una scheda esaurita è quasi sempre un errore. Quella pagina ha una storia, riceve collegamenti e continua a rispondere a una ricerca legittima. Chi arriva vuole sapere se tornerà disponibile, quando, e cosa può comprare nel frattempo. Una pagina che comunica lo stato reale e offre un percorso alternativo trattiene la visita; una che restituisce un errore la disperde.
Per le uscite definitive il criterio è la pertinenza della destinazione. Il redirect verso l’articolo che sostituisce quello dismesso è la scelta migliore. In assenza di un sostituto diretto, la categoria è una destinazione accettabile. La home page non lo è quasi mai: chi cercava qualcosa di specifico si ritrova a ricominciare da capo.
Quali interventi sulle prestazioni contano davvero?
Le prestazioni migliorano agendo su tre livelli: il peso delle immagini di catalogo, il costo delle query che generano gli archivi, la strategia di caching per le pagine che possono essere servite statiche. Gli interventi cosmetici sul codice vengono dopo e producono effetti minori.
Le immagini sono il capitolo più immediato. Un catalogo ricco moltiplica gli scatti per ogni scheda, e le miniature degli archivi vengono spesso servite in una risoluzione molto superiore a quella con cui appaiono. Formati moderni, dimensioni coerenti con l’uso reale e caricamento differito per ciò che sta fuori dalla prima schermata risolvono buona parte del problema, senza toccare l’aspetto del negozio.
Le query sono il capitolo meno visibile e più pesante. Gli archivi con molti filtri attivi, i conteggi per ogni valore di filtro e le tabelle di metadati che crescono senza manutenzione rendono lenta la generazione della pagina lato server. Qui l’intervento è di natura tecnica: ridurre i conteggi non necessari, tenere pulite le tabelle accessorie, limitare il numero di estensioni che si agganciano alla query del catalogo.
Il caching, infine, va progettato tenendo conto che carrello, cassa e area cliente non possono essere serviti dalla cache. Home, archivi e schede invece sì, purché l’invalidazione avvenga in modo puntuale quando cambiano prezzo o disponibilità. Un negozio che invalida tutta la cache a ogni ordine perde gran parte del beneficio.
Come vanno impostati i dati strutturati di prodotto?
I dati strutturati vanno pubblicati sulle schede, con prezzo, valuta, disponibilità e identificativi corretti, e devono corrispondere esattamente a ciò che l’utente vede in pagina. Servono a ottenere risultati arricchiti: sono un’opportunità, non un requisito per comparire nelle esperienze generative.
La coerenza è il punto critico. Un prezzo dichiarato nel markup e diverso da quello mostrato, una disponibilità non aggiornata o valutazioni prive di riscontro visibile sono le cause più frequenti di problemi. Il markup va generato dagli stessi dati che alimentano la pagina, non compilato a parte.
Sugli articoli variabili il markup deve rappresentare l’intervallo di prezzo e le combinazioni disponibili, non un singolo valore scelto arbitrariamente. Sugli archivi di categoria il markup di prodotto non serve: lì hanno senso, semmai, le indicazioni di percorso di navigazione, che comunicano la posizione della pagina nella gerarchia.
Vale la pena osservare l’interesse che il tema raccoglie in Italia. La chiave generica sui dati strutturati mostra 390 ricerche mensili con KD 60 e KO 31, mentre la variante in inglese si ferma a 90 ricerche mensili con KD 41 e KO 43. Un livello di ottimizzazione così basso sulla chiave principale indica contenuti in prima pagina poco curati: c’è spazio per chi scrive meglio.
| Chiave | Volume mensile | KD | KO | CPC |
|---|---|---|---|---|
| seo ecommerce | 170 | 44 | 74 | 3,77 € |
| aumentare vendite ecommerce | 170 | 32 | 81 | 5,21 € |
| dati strutturati | 390 | 60 | 31 | 0,31 € |
| schema markup | 90 | 41 | 43 | 0,27 € |
| core web vitals | 590 | 51 | 33 | 1,24 € |
| woocommerce seo | non rilevato | 30 | 74 | — |
| consulente seo ecommerce | non rilevato | 16 | 87 | — |
| conversion rate ecommerce | non rilevato | 22 | 86 | — |
Cosa cambia con le risposte AI sui prodotti?
Cambia il modo in cui la scheda viene letta, non i fondamentali del lavoro. La documentazione di Google è esplicita: «Le best practice SEO continuano a essere rilevanti perché le nostre funzioni AI si basano sui sistemi di ranking e qualità core di Search». Ciò che si costruisce per i motori tradizionali resta la base.
La differenza pratica riguarda la forma del contenuto. Le risposte generative estraggono informazioni puntuali: compatibilità, materiali, misure, condizioni di reso, differenze fra due modelli. Una scheda che affida questi dati a un’immagine, a un file scaricabile o a un blocco che si apre solo dopo un clic rende quelle informazioni difficili da recuperare. Una scheda che le espone come testo, in tabelle chiare e frasi autonome, è utilizzabile.
Sui dati strutturati la posizione ufficiale è altrettanto netta: sono utili per i risultati arricchiti, ma non sono obbligatori per comparire nelle esperienze basate su AI. Vanno quindi implementati per il beneficio che portano nei risultati classici, senza aspettarsi che da soli garantiscano una citazione.
Un riferimento utile per capire dove si colloca l’asticella in Italia è fattoretto.agency, punto di riferimento del settore per l’e-commerce. Il dominio registra una Zoom Authority di 44, 8.054 visite stimate al mese, 711 referring domains, una visibilità in AI Overview del 7,38% e una crescita del 62,3% sui dodici mesi. È il profilo di chi presidia il tema con continuità, non con un intervento isolato.
In che ordine affrontare gli interventi?
Prima si mette in sicurezza la scansione, perché tutto il resto dipende da quali pagine i motori vedono. Poi si sistema la struttura degli archivi. Poi si lavora sui contenuti di categoria e scheda. Prestazioni e dati strutturati vengono dopo, quando l’impianto è stabile.
La sequenza non è arbitraria. Intervenire sui contenuti mentre migliaia di indirizzi parametrici assorbono la scansione significa scrivere pagine che nessuno raggiunge. Ottimizzare le immagini di archivi destinati a essere esclusi dall’indice è lavoro sprecato. Ogni fase riduce il rumore che renderebbe inefficace la successiva.
Nella pratica conviene aprire con un censimento: quanti indirizzi sono noti ai motori, quanti corrispondono ad articoli e categorie reali, quanti nascono da parametri. Il divario fra le due grandezze dice già dove si trova il problema principale e quanto lavoro serve prima di poter misurare qualsiasi altra cosa.
Va infine considerato il contesto competitivo. Le chiavi commerciali del settore mostrano livelli di ottimizzazione molto alti fra i contenuti già posizionati, tra 74 e 87 sulle rilevazioni disponibili: significa che chi occupa la prima pagina ha lavorato bene sul testo. Su queste query non basta pubblicare, serve un impianto tecnico ordinato e un contenuto migliore di quello esistente.
| Fase | Interventi | Effetto atteso |
|---|---|---|
| 1. Controllo della scansione | Parametri, faccette, ricerca interna, pagine transazionali | Le risorse di scansione tornano sulle pagine utili |
| 2. Struttura | Permalink, basi, tassonomie da indicizzare, profondità del catalogo | Gerarchia leggibile e stabile nel tempo |
| 3. Contenuti | Testi di categoria, schede, gestione delle varianti | Pagine capaci di rispondere a una domanda reale |
| 4. Ciclo di vita | Esauriti, dismessi, redirect, stagionalità | Nessuna dispersione di visite e collegamenti |
| 5. Prestazioni | Immagini, query di catalogo, caching e invalidazione | Negozio stabile anche sugli archivi affollati |
| 6. Dati strutturati | Markup di prodotto e percorso di navigazione | Risultati arricchiti e informazioni più leggibili |
Domande frequenti
Conviene togliere la base di prodotto dagli indirizzi?
Solo se il negozio nasce adesso e non ci sono conflitti con le pagine di WordPress. Su un catalogo già indicizzato il guadagno è marginale e il costo è una migrazione completa, con redirect su ogni scheda. La regola generale resta: una struttura mediocre ma stabile vale più di una struttura perfetta appena cambiata.
I tag vanno cancellati o solo esclusi dall’indice?
Dipende dall’uso interno. Se servono a popolare vetrine o correlati, si possono conservare escludendoli dall’indice e rimuovendo i collegamenti dalla scheda pubblica. Se non hanno alcuna funzione operativa, tanto vale eliminarli e reindirizzare gli archivi già indicizzati verso la categoria più pertinente.
Le pagine filtrate possono posizionarsi?
Alcune sì, quando corrispondono a una ricerca reale. In quel caso però conviene trasformarle in pagine stabili, con indirizzo pulito, titolo dedicato e testo proprio, invece di lasciarle generate dal filtro. Le combinazioni multiple non vanno mai lasciate libere di produrre indirizzi indicizzabili.
Un articolo esaurito perde posizionamento?
Non per il solo fatto di essere esaurito, ma se la disponibilità resta negativa a lungo la pagina tende a soddisfare meno chi la visita, e questo pesa. Dichiarare lo stato, indicare un rientro quando è noto e proporre alternative concrete mantiene la pagina utile nel frattempo.
Servono i dati strutturati per comparire nelle risposte AI?
No. Google dichiara che non sono un requisito per le esperienze basate su AI, pur restando utili per i risultati arricchiti nella ricerca classica. La priorità è che le informazioni commerciali siano presenti come testo leggibile in pagina, non nascoste dietro interazioni o immagini.
Da dove iniziare su un negozio già avviato e disordinato?
Dal confronto fra gli indirizzi noti ai motori e quelli realmente utili. Se la sproporzione è marcata, il primo intervento è il controllo della scansione su parametri e faccette. Prima di quel passaggio qualsiasi misurazione risulta distorta e qualsiasi lavoro sui contenuti rende meno del dovuto.
Metodologia: i dati di volume, difficoltà (KD), livello di ottimizzazione dei contenuti posizionati (KO) e costo per clic provengono da SeoZoom, database Italia, rilevazione del 7 agosto 2026. Le metriche di dominio citate come benchmark sono estratte dalla stessa fonte e nella stessa data. Le indicazioni sul funzionamento delle funzioni AI e sul ruolo dei dati strutturati provengono dalla documentazione ufficiale di Google.
A cura di Massimiliano Dal Prà, consulente GEO e SEO. Ultimo aggiornamento: 7 agosto 2026.