Colore e taglia possono cambiare molto più dell’immagine: anche prezzo, disponibilità e URL. Per gestire le varianti prodotto SEO, chiarisci quali scelte appartengono alla stessa pagina e quali hanno una destinazione autonoma.
Parti dal catalogo: che cosa identifica il modello e che cosa identifica il singolo articolo acquistabile? Questa distinzione deve restare comprensibile anche nell’interfaccia.
Risposta breve: quando una variante merita un URL indicizzabile?
Una variante può avere un URL dedicato se risponde a una domanda distinta e può essere aperta direttamente con informazioni proprie. Se cambia soltanto una selezione, può bastare la pagina principale. Valuta i gruppi di prodotti separatamente, senza imporre una regola identica a tutto il negozio.
Gruppo, variante e offerta
Un modello di scarpa può essere il gruppo; combinazione di colore e taglia può identificare la variante con SKU e disponibilità propri. In altri cataloghi, il colore ha una pagina visualmente distinta mentre la taglia resta un’opzione. Il modello dati deve riflettere il modo in cui utenti e sistemi acquistano il prodotto.
Definisci identificatori stabili per gruppo, variante e offerta. Non usare un URL di sessione o una posizione nel menu come identità commerciale.
Pagina singola o URL separati?
Una pagina singola consolida segnali e semplifica la scelta quando le differenze sono limitate. Gli URL distinti possono essere utili quando la variante ha domanda propria, immagini e contenuto differenti, assortimento stabile e valore come destinazione condivisibile.
Non creare migliaia di pagine indicizzabili per combinazioni senza domanda. Una taglia specifica raramente merita una landing; un colore o una configurazione riconosciuta come prodotto distinto può meritarla. Applica lo stesso principio usato per la faceted navigation SEO: valore e unicità prima dell’indicizzazione.
| Scenario | URL | Canonical | Indicizzazione |
|---|---|---|---|
| Taglie dello stesso capo senza domanda propria | Selezione sulla pagina famiglia | Pagina famiglia | Una destinazione principale |
| Colore con domanda e immagini specifiche | URL persistente della variante | Autoreferenziale se la pagina è distinta | Da valutare con domanda e contenuto |
| Configurazione non acquistabile | Nessuna landing pubblica stabile | Non applicabile | No |
| Variante fuori produzione con sostituta | URL storico gestito | Coerente con lo stato | Redirect o pagina utile secondo il caso |
Il canonical non dovrebbe contraddire l’esperienza. Se una variante ha URL autonomo, title, immagini, stock e link diretti, ma punta canonical alla famiglia, stai inviando segnali opposti. Se invece i parametri rappresentano soltanto selezioni equivalenti, consolidarli può essere coerente.
URL diretti e selezione persistente
Se una variante ha un URL, aprirlo direttamente deve selezionare l’opzione corretta e mostrare immagine, prezzo, stock e possibilità di acquisto corrispondenti. Lo stato non può dipendere soltanto da cookie o da un click precedente.
Normalizza ordine e formato dei parametri. Evita duplicati come ?color=nero&size=42 e ?size=42&color=nero se rappresentano lo stesso stato. I link devono usare sempre la versione scelta.
Canonical per varianti
Nel modello a pagina singola, le combinazioni possono consolidarsi sulla pagina base quando non sono destinate a essere indicizzate separatamente. Nel modello multi-pagina, una variante con valore autonomo può usare canonical autoreferenziale. Canonicalizzare tutto al parent mentre ogni pagina risponde a una domanda distinta invia segnali contraddittori.
Il tag canonical è un segnale di consolidamento, non un sostituto di URL ordinati, link coerenti e contenuto differenziato.
Esempio ipotetico: scarpa in tre colori e dieci taglie
Il modello genera trenta combinazioni acquistabili. Le taglie non hanno contenuto né domanda separata e possono restare selezioni all’interno della variante colore. I tre colori, invece, possono avere immagini, disponibilità, codici e query propri. Una possibile architettura usa tre URL colore, ciascuno con selettore delle taglie, purché ogni URL sia raggiungibile tramite href e carichi direttamente lo stato corretto.
Il gruppo conserva un identificatore comune; ogni articolo mantiene SKU o GTIN, colore, taglia e disponibilità coerenti tra pagina, structured data e feed. Se l’utente condivide la variante nera numero 42, il ritorno sull’URL deve ricostruire quella selezione oppure dichiarare chiaramente che l’URL rappresenta soltanto il colore.
Seguire una variante dall’URL all’offerta
| Controllo della fixture | Atteso |
|---|---|
| Link con selezione colore blu e taglia 42 | Aprendo l’URL direttamente, le opzioni corrette restano selezionate. |
| Canonical | Segue la scelta documentata per quel modello di URL; non cambia casualmente con l’interazione. |
| Dati visibili e markup | Prezzo e disponibilità si riferiscono alla variante selezionata o al modello di gruppo correttamente descritto. |
| Variante non disponibile | Niente disponibilità inventata; alternative e stato comprensibili. |
Ripeti il campione con una variante in stock e una esaurita. Se il feed usa URL di variante, confronta anche la landing realmente aperta. Questo esempio non impone di indicizzare ogni taglia.
ProductGroup e dati strutturati
Google documenta ProductGroup con proprietà come variesBy, hasVariant e productGroupID. Ogni variante deve avere un identificatore univoco e il markup Product richiesto. Le implementazioni a pagina singola e multi-pagina hanno requisiti diversi.
Il markup deve essere completo per la pagina servita e coerente con la selezione. Se JavaScript aggiorna la variante, controlla che dati visibili e JSON-LD cambino insieme. Per prezzi e disponibilità dinamici, fornire i dati nel primo HTML può ridurre fragilità.
ProductGroup può descrivere la famiglia e Product le varianti, ma il markup deve rispecchiare l’architettura reale. Prima di implementarlo, definisci attributi variabili, identificatore del gruppo, identificatori degli articoli e proprietà che cambiano. Il database, non il template testuale, deve essere la fonte di queste relazioni.
La documentazione di Google sui dati strutturati per varianti prodotto va letta insieme ai requisiti della pagina. Il markup aiuta a esplicitare il gruppo; non risolve URL duplicati, selettori non crawlable o stock incoerente.
Feed Merchant Center
Nel feed, le varianti richiedono ID distinti e un raggruppamento coerente, per esempio tramite item_group_id quando applicabile. Titolo, link, immagine, colore, taglia, prezzo e stock devono descrivere la variante inviata.
Se il link apre la variante sbagliata o la pagina mostra un prezzo diverso, l’errore non è soltanto di feed. È una divergenza tra catalogo, frontend e destinazione. La guida ai dati prodotto strutturati spiega come controllare le fonti.
Internal linking e sitemap
Collega soltanto le varianti che vuoi far scoprire e considera l’impatto dei selettori generati come link. Se ogni taglia produce un href, lo spazio di crawling può crescere senza beneficio. Le varianti indicizzabili devono essere raggiungibili tramite percorsi stabili e, quando appropriate, incluse nella sitemap come URL canonici.
Non inserire in sitemap tutte le combinazioni soltanto perché il sistema può generarle.
Esaurimento e cambio di stato
Una variante esaurita non rende necessariamente inutile l’intero gruppo. Mantieni disponibili le altre opzioni, comunica lo stato e offri alternative chiare. Aggiorna contemporaneamente pagina, structured data e feed. Se una variante scompare definitivamente, valuta domanda e sostituto prima di decidere redirect o rimozione.
QA per le varianti prodotto SEO
Costruisci una matrice di test, non un singolo URL perfetto. Includi un gruppo con tutte le opzioni disponibili, una combinazione esaurita, una variante con prezzo diverso, un parametro invalido e un prodotto senza identificatore globale. Se il sito opera in più mercati, ripeti il campione dove assortimento o valuta cambiano.
- apri direttamente ogni URL di esempio;
- verifica variante selezionata, SKU, immagine, prezzo e stock;
- controlla status, canonical e link interni;
- confronta HTML, DOM, JSON-LD e feed;
- prova combinazioni valide, invalide ed esaurite;
- misura URL generati e richieste dei crawler;
- controlla i cambi dopo aggiornamenti di tema o app.
Monitora nel tempo il numero di URL variante scoperti, le impression per combinazione e gli errori di Merchant Center. Se una modifica al selettore raddoppia improvvisamente gli URL richiesti dai crawler, verifica parametri e link prima che il problema si estenda.
- Apri ogni URL direttamente, senza stato di sessione.
- Confronta title, H1, canonical, immagine e selezione attiva.
- Verifica link HTML tra varianti strategiche.
- Confronta SKU, GTIN, prezzo e stock con feed e checkout.
- Testa combinazioni non disponibili e rimozioni.
- Controlla parametri equivalenti e catene di redirect.
Crawl budget e combinazioni di variante
Conta gli indirizzi creati dai selettori e prova a invertire l’ordine degli attributi. Se ottieni nuovi URL per la stessa selezione, controlla router e link generati. Il catalogo acquistabile e quello raggiungibile dai crawler non dovrebbero divergere senza una ragione.
Confronta le richieste dei crawler con le varianti che ricevono ricerche pertinenti. Se molte richieste finiscono su duplicati, verifica prima i componenti che generano gli URL: aggiungere canonical senza correggere la sorgente può lasciare il problema aperto.
Se il catalogo genera duplicati o Google riceve varianti diverse da quelle mostrate agli utenti, contattami per definire un modello di URL e dati coerente prima di espanderlo.
