Un plan de site qui fonctionne repose sur des choix de hiérarchie effectués avant toute maquette. La profondeur de clics, le regroupement par intention utilisateur et la cohérence des libellés déterminent si un visiteur atteint la bonne page ou abandonne. Créer un plan de site clair exige de traiter la structure comme un livrable technique, pas comme un exercice de rangement intuitif.
Profondeur de clics et budget de crawl : la contrainte technique du plan de site
Chaque page stratégique doit rester accessible en trois clics maximum depuis la page d’accueil. Au-delà, les moteurs de recherche réduisent la fréquence d’exploration, et les visiteurs décrochent. Cette règle de profondeur conditionne toute l’arborescence.
Un site vitrine de cinq à dix pages ne pose aucun problème de profondeur. Les difficultés apparaissent dès qu’un catalogue produit, un blog actif ou des sous-catégories multiples entrent en jeu. Nous recommandons de cartographier la profondeur réelle avec un crawl (Screaming Frog, Sitebulb) avant de figer le menu, car la profondeur perçue dans un tableur ne correspond pas toujours à la profondeur technique.
Un point souvent négligé : les liens JavaScript non crawlables créent des pages orphelines invisibles pour Googlebot. Google rappelle que les liens internes HTML aident à découvrir les pages et à comprendre leur relation. Vérifiez que chaque entrée du plan de site pointe vers une URL accessible via un lien HTML standard, pas un onclick ou un routage côté client sans rendu serveur.
Pour observer concrètement comment une arborescence plate se matérialise, le plan du site de Ludika Studio illustre une structure où l’ensemble des pages reste à un ou deux niveaux de la racine.
Regroupement par intention utilisateur plutôt que par logique interne
La plupart des arborescences reproduisent l’organigramme de l’entreprise ou la nomenclature interne des produits. Le visiteur, lui, raisonne par besoin : comparer, acheter, contacter, comprendre un service. Regrouper les pages par intention de recherche réduit le nombre de clics et le taux de rebond.
La méthode la plus fiable reste le card sorting. Vous présentez les intitulés de vos pages (sur cartes physiques ou via un outil comme Adapté Workshop) à un panel d’utilisateurs cibles. Ils regroupent librement les cartes, puis vous analysez les clusters. Le tree test complète l’exercice : on demande aux participants de localiser une information précise dans l’arborescence proposée, sans interface graphique.
Ces deux tests révèlent des écarts fréquents entre la logique métier et la logique utilisateur. Un prestataire de services peut classer ses offres par secteur d’activité, alors que ses prospects cherchent par type de prestation. Si le card sorting montre un regroupement différent de celui que vous aviez prévu, c’est le signal qu’il faut restructurer.
- Card sorting ouvert : les participants créent eux-mêmes les catégories, utile pour un nouveau site ou une refonte complète
- Card sorting fermé : les catégories sont prédéfinies, utile pour valider une arborescence déjà esquissée
- Tree test : mesure le taux de réussite et le temps mis pour trouver une page dans la hiérarchie, sans influence du design
Libellés de navigation : conventions et accessibilité clavier
Un libellé de menu efficace décrit la destination, pas l’action. « Nos réalisations » fonctionne mieux que « Découvrir » parce que le visiteur sait ce qu’il trouvera derrière le lien. Limitez chaque libellé à deux ou trois mots. Au-delà, le menu devient illisible sur mobile et les tests de tree test montrent une chute du taux de réussite.
Depuis le 28 juin 2025, l’Acte européen sur l’accessibilité s’applique à certains services de commerce électronique destinés aux consommateurs. Pour les sites concernés, la navigation au clavier et la compréhension des parcours font partie des exigences à intégrer dès la conception de la structure.
Le W3C recommande que chaque élément interactif soit atteignable au clavier et que le focus reste visible. En pratique, cela signifie tester si l’on peut ouvrir un menu déroulant, parcourir ses liens et repérer l’élément sélectionné sans souris. Un piège courant : un en-tête fixe qui masque le lien recevant le focus clavier. Le critère WCAG 2.2 « Focus Not Obscured (Minimum) » cible précisément ce problème.
Fil d’Ariane et repères contextuels
Le fil d’Ariane (breadcrumb) complète le menu principal en montrant au visiteur sa position dans la hiérarchie. Il ne remplace pas une arborescence claire, mais il compense les entrées directes depuis un moteur de recherche, où l’utilisateur atterrit sur une page profonde sans contexte.
Implémentez le fil d’Ariane avec le balisage structuré BreadcrumbList (schema.org). Google peut alors afficher le chemin hiérarchique dans les résultats de recherche, ce qui améliore le taux de clic.
Sitemap XML et plan de site HTML : deux livrables distincts
Le sitemap XML s’adresse aux robots d’indexation. Le plan de site HTML s’adresse aux visiteurs. Confondre les deux revient à ignorer l’un des deux publics. Le sitemap XML liste toutes les URL indexables avec leur priorité et leur date de modification. Le plan de site HTML, lui, présente une sélection organisée des pages principales, souvent sous forme de liste hiérarchisée.
Un sitemap XML ne compense pas une mauvaise structure de liens internes. Si une page n’est reliée à aucune autre par un lien HTML, le sitemap XML signale son existence au moteur, mais le manque de maillage interne affaiblit son autorité. Inversement, un plan de site HTML sans sitemap XML ralentit la découverte des nouvelles pages par les crawlers.
- Sitemap XML : fichier technique hébergé à la racine, déclaré dans le robots.txt, limité à 50 000 URL par fichier
- Plan de site HTML : page navigable par les visiteurs, regroupant les liens principaux par catégorie, accessible depuis le pied de page
- Index de sitemaps : nécessaire quand le site dépasse la limite d’un seul fichier XML, il pointe vers plusieurs sitemaps enfants
Quand régénérer le sitemap XML
Chaque ajout, suppression ou redirection de page justifie une mise à jour du sitemap. Sur un CMS comme WordPress, des extensions génèrent automatiquement le fichier. Sur un site statique ou un framework JavaScript avec rendu côté serveur, automatisez la génération du sitemap dans votre pipeline de déploiement pour éviter les oublis.
Le plan de site le plus lisible du monde ne sert à rien si la hiérarchie sous-jacente ne reflète pas les parcours réels des visiteurs. Testez l’arborescence avec des utilisateurs, vérifiez la profondeur technique avec un crawl, et maintenez le sitemap XML synchronisé avec chaque publication. La clarté d’un plan de site se mesure au taux de réussite d’un tree test, pas à l’élégance du menu.
