Un plan de site mal conçu ne pose pas qu’un problème d’ergonomie. Depuis que Google a remplacé le FID par l’INP (Interaction to Next Paint) comme Core Web Vital en mars 2024, la réactivité de chaque interaction sur une page compte dans le classement. Un mega-menu JavaScript mal optimisé qui dépasse le seuil de 200 ms en INP dégrade directement la visibilité organique, même si le sitemap XML est techniquement propre.
INP et navigation : le signal SEO que les plans de site ignorent
La plupart des guides sur l’arborescence web traitent la structure comme un exercice purement logique : catégories, sous-catégories, profondeur de clic. Nous observons que cette approche omet un facteur technique devenu déterminant.
L’INP mesure la latence de toutes les interactions utilisateur pendant une visite, pas uniquement la première. Un menu déroulant avec des animations CSS lourdes, un filtre de catégories qui déclenche un re-render complet du DOM, ou un footer surchargé de liens internes qui ralentit le parsing : chacun de ces éléments de navigation alimente le score INP.
Nous recommandons de tester chaque composant de navigation isolément avec les outils de Chrome DevTools (onglet Performance). Si l’ouverture d’un sous-menu prend plus de 200 ms entre le clic et le rendu visuel, le composant doit être refactoré avant toute réflexion sur l’arborescence. Pour observer comment un plan du site Pucker Up structure ses entrées sans surcharge, c’est un bon exemple de sitemap léger qui ne pénalise pas la réactivité globale.
Arborescence de site web et profondeur de crawl : la règle des trois clics est obsolète
La fameuse règle des trois clics n’a jamais été validée par une étude rigoureuse. Ce qui compte pour les moteurs de recherche, c’est la profondeur de crawl effective, c’est-à-dire le nombre de liens que Googlebot doit suivre depuis une page d’entrée pour atteindre un contenu.
Un site de 500 pages avec une arborescence plate (toutes les pages à deux niveaux) distribue mieux le budget de crawl qu’un site de 50 pages organisé en cinq niveaux de catégories imbriquées. La profondeur n’est pas un problème de nombre de clics pour l’utilisateur, mais de nombre de sauts pour le robot.
Structurer les catégories par intention de recherche
Organiser les pages par thématique métier semble naturel. En SEO, c’est souvent une erreur. Les catégories d’un site doivent refléter les intentions de recherche des utilisateurs, pas l’organigramme de l’entreprise.
- Regrouper les pages qui répondent à une même requête cible sous un même noeud parent, même si elles concernent des services différents en interne
- Créer des pages de catégorie qui ciblent explicitement un mot-clé de volume (ex : « création site internet » plutôt que « nos prestations web »)
- Supprimer les niveaux intermédiaires qui n’ont pas de requête associée : si personne ne cherche le terme, la page de catégorie ne sert qu’à diluer le maillage
Chaque niveau d’arborescence doit correspondre à une requête réelle. Un niveau sans requête est un niveau inutile pour le SEO et un clic supplémentaire pour le visiteur.
Accessibilité et navigation : l’European Accessibility Act change la donne
Depuis le 28 juin 2025, l’European Accessibility Act impose des exigences concrètes sur la navigation des sites destinés aux consommateurs dans l’UE. La norme de référence est l’EN 301 549, alignée sur WCAG 2.2 niveau AA.
Concrètement, trois points impactent directement l’organisation d’un plan de site :
- L’ordre de tabulation doit suivre la logique visuelle du contenu : un menu dont les éléments sont réordonnés en CSS mais pas dans le DOM crée une navigation incohérente au clavier
- Les éléments de navigation masqués (menus hamburger, sous-menus au survol) doivent être accessibles sans souris, avec des états focus visibles
- Les pages du plan de site doivent être atteignables par au moins deux chemins distincts (menu principal, sitemap HTML, fil d’Ariane ou liens internes contextuels)
Ne pas respecter ces critères expose à des sanctions, mais au-delà du risque juridique, un site accessible est un site mieux crawlé. Googlebot ne survole pas un menu, il le parcourt séquentiellement comme un lecteur d’écran.
Sitemap XML et sitemap HTML : deux outils, deux fonctions distinctes
La confusion entre le fichier sitemap.xml et la page HTML de plan de site persiste. Le sitemap XML est un fichier technique destiné aux robots d’indexation. Il liste les URL avec leurs métadonnées (date de modification, priorité). La page HTML de plan de site est destinée aux utilisateurs et à l’accessibilité.
Nous recommandons de maintenir les deux, mais avec des logiques différentes. Le sitemap XML doit contenir uniquement les pages indexables (pas de pages paginées, pas de pages filtres, pas de redirections). Un sitemap XML propre ne liste que les URL en 200 avec une balise canonical auto-référente.
Fréquence de mise à jour du sitemap XML
Un sitemap statique généré une fois à la mise en ligne du site perd sa valeur après quelques mois. Les CMS comme WordPress régénèrent le fichier automatiquement, mais cette régénération inclut parfois des URL indésirables (pages auteur, archives par date, pages de tags vides).
Vérifier trimestriellement que le sitemap XML ne contient pas d’URL orphelines ou d’URL renvoyant un code 404 est un minimum. Google Search Console signale ces incohérences dans le rapport de couverture, mais avec un délai qui peut atteindre plusieurs semaines.
Le plan de site HTML, lui, doit rester lisible : une page avec 2 000 liens non hiérarchisés n’aide personne. Regrouper les liens par section et limiter l’affichage aux pages stratégiques rend cette page utile pour les visiteurs comme pour le maillage interne.
L’organisation d’un plan de site n’est pas un exercice ponctuel. La structure évolue avec le contenu, les requêtes ciblées et les contraintes techniques. Un audit trimestriel de l’arborescence, du sitemap XML et de la conformité accessibilité reste le moyen le plus fiable de maintenir une navigation qui sert à la fois les utilisateurs et les moteurs de recherche.