Un visiteur arrive sur une page produit depuis Google, cherche la rubrique SAV, ne la trouve pas en deux clics et quitte le site. Ce scénario se répète chaque jour sur des milliers de sites dont l’arborescence a grandi sans plan. Le problème n’est pas le volume de pages, c’est l’absence d’une carte lisible qui relie chaque contenu aux autres.
Plan de site HTML et sitemap XML : deux rôles distincts pour la navigation
On confond souvent le plan de site destiné aux visiteurs (une page HTML listant les rubriques) et le sitemap XML lu par les robots d’exploration. Les deux partagent un objectif (rendre les pages trouvables), mais leurs publics et leurs formats diffèrent.
Le plan HTML est une page consultable par un humain. Il présente les catégories, sous-catégories et pages clés sous forme de liens cliquables. Quand la navigation principale ne suffit pas, cette page devient un filet de sécurité pour le visiteur perdu.
Le sitemap XML, lui, est un fichier technique soumis aux moteurs de recherche. Google recommande d’y inclure les URL prioritaires, mais un sitemap XML ne garantit ni l’exploration ni l’indexation d’une page. Une URL isolée dans le fichier, sans lien interne pointant vers elle, risque d’être ignorée. En consultant le plan du site Superfora, on observe comment les deux niveaux coexistent : une structure lisible pour l’utilisateur, doublée d’un fichier destiné aux robots.
Concevoir un plan de site qui reflète le parcours réel des visiteurs
La plupart des plans de site reproduisent l’organigramme interne de l’entreprise : « À propos », « Nos services », « Contact ». Ce découpage a du sens pour l’équipe, rarement pour le visiteur qui cherche une réponse précise.
Partir des requêtes, pas des départements
Avant de dessiner l’arborescence, on liste les questions que les visiteurs posent réellement. Les données de la Search Console, les suggestions de recherche interne et les mots-clés à intention informationnelle fournissent la matière première. Chaque groupe de requêtes proches devient une branche du plan.
Regrouper les pages par intention utilisateur plutôt que par logique métier réduit le nombre de clics nécessaires. Un visiteur qui tape « délai de livraison » doit tomber sur la bonne page sans passer par « Nos engagements » puis « Logistique ».
Limiter la profondeur à trois niveaux
Au-delà de trois niveaux de navigation (accueil, catégorie, page), les taux de consultation chutent. Le plan de site doit refléter cette contrainte. Si une page se trouve à quatre clics de la page d’accueil, on la remonte ou on ajoute un raccourci depuis une catégorie parente.
- Niveau 1 : catégories principales visibles dans le menu (5 à 8 rubriques suffisent pour la majorité des sites vitrines ou e-commerce de taille moyenne)
- Niveau 2 : sous-catégories qui précisent l’intention (par exemple « Chaussures de randonnée » sous « Chaussures »)
- Niveau 3 : pages finales (fiches produits, articles, pages de service) reliées entre elles par des liens contextuels
Maillage interne et navigation : rendre chaque page accessible
Un plan de site, aussi complet soit-il, ne remplace pas un maillage interne solide. Les liens contextuels dans le corps du texte, les fils d’Ariane et les menus secondaires sont les vrais vecteurs de circulation sur le site.
Fil d’Ariane et position de l’utilisateur
Le fil d’Ariane indique au visiteur où il se trouve dans l’arborescence. Il permet aussi de remonter d’un niveau sans revenir à l’accueil. Pour les moteurs de recherche, il confirme la hiérarchie entre les pages. Chaque étape du fil doit correspondre à une page réelle et cliquable.
Liens contextuels dans le contenu
Un lien placé dans un paragraphe, sur une ancre descriptive, transmet plus de valeur qu’un lien générique en bas de page. On privilégie des ancres qui décrivent la page de destination (« voir les conditions de retour ») plutôt que des formules vagues.
Les pages orphelines (sans aucun lien interne pointant vers elles) restent invisibles pour les robots comme pour les visiteurs. Le plan de site HTML peut les rattraper, mais la solution durable consiste à les intégrer dans le maillage dès leur création.
Accessibilité du plan de site : navigation clavier et taille des zones cliquables
Un plan de site bien structuré perd son utilité si une partie des visiteurs ne peut pas l’utiliser. Les critères d’accessibilité publiés par le W3C dans WCAG 2.2 (octobre 2023) incluent des exigences sur la visibilité de l’élément sélectionné au clavier et la taille minimale des zones interactives.
En pratique, cela signifie que chaque lien du plan de site doit être atteignable via la touche Tab, avec un indicateur visuel clair (contour, changement de couleur). Les menus fixes qui recouvrent le contenu posent un problème particulier : ils peuvent masquer l’élément en focus et empêcher la navigation au clavier.
- Tester le plan de site en naviguant uniquement au clavier, sans souris
- Vérifier que les zones cliquables sont suffisamment grandes pour un usage tactile (smartphones, tablettes)
- S’assurer qu’aucun élément fixe (bannière, barre de cookies) ne recouvre un lien actif pendant la navigation
- Contrôler le contraste entre le texte des liens et l’arrière-plan
Maintenir le plan de site à jour sans fausser les signaux
Un plan de site obsolète envoie des signaux contradictoires. Des liens morts dans la page HTML frustrent les visiteurs. Dans le sitemap XML, une date « lastmod » mise à jour artificiellement (sans modification réelle du contenu) finit par être ignorée par Google.
On met à jour le champ « lastmod » uniquement lorsqu’un changement significatif a lieu : modification du texte, ajout de données structurées, refonte d’un bloc de liens internes. Un simple changement de date de copyright ne compte pas.
Côté HTML, chaque ajout ou suppression de page doit se répercuter dans le plan. Sur un site de plus de quelques centaines de pages, la génération automatique du plan (via le CMS ou un plugin dédié) évite les oublis. On vérifie manuellement une fois par trimestre que les catégories reflètent encore la réalité du site et les parcours des visiteurs.
Le plan de site n’est pas un document figé qu’on publie à la mise en ligne puis qu’on oublie. C’est un outil vivant, aligné sur la structure réelle du site et sur les besoins de ceux qui le consultent, humains comme robots.
