SEO des méga-menus

En bref — Un méga-menu est un grand menu déroulant de navigation qui affiche de nombreux liens à la fois, regroupés en colonnes. Pour le SEO, ce ne sont que des liens internes : chaque lien doit donc être un véritable <a href> afin que Google puisse le suivre de façon fiable. L’erreur la plus courante consiste à construire le panneau avec des gestionnaires de clic JavaScript plutôt qu’avec de vrais liens : tout semble fonctionner pour l’utilisateur, mais les moteurs de recherche ne peuvent pas l’explorer. Sur mobile, vérifiez que le menu hamburger conserve les mêmes liens.

Qu’est-ce qu’un méga-menu ?

Un méga-menu est un panneau de navigation escamotable — masqué jusqu’au survol ou au clic sur une entrée de premier niveau — qui affiche de nombreux liens à la fois, classés par catégorie dans des colonnes faciles à parcourir. Un menu déroulant ordinaire présente une courte liste unique. Dans un méga-menu, « Chaussures » peut ouvrir trois colonnes, « Homme », « Femme » et « Enfant », chacune avec ses sous-catégories. Les grandes boutiques en ligne les utilisent pour permettre aux clients d’atteindre en un clic une catégorie profonde depuis n’importe quelle page du site.

L’essentiel est le suivant : un méga-menu n’est qu’un ensemble de liens internes placé dans un habillage sophistiqué. Les règles générales des liens internes s’appliquent donc ici. Si vous n’avez pas encore lu l’article consacré aux liens internes dans ce groupe thématique, commencez par lui : cette page en est le complément pratique, consacré à la manière de ne rien casser.

La règle la plus importante

Pour qu’un moteur de recherche puisse suivre un lien, celui-ci doit être un véritable lien HTML : un élément <a> doté d’un attribut href :

<a href="/shoes/mens/">Men's shoes</a>

C’est tout. Si les liens de votre méga-menu sont de véritables <a href>, vous avez fait 90 % du travail. Les problèmes commencent lorsqu’un développeur remplace les liens par un comportement JavaScript du type « cliquer pour accéder à cette page ». Pour une personne, le résultat paraît identique : elle clique et la page s’ouvre. Pour Google, il n’y a toutefois rien à suivre, si bien que ces pages peuvent passer inaperçues.

Comment vérifier votre méga-menu

Faites un clic droit sur la page, choisissez Afficher le code source de la page (et non « Inspecter »), puis recherchez l’un des liens du menu. S’il apparaît sous la forme <a href="..."> dans ce code source brut, tout va bien. Si les liens n’apparaissent que dans l’inspecteur d’éléments — le DOM actif construit par JavaScript — mais pas dans le code source, signalez ce problème à votre développeur.

N’oubliez pas le mobile

Sur téléphone, le méga-menu devient généralement un menu hamburger ou un accordéon. Pour alléger l’interface, les équipes raccourcissent parfois ce menu et suppriment par inadvertance des liens qui n’existaient que là. Google attend un contenu mobile équivalent au contenu pour ordinateur : effectuez donc la même vérification sur le menu mobile. Les mêmes liens sont-ils présents, et sont-ils de véritables <a href> ?

Vous cherchez la version détaillée — le mode de défaillance JavaScript, le traitement du contenu masqué jusqu’au survol, le nombre excessif de liens et un exemple de balisage correct ou incorrect ? Passez à l’onglet Advanced.

En bref — Un méga-menu est un ensemble de liens internes dans une interface plus imposante : toutes les règles des liens internes s’y appliquent, à commencer par l’exigence <a href>. La défaillance la plus courante est un panneau au clic ou au survol dont les « liens » JavaScript ne sont pas de véritables ancres. L’utilisateur croit voir des liens, mais Google ne peut pas les explorer, ce qui rend silencieusement des pages orphelines si le menu constituait leur seul lien interne. Vérifiez le code source, et non l’inspecteur. Le contenu masqué jusqu’au survol n’est pas automatiquement dévalorisé s’il figure dans le HTML initial et n’est pas chargé uniquement après une interaction : le masquage CSS convient, le chargement AJAX au survol est risqué. Google indique tenir compte de ce contenu, sans avoir documenté une pondération identique à celle du contenu toujours visible. Il n’existe aucune limite stricte au nombre de liens — la règle des 100 liens est un mythe. L’organisation compte : regroupez les liens par catégorie dans des colonnes lisibles, avec des textes d’ancrage descriptifs, pour ne pas aplatir la structure thématique. Le menu hamburger ou accordéon mobile doit conserver les mêmes liens explorables. Les données structurées ne remplacent pas de vrais liens.

Point de départ : un méga-menu n’est qu’un ensemble de liens internes

Posons d’abord le cadre. Le « SEO des méga-menus » n’a rien de magique ni d’indépendant. Un méga-menu est un composant de navigation entièrement constitué de liens internes ; les règles générales qui gouvernent ces liens — lien explorable, texte d’ancrage descriptif, absence de limite magique au nombre de liens — s’appliquent sans modification. Je ne vais pas les redémontrer : l’article sur les liens internes de ce groupe les présente et cette page y renvoie régulièrement.

Les méga-menus méritent néanmoins une page dédiée parce qu’ils concentrent un nombre inhabituellement élevé de liens dans un même composant répété sur tout le site. Cette concentration crée deux risques distincts : un risque d’implémentation — les panneaux JavaScript qui ne génèrent jamais de vrais liens — et un risque structurel — un site trop aplati qui fait perdre à Google le signal de regroupement. L’opposition entre structure plate et profonde, ou entre pyramide et crêpe, est déjà traitée dans les articles sur l’architecture et la structure du site, notamment avec cette phrase de Mueller : “Google can’t recognize which parts of the site belong together.” (traduction) « Google ne peut pas reconnaître quelles parties du site vont ensemble. » Je ne reprendrai pas ce débat ici : cette page porte sur la mise en œuvre concrète.

La défaillance la plus courante : des gestionnaires JavaScript à la place de vrais liens

C’est le problème que je rencontre le plus souvent. Une équipe construit un méga-menu — parfois avec une ancienne extension jQuery ou un composant React/Vue maison — dont les « liens » sont en réalité des gestionnaires de clic, un attribut de routeur sans href, ou du contenu injecté dans le DOM seulement après un survol ou un clic. La liste publiée par Google des formats de liens qu’il ne peut pas explorer de façon fiable correspond précisément à ces modèles :

<a routerLink="products/category">Shoes</a>          <!-- no href -->
<span href="https://example.com">Shoes</span>        <!-- not an anchor -->
<a onclick="goto('https://example.com')">Shoes</a>   <!-- onclick, no href -->

Cette défaillance est particulièrement dangereuse parce qu’elle est silencieuse. Les pages semblent liées : une personne survole le menu, voit le panneau, clique et atteint la catégorie. Rien ne paraît cassé. Pourtant, les pages de destination ne reçoivent du méga-menu ni exploration ni valeur transmise par les liens ; si le menu constituait leur seul lien interne, elles deviennent orphelines. Un arbre de catégories entier peut ainsi être invisible pour Google tout en restant parfaitement navigable pour chaque personne qui le teste. C’est pourquoi ce défaut survit à l’assurance qualité : les humains ne le ressentent pas.

Comment vérifier qu’un méga-menu est réellement explorable

Ne vous fiez pas à la page rendue : examinez le code source.

• Affichez le code source de la page, pas l’inspecteur d’éléments. Le code source montre le HTML brut envoyé par le serveur. L’inspecteur montre le DOM actif après l’exécution de JavaScript et masque donc précisément le problème recherché. Si les liens du panneau apparaissent sous la forme <a href="..."> dans le code source, ils sont rendus par le serveur et sûrs. S’ils n’apparaissent que dans l’inspecteur, c’est un signal d’alerte.
• Outil URL Inspection (Inspection de l’URL) de GSC. Analysez la page dans l’outil d’inspection d’URL de Search Console, puis consultez le HTML rendu ou la page explorée. Vous verrez ainsi ce que Googlebot a effectivement obtenu.

Précisons la nuance : Google exécute désormais JavaScript, si bien qu’un menu construit en JS pourrait être exploré. Mais « pourrait » est le mot important. Le modèle vérifiable et sûr repose sur des liens <a href> rendus par le serveur, puis améliorés progressivement avec JavaScript pour l’animation et l’interactivité — jamais sur des liens dont l’existence dépend de JS. Utilisez JS pour définir le comportement du menu, pas pour faire exister les liens.

Le contenu masqué jusqu’au survol est-il dévalorisé ?

Cette question revient toujours au sujet des méga-menus, et c’est aussi celle pour laquelle les anciennes croyances SEO sont véritablement dépassées. Un panneau masqué jusqu’au survol voit-il tous ses liens dévalorisés parce qu’ils ne sont pas visibles au chargement ?

Pas automatiquement — mais il faut être précis, car les affirmations excessives naissent ici. Les consignes actuelles de Google et une déclaration de John Mueller indiquent que le contenu présent dans le HTML mais masqué visuellement — dans un panneau au survol, un accordéon fermé ou un onglet inactif — est pris en compte et non exclu d’emblée. À la question de savoir si le contenu d’onglets ou d’accordéons masqués était dévalorisé avec l’indexation orientée mobile, Mueller a répondu : “No. Specifically when it comes to content on mobile pages we do take into account anything that’s in the HTML. So if there’s something there that might be visible to users at some point we will include that… so that’s completely normal” (traduction) « Non. En particulier pour le contenu des pages mobiles, nous tenons compte de tout ce qui se trouve dans le HTML. Si un élément est susceptible d’être visible à un moment donné, nous l’incluons… ce qui est tout à fait normal. » Cette déclaration est rapportée dans l’article de Search Engine Journal. La documentation de Google sur l’indexation orientée mobile confirme sur le plan opérationnel qu’il est acceptable de placer du contenu « dans des accordéons ou des onglets » sur mobile s’il reste équivalent à celui de la version pour ordinateur.

Cette citation établit la disponibilité du contenu : il est exploré, rendu et pris en compte plutôt qu’écarté. Elle n’établit pas que le contenu masqué au survol reçoit une pondération identique à celle du contenu toujours visible. Google n’a rien publié sur cette question précise ; il faut donc la considérer comme non documentée, sans supposer une équivalence. Séparez les deux questions : le contenu est-il exclu ? Non, ce point est établi. Se classe-t-il exactement comme le contenu visible ? Ce n’est pas documenté.

Cette position remplace l’ancienne affirmation, datant approximativement de 2015–2016, selon laquelle le contenu placé derrière des onglets ou des zones à développer recevait moins de poids. Cette affirmation précise est obsolète. Les sources n’établissent qu’un point plus étroit : le contenu masqué mais présent dans le HTML n’est pas écarté d’office ; personne n’a toutefois documenté une pondération identique à celle du contenu visible. Ne remplacez donc pas l’ancien mythe de la « dévalorisation » par l’affirmation tout aussi infondée d’une « égalité certaine ».

Une nuance décisive piège cependant beaucoup de monde : « masqué avec CSS » et « chargé uniquement après une interaction » désignent deux situations totalement différentes.

• Un panneau en display:none jusqu’au survol, dont les liens sont déjà présents dans le DOM, ne pose pas de problème : il est indexé normalement.
• Un panneau dont le HTML est chargé par un appel API déclenché au survol risque de ne jamais être exploré.

Il ne s’agit pas alors d’une dévalorisation du contenu masqué, mais d’un problème d’explorabilité. Les liens n’existent pas avant l’action de l’utilisateur, donc le robot ne les voit jamais. La confusion entre ces deux défaillances entretient le mythe. Retenez la distinction : liens masqués avec CSS = acceptables ; liens chargés par AJAX lors de l’interaction = défaillants.

Budget de liens : regroupez, ne déversez pas tout

Il n’existe aucune limite stricte documentée au nombre de liens d’un méga-menu. L’ancienne règle des « 100 liens par page » est un mythe pur et simple, réfuté en détail dans l’article sur les liens internes. Google indique qu’il n’existe pas de nombre idéal magique.

L’absence de limite ne signifie toutefois pas qu’il faut tout entasser. Le véritable levier n’est pas le nombre brut, mais l’organisation. Une session Search Central de 2021, rapportée par Barry Schwartz, évoquait un méga-menu de plus de 1 000 liens et une baisse de trafic après le passage de liens chargés au survol à du HTML statique. Mueller ne s’inquiétait pas du nombre en lui-même, mais du risque qu’un vaste ensemble indifférencié de liens de même niveau aplatisse le regroupement thématique. Selon ses mots : “we think, oh, all of these are equally important, and we don’t really know which of these are connected to each other,” (traduction) « nous pensons que tous ces éléments sont d’importance égale et nous ne savons pas vraiment lesquels sont liés entre eux » tandis que “a pyramid structure helps us a lot more to understand the context of individual pages.” (traduction) « une structure pyramidale nous aide beaucoup plus à comprendre le contexte de chaque page. » Il considérait même comme une correction structurelle légitime le fait de recharger au survol une partie de ces 1 000 liens, à condition de conserver d’autres chemins d’exploration pertinents vers leurs destinations.

Conséquence pratique : un méga-menu bien organisé de 150 liens, avec des en-têtes de colonnes clairs — Homme, Femme, Enfant, puis leurs sous-catégories — préserve le signal hiérarchique. Un mur non organisé de 150 liens ne le préserve pas, malgré un nombre identique. Par conséquent :

• Regroupez selon de véritables limites de catégories. Les colonnes et leurs titres doivent refléter la hiérarchie réelle du site.
• Gardez des colonnes faciles à parcourir. Quelques éléments par groupe, pas une liste alphabétique interminable.
• Employez des textes d’ancrage descriptifs et précis. Ils doivent décrire la destination, et non répéter trente fois « Acheter maintenant ».
• Ne cherchez pas l’exhaustivité. Un méga-menu sert aux grands parcours de découverte. Les pages vraiment prioritaires doivent aussi recevoir des liens contextuels dans le contenu, et non dépendre uniquement du menu global, identique sur toutes les pages et diffusant partout le même signal d’« importance ».

Sur mobile, conservez les mêmes liens dans une interface adaptée

Sur mobile, le méga-menu devient un menu hamburger ou un accordéon. Le piège consiste à le raccourcir pour épurer l’expérience et à supprimer ainsi des destinations qui n’existaient que dans le méga-menu pour ordinateur. Les consignes de Google sur l’indexation orientée mobile indiquent explicitement que le contenu mobile — navigation comprise — doit être équivalent au contenu pour ordinateur. Puisque l’indexation repose sur la navigation mobile, les liens supprimés peuvent paraître moins importants ou, si le méga-menu était leur seul lien interne, ne jamais être découverts.

Effectuez donc sur mobile le même audit que sur ordinateur : affichez le HTML rendu de la navigation mobile, vérifiez que les mêmes destinations sont présentes et que chacune utilise un véritable <a href>. Même test d’explorabilité, même test de parité, dans une interface plus petite.

Cela couvre les destinations, mais pas l’interaction, qui nécessite un contrôle distinct souvent oublié. L’indexation orientée mobile exige le même ensemble de destinations importantes, pas une interaction identique ; un menu hamburger ou accordéon convient donc. Le mécanisme d’affichage doit néanmoins être testé au clavier et pour la gestion du focus : une personne utilisant uniquement le clavier peut-elle atteindre le déclencheur, ouvrir le panneau et parcourir les destinations avec la touche Tab, tandis que l’état aria-expanded reste exact ? Le modèle de navigation par affichage WAI-ARIA fournit un exemple fonctionnel, sans être l’unique implémentation conforme. Testez séparément la parité des destinations et le comportement d’affichage au clavier : un menu peut réussir l’un de ces tests et échouer à l’autre.

Autre mythe : les données structurées ne corrigent pas l’explorabilité

Certains guides présentent le balisage SiteNavigationElement comme un moyen de rendre le menu explorable. Ce n’est pas le cas. Les données structurées peuvent décrire sémantiquement la navigation, mais elles ne remplacent pas de vrais liens explorables. Mueller le rappelle à propos des liens internes : “we don’t use those URLs in the same way as we would use normal internal links on a page.” (traduction) « nous n’utilisons pas ces URL comme nous utiliserions des liens internes normaux sur une page. » Le schéma s’ajoute au-dessus de liens <a href> déjà explorables ; il ne les remplace jamais.

Ce que ces contrôles garantissent — et ne garantissent pas

Des ancres réelles et visibles dans le code source, une structure regroupée, la parité mobile et un mécanisme d’affichage utilisable au clavier éliminent les défaillances précises décrites ci-dessus : pages non découvertes, structure thématique aplatie, rupture de parité et navigation inaccessible. Rien de tout cela ne garantit l’exploration, l’indexation, une hausse du classement ou du trafic, ni une citation par une IA : ces résultats dépendent de bien plus que du balisage de navigation. Traitez les ancres du code source et du rendu, l’extraction par un robot, la parité des destinations ordinateur/mobile et le comportement clavier/focus comme des tests réussite/échec séparés. Un méga-menu peut en réussir certains et en échouer d’autres.

Votre site a-t-il seulement besoin d’un méga-menu ?

Pour résumer — l’analyse complète des structures plates ou profondes se trouve dans les articles sur l’architecture et la structure du site — un méga-menu se justifie lorsque le site est assez vaste pour que la découverte entre catégories constitue un véritable parcours utilisateur et que l’accès global aux catégories profondes réduise sensiblement la profondeur de clic. C’est l’un des meilleurs moyens de maintenir les pages importantes à quelques clics de l’accueil et de viser le repère d’environ trois clics de Bing. Si votre catalogue est petit ou si les éléments de longue traîne du menu sont rarement utilisés, le méga-menu est une surcharge inutile. Décidez d’abord si vous en avez besoin, avant d’optimiser comment le construire ; l’arbre de décision présente ce choix.

Résumé par l’IA

Voici une synthèse de la version avancée :

• Un méga-menu n’est qu’un ensemble de liens internes dans une interface plus grande. Toutes les règles des liens internes s’appliquent, à commencer par l’obligation d’utiliser de vrais <a href>.
• La principale défaillance réelle : un panneau au clic ou au survol dont les liens JavaScript ne sont pas de véritables ancres — onclick, routerLink sans href, ou DOM injecté uniquement après une interaction. Il semble lié pour l’utilisateur, mais Google ne peut pas l’explorer ; si le méga-menu était le seul lien interne d’une page, celle-ci devient orpheline. La défaillance est silencieuse et échappe donc aux tests humains.
• Vérifiez le code source, pas l’inspecteur d’éléments. Le code source montre le HTML brut du serveur : si les liens y figurent sous forme de <a href>, ils sont sûrs. Utilisez aussi l’outil URL Inspection (Inspection de l’URL) de GSC.
• Modèle sûr : des liens <a href> rendus par le serveur et améliorés progressivement avec JS pour l’animation, jamais des liens qui dépendent de JS pour exister.
• Le contenu masqué jusqu’au survol n’est pas exclu d’emblée. Mueller et la documentation actuelle sur l’indexation orientée mobile indiquent que le contenu présent dans le HTML mais masqué visuellement est pris en compte. Google n’a toutefois pas documenté une pondération identique à celle du contenu toujours visible. Nuance essentielle : liens masqués par CSS = acceptables et évalués normalement ; liens chargés uniquement après interaction = risque de ne jamais être explorés. Ce sont deux défaillances différentes.
• Aucune modification du méga-menu ne garantit un résultat. Ancres réelles, liens visibles dans le code source, structure regroupée, parité mobile et affichage utilisable au clavier éliminent des défaillances précises ; ils ne garantissent ni exploration, ni indexation, ni meilleur classement, trafic ou citation par une IA. Validez séparément les ancres du code source et du rendu, l’extraction du robot, la parité ordinateur/mobile et le comportement clavier/focus.
• Aucune limite stricte au nombre de liens : la règle des 100 liens est un mythe. Le véritable levier est l’organisation : catégories, colonnes lisibles et textes d’ancrage descriptifs. La réponse de Mueller sur les méga-menus vise l’aplatissement du regroupement, pas le nombre brut.
• Le mobile doit conserver les mêmes liens explorables, et non proposer un menu hamburger tronqué : Google attend une parité du contenu mobile.
• Les données structurées (SiteNavigationElement) ne remplacent pas de vrais liens explorables.

Documentation officielle

Il n’existe aucune documentation de Google ou de Bing consacrée spécifiquement aux « méga-menus ». Les consignes officielles portent sur l’explorabilité des liens, les textes d’ancrage et l’indexation orientée mobile, puis s’appliquent à cette interface. Voici les sources primaires pertinentes.

Google

• Bonnes pratiques concernant les liens SEO — l’exigence <a href> et la liste des formats déconseillés, comme l’absence de href, onclick ou les balises qui ne sont pas des ancres. C’est le document fondamental.
• Bonnes pratiques pour l’indexation orientée mobile — la parité du contenu entre mobile et ordinateur, ainsi que la précision selon laquelle les accordéons et onglets conviennent sur mobile si le contenu reste équivalent.
• Guide détaillé du fonctionnement de la recherche Google — le contexte général de découverte des URL : Google trouve la plupart des nouvelles pages grâce aux liens.

Bing / Microsoft

• Consignes Bing pour les webmasters — aucun passage propre aux méga-menus, mais la recommandation générale de maintenir les pages importantes à environ trois clics de l’accueil et le recours plus marqué aux sitemaps XML donnent le contexte utile. Puisque Bing s’appuie davantage sur les sitemaps, un méga-menu qui crée accidentellement des pages orphelines présente un risque comparativement plus élevé : il existe moins de chemins de découverte alternatifs.

Schema.org

• SiteNavigationElement — le type de schéma pour la navigation. Il constitue une amélioration sémantique à ajouter à de vrais liens, pas une correction d’explorabilité.

Accessibilité (WAI-ARIA / WCAG)

• Exemple WAI-ARIA de menu de navigation par affichage — un exemple fonctionnel de comportement utilisable au clavier pour cette interface ; ce n’est pas la seule implémentation conforme.
• WCAG 2.2 — Comprendre le critère de succès 2.1.1 : Clavier — l’exigence sous-jacente selon laquelle le déclencheur et le panneau du méga-menu doivent fonctionner sans souris.

Citations des sources

Déclarations publiques pertinentes pour construire un méga-menu explorable et bien structuré.

Google — l’exigence d’un lien explorable (bonnes pratiques concernant les liens SEO)

• “Google can only crawl your link if it’s an <a> HTML element (also known as anchor element) with an href attribute.” (traduction) « Google ne peut explorer votre lien que s’il s’agit d’un élément HTML d’ancrage doté d’un attribut href. » Accéder à la citation

John Mueller, Google — le contenu masqué ou placé dans des onglets est indexé comme le contenu visible

• “No. Specifically when it comes to content on mobile pages we do take into account anything that’s in the HTML. So if there’s something there that might be visible to users at some point we will include that… so that’s completely normal.” (traduction) « Non : pour le contenu des pages mobiles en particulier, nous tenons compte de tout ce qui se trouve dans le HTML. Si un élément peut devenir visible pour les utilisateurs, nous l’incluons… c’est donc parfaitement normal. » (Réponse à la question de savoir si le contenu masqué derrière des onglets ou des accordéons est dévalorisé avec l’indexation orientée mobile.) Lire l’article

John Mueller, Google — structure plate ou pyramidale, dans le contexte d’un méga-menu de 1 000 liens

• “If it’s very flat, then we think, oh, all of these are equally important, and we don’t really know which of these are connected to each other.” (traduction) « Si la structure est très plate, nous considérons que tous ces éléments ont la même importance et nous distinguons mal ceux qui sont liés entre eux. » Lire l’article
• “A pyramid structure helps us a lot more to understand the context of individual pages within the site.” (traduction) « Une structure pyramidale nous aide beaucoup plus à comprendre le contexte de chaque page du site. » / “I don’t think it would always have a negative effect.” (traduction) « Je ne pense pas que cela ait toujours un effet négatif. » (À propos du passage d’environ 1 000 liens plats de méga-menu à une structure plus profonde.) Lire l’article

John Mueller, Google — les données structurées ne remplacent pas de vrais liens internes

• “Even if in the structured data you also provide URLs, we don’t use those URLs in the same way as we would use normal internal links on a page.” (traduction) « Même si vous fournissez aussi des URL dans les données structurées, nous ne les utilisons pas comme des liens internes normaux sur une page. »

Faut-il utiliser un méga-menu — et le vôtre est-il sûr ?

Cet arbre couvre les deux questions importantes : ce site doit-il avoir un méga-menu et, si oui, Google peut-il explorer sa mise en œuvre ? Pour l’analyse structurelle complète des architectures plates ou profondes, consultez les articles de ce groupe consacrés à l’architecture et à la structure du site.

Liste de contrôle SEO d’un méga-menu

Procédez de haut en bas : explorabilité, structure, puis mobile.

• Chaque lien du panneau est un véritable <a href> — pas un onclick, un attribut routerLink ou de routeur sans href, ni une autre balise stylisée comme un lien.
• Les liens apparaissent dans le code source de la page, pas seulement dans l’inspecteur ou le DOM actif : c’est la différence entre rendu serveur et JS uniquement.
• Le HTML du panneau figure dans la page initiale et est masqué par CSS — il n’est pas chargé par une API au survol ou au clic.
• L’outil URL Inspection (Inspection de l’URL) de GSC confirme la présence des liens dans le HTML exploré ou rendu.
• JavaScript améliore, il ne crée pas — JS gère l’animation et l’interactivité ; les liens existent sans lui.
• Aucune destination orpheline — aucune page importante ne dépend du méga-menu comme seul lien interne ; contrôlez les liens contextuels dans le contenu.
• Les liens sont regroupés par catégorie sous des titres de colonnes qui reflètent la hiérarchie du site, plutôt que dans un mur indifférencié.
• Les colonnes sont faciles à parcourir — quelques éléments par groupe, pas une liste alphabétique exhaustive.
• Le texte d’ancrage est descriptif et propre à chaque destination — pas des dizaines de « Acheter maintenant » génériques.
• Le menu est sélectif, pas exhaustif — il sert les grands parcours de découverte, tandis que les pages prioritaires reçoivent aussi des liens contextuels.
• Le menu hamburger ou accordéon mobile contient les mêmes liens que le méga-menu pour ordinateur.
• Les liens mobiles sont aussi de véritables <a href> — répétez le contrôle du code source et de l’outil URL Inspection sur la navigation mobile.
• Les données structurées (SiteNavigationElement), si elles sont utilisées, s’ajoutent à de vrais liens — elles ne les remplacent jamais.
• Revérifiez après chaque mise à niveau frontale — les changements de framework transforment parfois discrètement de vrais liens en gestionnaires de clic.

Méga-menu et SEO — aide-mémoire

Explorable ou non

Les deux défaillances souvent confondues

• Masqué par CSS — liens présents dans le DOM, panneau masqué jusqu’au survol — → indexé normalement.
• Chargé lors de l’interaction — les liens n’existent pas avant le déclenchement d’un événement — → risque de ne jamais être exploré. C’est un défaut d’explorabilité, pas une dévalorisation du contenu masqué.

Mythe et réalité

Vérification rapide

• Code source de la page — pas l’inspecteur — → recherchez un lien du menu → s’agit-il d’un <a href> ?
• Outil URL Inspection (Inspection de l’URL) de GSC → le HTML exploré ou rendu contient-il les liens ?
• Mobile : répétez les deux contrôles sur le menu hamburger ou accordéon.

Exemple de bon et de mauvais balisage de méga-menu

Mauvais : un panneau uniquement en JavaScript

Google ne peut pas suivre de façon fiable des liens qui n’existent qu’après l’exécution de JavaScript, comme ceux-ci :

<nav class="mega">
  <button class="trigger" onclick="openFlyout('shoes')">Shoes</button>
  <div class="flyout" id="shoes-flyout" hidden>
    <!-- injected by JS after the click; empty in the server HTML -->
    <span class="menu-link" data-url="/shoes/mens/">Men's shoes</span>
    <span class="menu-link" data-url="/shoes/womens/">Women's shoes</span>
    <a routerLink="/shoes/kids/">Kids' shoes</a>          <!-- no href -->
    <a onclick="go('/shoes/sale/')">Sale</a>              <!-- onclick, no href -->
  </div>
</nav>

Toutes ces destinations sont invisibles pour un robot : les « liens » <span> ne sont pas des ancres, routerLink n’a pas de href, et l’ancre onclick ne fournit aucune URL à suivre. Si ces pages n’ont aucun autre lien interne, elles sont orphelines.

Bon : des liens rendus par le serveur et améliorés progressivement

Les liens sont de véritables éléments <a href> présents dans le HTML du serveur ; JavaScript ajoute uniquement le comportement au survol :

<nav class="mega" aria-label="Primary">
  <ul>
    <li>
      <a href="/shoes/">Shoes</a>
      <div class="flyout">          <!-- CSS: display:none until hover/focus -->
        <div class="col">
          <h3>Men's</h3>
          <ul>
            <li><a href="/shoes/mens/running/">Men's running shoes</a></li>
            <li><a href="/shoes/mens/boots/">Men's boots</a></li>
          </ul>
        </div>
        <div class="col">
          <h3>Women's</h3>
          <ul>
            <li><a href="/shoes/womens/running/">Women's running shoes</a></li>
            <li><a href="/shoes/womens/boots/">Women's boots</a></li>
          </ul>
        </div>
      </div>
    </li>
  </ul>
</nav>

/* Hidden until hover — links are still in the DOM, so they're crawled normally */
.flyout { display: none; }
.mega li:hover > .flyout,
.mega li:focus-within > .flyout { display: block; }

Tout est explorable dans le HTML brut, et le masquage du panneau avec CSS ne change rien : le contenu masqué par CSS est indexé comme le contenu visible.

Encore mieux : un regroupement, pas un mur

Les deux balisages ci-dessous contiennent le même nombre de liens, mais transmettent des informations très différentes à Google. À gauche, un ensemble sans organisation ; à droite, les mêmes liens sous des titres qui reflètent la hiérarchie.

<!-- Structurally flat: an ungrouped wall -->
<div class="flyout">
  <a href="/shoes/mens/running/">Men's running</a>
  <a href="/shoes/womens/running/">Women's running</a>
  <a href="/shoes/kids/">Kids'</a>
  <a href="/shoes/mens/boots/">Men's boots</a>
  <a href="/shoes/sale/">Sale</a>
  <a href="/shoes/womens/boots/">Women's boots</a>
  <!-- ...140 more, no structure... -->
</div>

<!-- Grouped: the hierarchy is legible -->
<div class="flyout">
  <div class="col"><h3>Men's</h3>
    <ul><li><a href="/shoes/mens/running/">Running</a></li>
        <li><a href="/shoes/mens/boots/">Boots</a></li></ul></div>
  <div class="col"><h3>Women's</h3>
    <ul><li><a href="/shoes/womens/running/">Running</a></li>
        <li><a href="/shoes/womens/boots/">Boots</a></li></ul></div>
  <div class="col"><h3>Kids &amp; Sale</h3>
    <ul><li><a href="/shoes/kids/">Kids' shoes</a></li>
        <li><a href="/shoes/sale/">Sale</a></li></ul></div>
</div>

Les deux versions sont explorables. Seule la version regroupée préserve les relations entre catégories qui permettent à Google de comprendre quelles pages vont ensemble.

Anti-modèles des méga-menus

Voici les défaillances récurrentes des méga-menus et la solution à leur apporter.

1. Des gestionnaires de clic à la place d’ancres. Le cas classique : onclick, un attribut routerLink ou de routeur sans href, ou un <span> stylisé comme un lien. L’utilisateur ne voit aucun problème, mais un robot ne peut pas le suivre. → Utilisez de vrais liens <a href>, améliorés par JS pour le comportement.

2. Le HTML du panneau est chargé au survol. Le contenu du panneau n’est récupéré par une API qu’après un survol ou un clic ; les liens n’existent donc pas avant l’action de l’utilisateur. → Placez-les dans le HTML initial et masquez le panneau avec CSS.

3. Faire confiance au rendu plutôt qu’au code source. Contrôler le menu dans l’inspecteur — le DOM actif — masque précisément le défaut JS recherché. → Utilisez le code source de la page et l’outil URL Inspection de GSC.

4. Le mur de liens indifférencié. Des centaines de liens de même niveau dans un panneau sans regroupement. Aucune règle sur le nombre n’est enfreinte, mais le signal de regroupement thématique est aplati. → Regroupez par catégorie sous des titres qui reflètent la hiérarchie et restez sélectif.

5. Des textes d’ancrage génériques et répétés. Répéter « Acheter maintenant », « Tout voir » ou « Cliquez ici » sur des dizaines de destinations n’indique rien aux moteurs de recherche. → Employez un texte descriptif propre à chaque destination.

6. Un menu mobile tronqué. Supprimer des liens du menu hamburger ou accordéon pour épurer l’interface rompt la parité mobile et peut rendre orphelines les pages dont le seul lien se trouvait dans le méga-menu pour ordinateur. → Conservez les mêmes liens et vérifiez qu’ils sont aussi de vraies ancres sur mobile.

7. Traiter le schéma comme une correction d’explorabilité. Ajouter SiteNavigationElement à des liens uniquement en JS ne les rend pas explorables. → Le schéma est une couche sémantique au-dessus de liens déjà explorables, jamais un remplacement.

8. Croire que le contenu masqué jusqu’au survol est dévalorisé. L’ancien mythe du « contenu masqué dévalorisé » conduit à des solutions inutilement complexes. Les liens présents dans le DOM et masqués par CSS sont indexés normalement. → Ne concevez pas un contournement pour un mythe ; vérifiez simplement que les liens figurent bien dans le HTML.

Problèmes de méga-menu à diagnostiquer

Les liens semblent fonctionner, mais un robot ne les découvre pas

Symptôme : un clic sur une entrée de menu ouvre la destination dans le navigateur, mais l’URL est absente d’une exploration lancée depuis l’accueil. Cause probable : l’entrée est un div, un button ou un gestionnaire JavaScript, plutôt qu’une ancre dotée d’un href. Correction : rendez un véritable <a href="/destination/"> dans le HTML, relancez l’exploration depuis l’accueil et vérifiez que la destination apparaît comme lien interne sortant.

Les liens sont explorables sur ordinateur, mais disparaissent sur mobile

Symptôme : des catégories importantes figurent dans le menu pour ordinateur, mais pas dans le DOM mobile. Cause probable : le menu mobile emploie une source de données distincte et raccourcie. Correction : donnez à l’accordéon mobile les mêmes destinations importantes et vérifiez que les ancres existent avant toute pression.

Le panneau s’ouvre au survol, mais pas au clavier

Symptôme : les utilisateurs de souris atteignent le panneau, mais les touches Tab et Entrée ne l’affichent pas. Cause probable : l’interaction dépend uniquement du survol. Correction : utilisez un bouton comme déclencheur, gérez le clavier et maintenez un état aria-expanded exact ; conservez les destinations sous forme d’ancres normales.

Le cadre Atteindre, Rendre, Restreindre

Appliquez trois contrôles à chaque méga-menu :

1. Atteindre : un utilisateur et un robot peuvent-ils atteindre chaque destination importante par une véritable ancre, sur ordinateur comme sur mobile ?
2. Rendre : ces ancres figurent-elles dans le HTML livré ou rendu sans nécessiter de survol, de clic ou de réponse API ?
3. Restreindre : le menu se limite-t-il aux destinations qui méritent des liens sur tout le site, regroupées sous des titres utiles, plutôt que de devenir un plan du site dans une liste déroulante ?

Le menu échoue dès qu’un de ces trois axes est rompu. Atteindre protège la découverte, Rendre protège l’implémentation et Restreindre protège la hiérarchie et l’utilisabilité.

Inspecter les liens d’un méga-menu dans le navigateur

Exécutez ce code dans la console des outils de développement de Chrome tandis que le menu est fermé. Il recense les ancres situées dans des conteneurs de navigation courants et signale celles qui n’ont pas de href :

const links = [...document.querySelectorAll('header nav a, [role="navigation"] a')];
console.table(links.map(a => ({ text: a.textContent.trim(), href: a.getAttribute('href'), crawlable: a.hasAttribute('href') })));

Exécutez le même extrait avec une largeur d’affichage pour ordinateur puis pour mobile. Toute destination présente dans un seul des deux résultats doit être examinée.

Extraire les destinations de navigation lors d’une exploration

Utilisez cette expression XPath dans la fonction d’extraction personnalisée d’un robot pour collecter les URL du menu :

//header//nav//a[@href]/@href | //*[@role='navigation']//a[@href]/@href

Cette union couvre les éléments sémantiques nav ainsi que les régions de navigation identifiées par un rôle ARIA. Comparez l’ensemble extrait à l’inventaire de navigation approuvé, sans supposer que chaque cible cliquable est un lien.

Ressources utiles

Mes articles connexes

• Guide pratique des liens internes pour le SEO — le guide Ahrefs complet sur la transmission du PageRank par les liens internes, l’absence de limite fixe au nombre de liens et les textes d’ancrage : les ingrédients mêmes d’un méga-menu.
• Guide du débutant en SEO technique — la place de la navigation et de l’explorabilité dans l’ensemble du SEO technique.
• Problèmes et bonnes pratiques du SEO JavaScript — les problèmes de rendu et de JavaScript à l’origine de la plupart des panneaux de méga-menu défaillants.

Sources officielles

• Les bonnes pratiques de Google concernant les liens SEO — la référence canonique pour l’explorabilité d’un lien.
• Les bonnes pratiques de Google pour l’indexation orientée mobile — l’exigence de parité que le menu mobile doit respecter.

Dans le secteur

• Mueller réfute le mythe du contenu masqué dans les onglets (Search Engine Journal) — la déclaration directe de Mueller selon laquelle le contenu masqué jusqu’à l’interaction est indexé comme le contenu visible.
• Google recommande une navigation pyramidale pour les grands sites (Search Engine Roundtable) — la réponse complète de Mueller sur un méga-menu de 1 000 liens, à l’origine des conseils de budget de liens présentés ici.
• Le contenu des onglets est-il un facteur de classement Google ? (Search Engine Journal) — l’histoire du débat sur le contenu masqué et les raisons pour lesquelles l’ancienne thèse de la « dévalorisation » est obsolète.
• Google : le contenu des onglets ou zones à développer est dévalorisé (Search Engine Roundtable) — l’ancienne recommandation désormais remplacée, utile pour comprendre l’origine du mythe.
• Méga-menus et SEO (MagsTags) — une analyse centrée sur la théorie de la valeur des liens, avec un exemple de diffusion du PageRank par un grand menu ; contexte utile, mais non sourcé par Google.
• r/TechSEO — la communauté qui aide à diagnostiquer pages orphelines et défauts d’explorabilité, là où la plupart des problèmes de méga-menu apparaissent concrètement.

Testez vos connaissances : SEO des méga-menus

Cinq questions rapides sur la construction d’un méga-menu explorable et bien structuré. Choisissez une réponse pour chacune, puis vérifiez votre résultat.

Journal des modifications