Checklist per l’architettura SEO di un catalogo tecnico

5 Settembre 2026 · SEO

Un catalogo tecnico deve permettere a persone e motori di ricerca di capire che cosa viene offerto, come le famiglie si differenziano e quali attributi sono utili per scegliere. Se categorie, varianti e filtri vengono progettati soltanto per comodità interna, il risultato può essere un sistema difficile da navigare e pieno di URL duplicate.

Questa checklist aiuta a costruire un’architettura che unisca domanda, modello dati e gestione operativa.

1. Definire le entità del catalogo

Prima di disegnare il menu, elencare gli oggetti reali:

• famiglia o categoria;
• prodotto o modello;
• variante;
• componente o accessorio;
• materiale;
• processo o tecnologia;
• applicazione;
• settore;
• documento;
• ricambio o servizio correlato.

Per ogni entità definire identificatore, attributi, relazioni e responsabile del dato. Se “serie”, “modello” e “variante” vengono usati in modo incoerente, anche URL e filtri diventeranno incoerenti.

2. Separare tassonomia interna e percorso dell’utente

La classificazione ERP può essere necessaria per la gestione, ma non deve per forza diventare la navigazione. Verificare come i clienti arrivano alla scelta:

• conoscono già il codice o il modello;
• partono da una prestazione;
• cercano una compatibilità;
• devono risolvere un problema;
• selezionano materiale o dimensione;
• cercano per macchina, settore o applicazione;
• devono sostituire un componente esistente.

Il catalogo può offrire più percorsi verso lo stesso prodotto senza creare una pagina indicizzabile per ogni combinazione.

3. Valutare le categorie

Una categoria utile dovrebbe avere:

• un insieme coerente di prodotti;
• un criterio di appartenenza comprensibile;
• una domanda o un compito reale;
• caratteristiche che aiutano il confronto;
• contenuto unico sufficiente;
• link a sottocategorie e alternative;
• possibilità di essere mantenuta.

Evitare categorie con un solo prodotto create solo per replicare il nome di una keyword, salvo che rappresentino un’entità stabile e utile.

4. Progettare attributi e unità di misura

Creare un dizionario degli attributi con:

Non usare testi liberi quando serve un dato strutturato. “Fino a 10 bar”, “10bar” e “10 Bar max” non devono essere tre valori diversi.

5. Decidere quando una variante merita una URL

Una variante può meritare una pagina autonoma se:

• ha domanda specifica;
• possiede codice, prezzo, disponibilità o documenti distinti;
• cambia in modo significativo uso o prestazione;
• può essere collegata e condivisa;
• ha contenuto sufficiente per una scelta autonoma.

Può restare una selezione nella pagina madre se cambia solo un’opzione minore e non richiede una risposta distinta. La decisione deve essere coerente per tutta la famiglia.

6. Progettare filtri senza moltiplicare pagine inutili

Per ogni filtro stabilire:

• utilità per la selezione;
• numero e qualità dei risultati;
• stabilità nel tempo;
• possibile domanda organica;
• combinazioni ammesse;
• comportamento dell’URL;
• indicizzabilità;
• presenza nei link interni e nelle sitemap.

Non tutti i filtri devono generare pagine indicizzabili. Un filtro può essere utilissimo per l’utente e restare escluso dall’indice. Le combinazioni con valore possono essere trasformate in landing curate, non lasciate alla generazione automatica.

7. Controllare URL e canonical

Verificare:

• una URL stabile per ogni entità indicizzabile;
• parametri coerenti e non duplicati;
• assenza di sessioni, timestamp o tracking nei link interni;
• canonical autoreferenziali sulle pagine indicizzabili;
• canonical coerenti per varianti e filtri;
• sitemap con sole URL canoniche e valide;
• redirect permanenti quando un prodotto viene sostituito;
• gestione esplicita dei prodotti fuori produzione.

Il canonical non deve diventare un modo per ignorare un numero incontrollato di URL generate dal sistema.

8. Gestire prodotti non disponibili e fuori catalogo

Distinguere:

• temporaneamente non disponibile;
• disponibile su richiesta;
• sostituito da un nuovo modello;
• fuori produzione ma ancora assistito;
• eliminato senza alternativa.

Una pagina storica può essere utile per ricambi, documentazione e sostituzioni. Se viene rimossa, scegliere redirect o status in base all’equivalenza reale. Reindirizzare tutto alla categoria crea confusione.

9. Integrare documenti e contenuti tecnici

Ogni prodotto può collegare:

• schede tecniche;
• manuali;
• certificati;
• disegni e file CAD;
• curve e tabelle;
• guide di selezione;
• ricambi;
• casi e applicazioni;
• domande frequenti specifiche.

I documenti devono avere titolo, versione, lingua, data e relazione con il prodotto. Non lasciare PDF senza contesto o versioni obsolete raggiungibili.

10. Progettare la ricerca interna

La ricerca deve gestire:

• codici completi e parziali;
• sinonimi e acronimi;
• errori comuni;
• unità di misura;
• nomi storici;
• compatibilità e modelli sostitutivi;
• filtri successivi alla query;
• risultati senza corrispondenza.

Registrare le ricerche interne e i “nessun risultato”. Sono una fonte diretta per migliorare dati, sinonimi e offerta.

11. Collegare il catalogo ai sistemi aziendali

Mappare la fonte di verità per:

• anagrafiche e codici;
• prezzi e disponibilità;
• documenti;
• attributi;
• traduzioni;
• stato del prodotto;
• relazioni tra accessori e ricambi.

Definire frequenza di sincronizzazione, gestione degli errori e responsabilità. Un’architettura SEO non è sostenibile se richiede correzioni manuali su migliaia di schede.

12. Misurare qualità e utilizzo

Indicatori utili:

• categorie senza prodotti o con pochi risultati;
• filtri usati e combinazioni senza risultati;
• ricerche interne senza esito;
• percentuale di prodotti con attributi completi;
• URL duplicate o escluse;
• pagine orfane;
• richieste generate per famiglia;
• documenti scaricati in contesti commerciali;
• prodotti visualizzati prima di una RFQ.

Checklist finale

1. Le entità e le relazioni sono definite.
2. La navigazione riflette compiti reali.
3. Le categorie hanno criterio e valore.
4. Gli attributi sono normalizzati.
5. Le varianti seguono regole coerenti.
6. I filtri hanno una politica di indicizzazione.
7. URL, canonical e sitemap sono allineati.
8. I prodotti fuori catalogo hanno stati distinti.
9. Documenti e versioni sono governati.
10. La ricerca interna gestisce codici e sinonimi.
11. ERP, PIM, CMS e commerce hanno responsabilità chiare.
12. Esistono controlli periodici sulla qualità dei dati.

Domande frequenti

Ogni filtro deve essere indicizzabile?

No. La maggior parte dei filtri serve alla navigazione. Rendere indicizzabili solo combinazioni stabili, utili e sostenute da domanda e contenuto.

Quando una variante merita una pagina?

Quando rappresenta un oggetto selezionabile e condivisibile con dati o domanda distinti. Non basta che il sistema possa generare una URL.

Un PDF può sostituire la scheda prodotto?

Raramente. Il PDF può fornire dettaglio, ma la pagina web deve contestualizzare il prodotto, essere navigabile, collegare alternative e offrire un percorso di conversione.

Approfondisci il servizio: SEO industriale.