Pourquoi Google ignore-t-il les liens cachés derrière vos menus déroulants ?

Qu'est-ce que le HTML rendu et pourquoi Google s'y limite-t-il ?

Le HTML rendu correspond au DOM final après exécution du JavaScript, tel que visible dans les outils de test comme Google Search Console ou l'inspecteur de rendu mobile. Google ne crawle pas le code source brut, mais bien ce qui est effectivement affiché dans le navigateur après que toutes les manipulations JavaScript ont eu lieu.

La nuance importante : Google distingue ce qui est présent dans le DOM de ce qui nécessite une action pour apparaître. Un menu déroulant qui charge des liens uniquement au survol ou au clic n'est jamais considéré comme crawlable, même si le JavaScript fonctionne parfaitement côté client. Le bot ne simule aucune interaction utilisateur — ni clic, ni hover, ni scroll infini déclenché par événement.

Pourquoi cette limitation technique persiste-t-elle encore ?

Soyons honnêtes : Google pourrait techniquement simuler des interactions comme le fait un outil de test automatisé type Selenium. Mais le crawl budget et la charge serveur imposent des contraintes économiques strictes. Crawler des milliards de pages en simulant des clics sur chaque élément interactif multiplierait les ressources nécessaires par un facteur prohibitif.

En pratique, cela signifie que toute navigation lazy-loaded conditionnée à un événement utilisateur (onclick, onmouseover, scroll avec intersection observer déclenché manuellement) est un point mort pour le crawler. Google part du principe que si un lien est important, il doit être accessible sans friction dans le HTML rendu initial.

Que se passe-t-il avec les liens chargés uniquement en JSON ?

Un cas fréquent concerne les applications JavaScript modernes (React, Vue, Angular) où les routes sont gérées côté client et les liens construits dynamiquement depuis une API JSON. Si votre composant de navigation fetch un endpoint /api/menu.json et construit des <a href> en JavaScript, ces liens ne seront crawlés que s'ils finissent effectivement dans le DOM rendu.

La confusion vient souvent de développeurs qui voient les liens apparaître dans leur navigateur et supposent que Google les voit aussi. Mais si le JSON est chargé après un événement utilisateur ou si le framework ne fait pas de rendu serveur (SSR) ou de pré-rendu statique, Google ne voit qu'une page vide ou un squelette HTML sans liens exploitables.

• Seul le HTML rendu compte : tout lien absent du DOM après exécution initiale du JavaScript est invisible pour Google
• Les interactions utilisateur ne sont jamais simulées : hover, clic, scroll conditionnel sont autant de barrières infranchissables pour le bot
• Le JSON seul ne suffit pas : les liens doivent être injectés dans le DOM rendu, idéalement via SSR ou hydratation statique
• Utilise les outils de test Google pour vérifier ce que le bot voit réellement, pas ce que ton navigateur affiche après interaction
• Le crawl budget est une ressource limitée : Google ne peut pas se permettre de simuler chaque scénario d'interaction sur des milliards de pages

Cette déclaration est-elle cohérente avec les observations terrain ?

Oui, et c'est même l'un des rares points où Google est parfaitement transparent. Les tests pratiqués depuis des années avec des menus déroulants conditionnels confirment que les pages cachées derrière un hover ou un clic ne sont jamais indexées, sauf si elles bénéficient de liens directs ailleurs sur le site. Les audits de crawl sur des sites e-commerce lourds en JavaScript montrent systématiquement des taux de découverte effondrés pour les catégories enfouies dans des mega-menus à déclenchement manuel.

La cohérence s'arrête là où Google ne précise pas ce qu'il entend exactement par "HTML rendu". Certains frameworks comme Next.js ou Nuxt génèrent du SSR mais avec des hydrations partielles qui peuvent laisser des liens non crawlables si mal configurées. [À vérifier] : Google crawle-t-il les liens injectés par hydratation client-side après le premier paint, ou seulement ceux présents dans le HTML initial envoyé par le serveur ? La documentation officielle reste floue sur ce point.

Quelles erreurs d'implémentation passent sous le radar ?

Le piège classique : un site qui affiche correctement ses liens dans Chrome en mode inspection mais qui les charge en réalité via un event listener DOMContentLoaded ou window.onload. Si ce chargement dépend d'une ressource tierce (CDN lent, script bloquant), le bot peut timeout avant que les liens apparaissent dans le DOM. Résultat : crawl incomplet, et personne ne comprend pourquoi certaines sections du site ne sont jamais indexées.

Autre erreur fréquente : les menus hamburger mobiles qui nécessitent un clic pour déployer la navigation. Sur desktop, les liens sont dans le DOM ; sur mobile, ils sont chargés à la demande. Si Google crawle en mode mobile-first avec un viewport smartphone, ces liens sont invisibles. Beaucoup de sites perdent des pans entiers de leur arborescence à cause de cette asymétrie desktop/mobile non testée.

Dans quels cas cette règle ne s'applique-t-elle pas ?

Elle ne s'applique pas si les liens sont découverts par d'autres chemins de crawl : sitemap XML, liens externes entrants, navigation breadcrumb présente ailleurs, liens internes dans le contenu éditorial. Un lien absent d'un menu déroulant mais présent dans un article de blog sera parfaitement crawlé. Le problème survient uniquement quand le menu est la seule porte d'entrée vers certaines pages.

Et c'est là que ça coince : sur des sites d'envergure avec des milliers de produits ou de catégories, le menu est souvent la navigation principale. Si ce menu est inaccessible au bot, le crawl se limite aux quelques pages linkées dans le footer ou dans des contenus éditoriaux sporadiques. Le reste ? Invisible. [À vérifier] : Google favorise-t-il activement les sites avec navigation statique dans son classement, ou se contente-t-il de pénaliser passivement ceux qui rendent le crawl difficile ?

Que faut-il faire concrètement pour garantir la crawlabilité des liens ?

Première action : audit du HTML rendu via Google Search Console, onglet "Inspection d'URL". Compare le HTML source brut avec le HTML rendu après JavaScript. Si des liens apparaissent uniquement dans le rendu mais nécessitent une interaction pour se charger, ils sont perdus pour le bot. Utilise aussi des outils comme Screaming Frog en mode JavaScript activé pour simuler le rendu et identifier les écarts.

Ensuite, refactorise ta navigation pour qu'elle soit statique dans le DOM initial. Pas besoin de sacrifier l'UX : un mega-menu peut être présent dans le HTML rendu mais caché visuellement en CSS (display:none ou visibility:hidden), puis révélé au hover via CSS pur ou JavaScript. L'essentiel est que les balises <a href> soient déjà dans le DOM au chargement, pas injectées à la demande.

Quelles erreurs éviter absolument dans l'implémentation ?

Ne confonds pas rendu côté client et rendu serveur. Un framework comme React en mode SPA (Single Page Application) pur génère souvent un HTML vide avec un <div id="root"></div> et construit tout le contenu en JavaScript client. Pour Google, c'est une page blanche. La solution : passer en SSR (Server-Side Rendering) avec Next.js, ou utiliser du pré-rendu statique (Static Site Generation) pour les pages clés.

Évite aussi les liens conditionnels basés sur des cookies ou la géolocalisation détectée côté client. Si ton menu affiche des liens différents selon que l'utilisateur est en France ou en Belgique, et que cette détection se fait en JavaScript après chargement, Google (qui crawle depuis des IPs américaines la plupart du temps) ne verra qu'une version partielle de ton menu. Privilégie une navigation universelle avec des variantes linguistiques ou régionales accessibles via des liens statiques.

Comment vérifier que mon site respecte ces contraintes ?

Teste systématiquement avec JavaScript désactivé dans ton navigateur. Si tes liens de navigation disparaissent, c'est qu'ils ne sont pas dans le HTML initial et que Google ne les verra probablement pas non plus. Complète avec un crawl Screaming Frog en mode "JavaScript rendering" et compare le nombre de liens découverts versus un crawl classique sans JS : tout écart significatif indique un problème de crawlabilité.

Utilise aussi le rapport de couverture Search Console pour identifier les pages découvertes mais non indexées. Si des sections entières de ton arborescence n'apparaissent jamais dans ce rapport, c'est souvent lié à une navigation conditionnelle non crawlable. Croise avec les logs serveur pour confirmer que Googlebot ne requête même pas ces URLs : absence totale de crawl = problème de découverte, pas d'indexation.

• Audit du HTML rendu via Search Console et comparaison avec le source brut
• Refonte de la navigation pour injecter tous les liens critiques dans le DOM initial, sans condition d'interaction
• Passage en SSR ou pré-rendu statique pour les frameworks JavaScript modernes
• Test JavaScript désactivé : la navigation doit rester fonctionnelle (ou au minimum les liens doivent être présents)
• Crawl Screaming Frog avec/sans JS pour mesurer l'écart de découverte de liens
• Surveillance des logs serveur pour identifier les pages jamais crawlées malgré leur présence dans le sitemap