Checklist per l’architettura di un sito B2B

29 Settembre 2026 · Siti web

L’architettura di un sito B2B deve aiutare pubblici diversi a orientarsi tra offerta, applicazioni, prove e contenuti. Non coincide con il menu e non si risolve scegliendo quante voci mostrare. È l’insieme di tipi di pagina, relazioni, etichette, percorsi e regole con cui il sito rende comprensibile l’azienda.

Questa checklist serve prima di un rifacimento oppure durante un audit di un sito esistente.

1. Costruire l’inventario

Censire:

• URL pubblicate;
• tipo di pagina;
• titolo e obiettivo;
• pubblico;
• traffico e conversioni;
• link interni;
• stato del contenuto;
• owner;
• documenti e asset collegati;
• duplicazioni e pagine orfane.

Non progettare la nuova struttura soltanto guardando il menu attuale. Molte pagine importanti possono essere nascoste o scollegate.

2. Mappare i compiti degli utenti

Per ogni pubblico elencare compiti come:

• capire se l’azienda opera nel proprio ambito;
• trovare una soluzione a un problema;
• confrontare prodotti o approcci;
• verificare requisiti e compatibilità;
• scaricare documentazione;
• valutare prove e casi;
• trovare assistenza o ricambi;
• inviare una richiesta completa;
• contattare una sede o un referente.

Ogni compito deve avere un percorso breve e comprensibile, anche se l’utente entra da una pagina interna.

3. Definire le entità principali

Possibili entità:

• servizi;
• prodotti e famiglie;
• soluzioni;
• settori;
• applicazioni;
• tecnologie;
• problemi;
• risorse;
• casi;
• persone;
• sedi;
• documenti.

Definire quando un’entità merita una pagina autonoma e quale relazione ha con le altre. “Settore” e “applicazione” non sono sinonimi: il settore descrive il contesto, l’applicazione l’uso.

4. Progettare i tipi di pagina

Ogni template deve avere un compito specifico.

Evitare template che ripetono lo stesso testo cambiando soltanto il nome del settore.

5. Disegnare la navigazione globale

Il menu principale deve rappresentare le scelte più frequenti e stabili. Verificare:

• etichette comprensibili al mercato;
• numero di livelli gestibile;
• accesso a contatti e ricerca;
• differenza tra desktop e mobile;
• stato attivo e breadcrumb;
• assenza di voci duplicate;
• priorità commerciale senza nascondere risorse utili.

Un mega menu è utile solo se organizza, non se espone l’intero inventario.

6. Progettare percorsi contestuali

Ogni pagina deve suggerire il passo successivo. Esempi:

• settore → applicazioni e servizi pertinenti;
• servizio → metodo, casi e risorse;
• prodotto → varianti, documenti e accessori;
• articolo → pagina commerciale e approfondimenti;
• caso → soluzione utilizzata;
• documento → prodotto e versione.

I link devono spiegare la relazione. “Scopri di più” ripetuto non aiuta a capire la destinazione.

7. Verificare etichette e linguaggio

Testare le etichette con persone reali o almeno con vendite e assistenza. Controllare:

• termini interni non conosciuti;
• acronimi;
• differenze tra mercati;
• parole troppo generiche come “soluzioni”;
• sovrapposizione tra categorie;
• traduzioni letterali;
• nomi storici ancora usati dai clienti.

Una buona etichetta permette di prevedere cosa si troverà dopo il clic.

8. Integrare ricerca interna e filtri

La ricerca è particolarmente utile con cataloghi, codici, documenti o molti contenuti. Deve gestire:

• sinonimi;
• codici;
• errori;
• filtri;
• priorità dei risultati;
• contenuti obsoleti;
• nessun risultato;
• tracciamento delle query.

Non usare la ricerca per compensare una navigazione incomprensibile.

9. Rendere visibili prove e fiducia

Le prove non devono essere confinate in una pagina istituzionale. Collegare dove pertinenti:

• casi;
• certificazioni;
• dati;
• processi;
• persone;
• documenti;
• clienti autorizzati;
• metodologie;
• limiti e condizioni.

Ogni pagina commerciale deve rispondere a “perché dovrei credere a questa affermazione?”.

10. Progettare conversioni diverse

Distinguere:

• contatto generale;
• richiesta tecnica;
• richiesta di offerta;
• richiesta documento;
• assistenza;
• demo o appuntamento;
• iscrizione;
• candidatura.

Per ogni percorso definire campi, routing, conferma, tempo di risposta e pagina di ringraziamento. Non inviare tutto a una casella generica.

11. Verificare SEO e indicizzazione

Controllare:

• una pagina primaria per ogni intento;
• URL stabili;
• gerarchia dei link;
• pagine orfane;
• breadcrumb;
• sitemap;
• duplicazioni tra settori e servizi;
• pagine filtro e ricerca;
• contenuti troppo simili;
• canonical e redirect.

L’architettura SEO deriva dalle relazioni e dalla domanda, non soltanto dalla profondità delle cartelle.

12. Definire governance e manutenzione

Per ogni tipo di pagina stabilire:

• chi può crearla;
• campi obbligatori;
• criteri di pubblicazione;
• tassonomie ammesse;
• regole di linking;
• owner;
• trigger di revisione;
• procedura di ritiro;
• gestione delle traduzioni.

Senza governance, la struttura ordinata del lancio si degrada rapidamente.

Test pratici prima dell’approvazione

Chiedere a persone non coinvolte nel progetto di completare compiti:

1. trovare una soluzione per un’applicazione;
2. confrontare due offerte;
3. verificare una certificazione;
4. trovare un documento;
5. richiedere un preventivo;
6. tornare alla categoria precedente;
7. capire chi contattare.

Misurare successo, tempo, errori e parole cercate. Correggere la struttura prima del design finale.

Checklist finale

1. Inventario e dati sono disponibili.
2. I compiti dei pubblici sono mappati.
3. Entità e tipi di pagina sono distinti.
4. Il menu rappresenta scelte reali.
5. Esistono percorsi contestuali.
6. Etichette e linguaggio sono comprensibili.
7. Ricerca e filtri hanno un ruolo chiaro.
8. Prove e documenti sono collegati.
9. Le conversioni hanno routing distinto.
10. SEO, URL e linking sono coerenti.
11. La struttura è testata con compiti.
12. Governance e manutenzione sono definite.

Domande frequenti

Quante voci deve avere il menu?

Non esiste un numero universale. Deve consentire scelte comprensibili senza nascondere le priorità. La qualità delle categorie conta più del conteggio.

Settori e applicazioni vanno separati?

Sì quando descrivono dimensioni diverse e hanno contenuti distinti. Se le pagine sarebbero quasi identiche, è meglio evitare duplicazioni.

La ricerca interna è sempre necessaria?

No. Diventa importante con molti prodotti, codici, documenti o contenuti. Un sito piccolo può funzionare meglio con navigazione e filtri semplici.

Approfondisci il servizio: Siti web B2B.