Architettura SEO di un catalogo tecnico: categorie, attributi, filtri e documentazione
31 Luglio 2026 · SEO
Il catalogo interno non coincide con la domanda
ERP, PIM e listini sono progettati per amministrare codici, varianti e processi. La navigazione pubblica deve invece aiutare una persona a partire da famiglia, applicazione, attributo, problema, marchio o codice. Le due strutture devono dialogare, ma non essere necessariamente identiche.
Prima di progettare categorie e URL è necessario mappare prodotti, relazioni e bisogni. Una tassonomia troppo vicina all’organizzazione interna può essere incomprensibile; una tassonomia costruita soltanto sulle keyword può diventare instabile o duplicare dati già gestiti dai filtri.
Famiglie, categorie e livelli
Le categorie dovrebbero rappresentare insiemi comprensibili e durevoli. Ogni livello deve avere una funzione: orientare, confrontare, descrivere o condurre alle schede. Una gerarchia eccessivamente profonda aumenta i passaggi e può indebolire il linking; una gerarchia piatta rende difficile distinguere famiglie e contesti.
- Usare nomi comprensibili al mercato e mantenere la corrispondenza con i dati interni.
- Limitare i livelli che non aggiungono una decisione reale.
- Collegare le categorie principali da navigazione, hub e pagine pertinenti.
- Prevedere testi e criteri di scelta sostanziali, non descrizioni riempitive.
- Gestire fusioni, rinominazioni e prodotti fuori gamma con regole di redirect.
Attributi, varianti e codici
Gli attributi descrivono proprietà utili alla scelta: materiale, misura, pressione, portata, protocollo, potenza, compatibilità. Le varianti sono combinazioni acquistabili o identificabili. Non ogni attributo deve generare una pagina indicizzabile. La decisione dipende da domanda, utilità, quantità di prodotti, stabilità e contenuto disponibile.
I codici possono essere importanti per distributori, ricambi ed equivalenze. La scheda dovrebbe rendere chiara la relazione tra codice, famiglia, alternativa e documenti. Creare pagine quasi vuote per ogni codice può moltiplicare duplicazioni; aggregare tutto in un PDF può rendere impossibile la scoperta. Occorre trovare il livello informativo adeguato.
Applicazioni, settori e problemi
Le pagine applicative meritano un URL quando spiegano requisiti, condizioni, configurazioni e criteri specifici. Una semplice lista “adatto a settore X” non è sufficiente. Le pagine settore devono mostrare differenze reali, come norme, ambiente, qualità o processo di acquisto, e non replicare la stessa descrizione con il nome del comparto cambiato.
I problemi possono generare guide o soluzioni quando aiutano a scegliere e collegano più prodotti. Devono indicare condizioni e limiti: un contenuto che suggerisce una soluzione universale può essere tecnicamente scorretto e commercialmente dannoso.
Navigazione a faccette e filtri
I filtri sono essenziali per l’utente, ma possono generare un numero enorme di combinazioni URL. Google raccomanda di evitare spazi infiniti, URL duplicati e ordinamenti indicizzati senza valore. La strategia deve distinguere tra faccette utili alla navigazione, combinazioni che meritano landing curate e URL da non rendere indicizzabili.
| Combinazione | Indicizzazione tipica | Condizione |
|---|---|---|
| Categoria principale | Sì | Contenuto, domanda e prodotti sufficienti |
| Attributo molto cercato | Possibile | Intento distinto e pagina curata |
| Due o più filtri rari | Di norma no | Evitare pagine sottili e spazi infiniti |
| Ordinamento prezzo/nome | No | Non cambia sostanzialmente il contenuto |
| Ricerca interna | No | URL dinamici e risultati variabili |
| Applicazione sostanziale | Sì | Requisiti, criteri, prodotti e prove specifici |
Le scelte tecniche possono includere link non crawlable per certe combinazioni, canonical, robots, noindex o assenza di URL persistente, ma vanno progettate insieme a UX e sviluppo. Non esiste una regola unica valida per tutte le piattaforme.
URL, canonical e duplicati
Google consiglia strutture URL coerenti e riduzione delle alternative che restituiscono lo stesso contenuto. Parametri leggibili, normalizzazione di maiuscole e minuscole e uso consistente degli identificatori aiutano. La canonical è un segnale per indicare la versione rappresentativa, non un rimedio per generare indiscriminatamente duplicati.
Varianti di lingua, valuta, sessione, ordinamento e tracking devono essere gestite. Le sitemap dovrebbero contenere URL canonici e utili. Il linking interno deve puntare alla versione preferita. Un controllo periodico di Search Console e crawl permette di vedere quali combinazioni vengono scoperte e indicizzate.
Schede prodotto e pagine categoria
La categoria aiuta a capire differenze e scegliere; la scheda permette di verificare il singolo prodotto. Una categoria non deve essere soltanto una griglia, soprattutto quando le differenze sono tecniche. Può includere criteri, tabella comparativa, attributi, applicazioni e FAQ. La scheda deve chiarire denominazione, codice, varianti, compatibilità, documenti, disponibilità e passo successivo.
I contenuti generati dai dati devono essere controllati. Tabelle e specifiche sono preziose, ma il testo deve spiegare cosa significano e per chi. I dati strutturati possono aiutare Google a comprendere elementi di prodotto, ma devono descrivere contenuto visibile e rispettare le linee guida.
PDF, CAD e documentazione
PDF e CAD sono asset importanti, ma non dovrebbero essere l’unico luogo in cui esistono le informazioni. La pagina HTML contestualizza il documento, rende chiaro a quale prodotto e versione appartiene, indica la data e collega alternative. Il sistema deve gestire revisioni e rimozioni, evitando file orfani e link rotti.
Download di schede, certificazioni e manuali possono essere microconversioni utili. La misurazione deve distinguere i tipi di documento e collegarli alle pagine e ai successivi lead, senza attribuire automaticamente un’intenzione commerciale a ogni download.
Ricerca interna e sinonimi
Googlebot non usa normalmente la ricerca interna per scoprire i prodotti; servono link crawlable, paginazione e sitemap. Per l’utente, invece, la ricerca interna può essere decisiva. Deve comprendere codici, sinonimi, errori comuni, marchi ed equivalenze. Le query senza risultati sono una fonte di keyword research e di miglioramento del catalogo.
PIM, ERP, multilingua e governance
Il PIM può diventare la fonte di verità dei dati prodotto, mentre CMS ed e-commerce li presentano in contesti diversi. La governance deve definire owner, campi obbligatori, versioni, traduzioni, documenti e regole di pubblicazione. Nei mercati internazionali, attributi e terminologia possono variare; hreflang aiuta a collegare versioni localizzate, ma non sostituisce l’adattamento.
Il deliverable architetturale
- Modello delle entità: famiglie, prodotti, varianti, attributi, applicazioni e documenti.
- Albero di navigazione e percorsi alternativi.
- Matrice delle faccette con regole URL e indicizzazione.
- Template di categoria e scheda prodotto.
- Mappa URL, canonical, redirect e sitemap.
- Requisiti di ricerca interna e sinonimi.
- Piano dati, owner e workflow di aggiornamento.
- Piano di misurazione: filtri usati, query, zero risultati, documenti e conversioni.
Domande frequenti
Ogni filtro deve creare una pagina indicizzabile?
No. Molti filtri servono soltanto all’utente e genererebbero pagine sottili o duplicate. Si selezionano soltanto combinazioni con intento e contenuto sostanziali.
Come gestire varianti molto simili?
Con una pagina di famiglia o prodotto e selezione delle varianti quando l’intento è lo stesso. Pagine separate sono utili se cambiano contenuto, scelta o domanda in modo significativo.
I PDF possono sostituire le pagine HTML?
Possono essere indicizzati, ma l’HTML offre contesto, navigazione, aggiornamento, conversione e linking. Il PDF dovrebbe essere un asset collegato, non il solo contenuto.
Come si organizza un catalogo multilingua?
Con dati e governance centrali, terminologia locale verificata, URL coerenti, hreflang e pagine adattate alle SERP del paese.
Quando serve un PIM?
Quando volume, varianti, canali, lingue e responsabilità rendono difficile mantenere dati coerenti nel solo CMS o gestionale.
Fonti e riferimenti
- Google Search Central, ecommerce site structure — Navigazione crawlable e importanza dei link.
- Google Search Central, ecommerce URL structure — Parametri e riduzione degli URL duplicati.
- Google Search Central, pagination — Link, paginazione e filtri.
- Google Search Central, canonicalization — Selezione dell’URL rappresentativo.
- Google Search Central, ecommerce best practices — Indice delle linee guida e-commerce.
Approfondisci il servizio: SEO industriale.