Les liens en mouseover sont-ils vraiment crawlables par Google ?

Quelle est la différence entre un lien visible au chargement et un lien généré au survol ?

Un lien visible au chargement existe dans le HTML dès que le navigateur reçoit la page. Il peut être masqué en CSS (opacity: 0, display: none, position absolute hors écran), mais son href et son ancre sont déjà dans le DOM. Googlebot le détecte sans problème.

Un lien généré au survol, en revanche, n'existe pas avant l'événement mouseover ou mouseenter. Un script JavaScript intercepte le survol et injecte alors le dans le DOM. Googlebot, qui ne déclenche pas d'événements souris, ne voit jamais ce lien apparaître.

Pourquoi cette distinction importe-t-elle en crawl ?

Le crawl de Google repose sur l'analyse du DOM final rendu après exécution du JavaScript initial. Si un lien nécessite une interaction utilisateur pour exister, il reste hors de portée du crawler.

Concrètement, un mega-menu en CSS pur (sous-menus cachés par défaut, affichés via :hover) ne pose aucun problème. Tous les liens sont dans le HTML de départ. Mais un menu qui charge les sous-liens via fetch() ou XHR au survol prive Google de ces URL.

Quels patterns techniques tombent dans le piège ?

Les frameworks modernes optimisent souvent le Time to Interactive en retardant le rendu des sous-menus. React, Vue ou Angular peuvent ne monter qu'au hover les composants de navigation secondaire. Si le SSR ou l'hydratation ne les injecte pas dès le départ, Google rate ces liens.

Autre cas fréquent : les mega-menus avec lazy-loading des catégories. Au survol de "Produits", une requête API charge les 50 sous-catégories. L'UX est fluide, mais le crawl s'arrête à la racine. Le maillage interne s'effondre, les pages profondes ne reçoivent plus de jus.

• Liens présents au chargement (masqués en CSS) : crawlables sans restriction
• Liens injectés au survol (JavaScript event-driven) : invisibles pour Googlebot
• Impact crawl budget : les pages orphelines ne sont découvertes que via sitemap ou backlinks externes
• Mega-menus CSS purs : solution la plus safe pour le SEO, tous les hrefs sont scrapables
• Hydratation SSR incomplète : risque majeur avec les SPA modernes si le serveur ne rend pas les sous-menus

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

Oui, mais avec une nuance importante : Google exécute désormais JavaScript de manière avancée, et la frontière entre "visible au chargement" et "généré au survol" dépend du timing. Si un script s'exécute dans les 5 premières secondes et injecte les liens sans attendre d'interaction, le crawl peut les capter.

Le vrai problème, c'est le délai d'attente. Googlebot ne patiente pas indéfiniment pour qu'un onmouseover déclenche un fetch. Les tests avec Search Console montrent que les liens apparaissant après 3-4 secondes [À vérifier] sont souvent ratés, surtout sur les sites à crawl budget serré.

Quels risques concrets pour le maillage interne ?

Si vos catégories principales sont accessibles via un menu en mouseover event-driven, vous fragmentez votre architecture. Les pages de niveau 2 et 3 deviennent orphelines du point de vue du crawl. Google ne les découvre que via le sitemap XML ou des liens externes, ce qui dilue le PageRank interne.

Résultat : des pages stratégiques avec un bon contenu restent mal indexées, non pas par manque de qualité, mais par défaut d'accessibilité structurelle. Le problème empire sur mobile, où Googlebot mobile-first ne déclenche aucun événement hover.

Dans quels cas ce pattern reste-t-il acceptable ?

Les liens secondaires (filtres avancés, options de tri, navigation utilitaire) peuvent être chargés au survol sans dommage SEO majeur. Si ces URL sont par ailleurs linkées depuis des pages de hub ou le footer, le crawl alternatif compense.

En revanche, pour la navigation primaire (rubriques majeures, catégories produits, sections édito), tout lien manquant au chargement constitue une faille architecturale. Le risque dépasse le crawl : cela affecte aussi l'expérience utilisateur sur connexions lentes, où le JavaScript tarde à s'exécuter.

Comment vérifier si mes menus sont crawlables ?

Ouvre l'inspecteur de ton navigateur, coupe le JavaScript, et recharge la page. Si les liens de navigation disparaissent totalement, c'est un signal d'alarme. Ils dépendent d'une exécution JS qui peut échouer ou être ignorée par Googlebot.

Ensuite, utilise l'outil d'inspection d'URL de Search Console. Compare le HTML brut envoyé par le serveur avec le "code source rendu". Si les sous-menus n'apparaissent que dans le rendu et nécessitent un hover pour se peupler, c'est problématique.

Quelle implémentation technique garantit le crawl ?

La solution la plus robuste reste le CSS pur : tous les liens existent dans le HTML, les sous-menus sont cachés par défaut (display: none ou opacity: 0), et le :hover les affiche. Zero JavaScript requis, crawlabilité maximale.

Si tu utilises React ou Vue, assure-toi que le SSR (Server-Side Rendering) injecte les menus complets dans le HTML initial. Évite les composants qui ne se montent qu'au mouseenter. L'hydratation doit rendre les liens cliquables, pas les créer de toutes pièces.

Quelles erreurs fréquentes doivent être corrigées en priorité ?

Les mega-menus avec lazy-loading API sont le piège numéro un. Si au survol d'une catégorie, un appel fetch() charge les sous-liens, Google ne les verra jamais. Précharge ces données côté serveur ou injecte-les en JSON-LD dans le DOM initial.

Autre erreur classique : les menus mobiles basés sur des toggles JavaScript sans fallback HTML. Sur desktop, le hover fonctionne, mais Googlebot mobile-first ne déclenche aucun événement tactile. Résultat : indexation partielle.

• Désactiver JavaScript dans Chrome DevTools et vérifier la présence des liens de navigation
• Crawler le site avec Screaming Frog en mode rendu JavaScript et comparer avec un crawl HTML brut
• Utiliser l'outil d'inspection d'URL Search Console pour auditer le DOM rendu vs. le HTML source
• Remplacer les événements mouseover par du CSS pur (:hover) pour les menus critiques
• Garantir que le SSR injecte tous les liens de navigation dès le HTML initial, sans attendre l'hydratation
• Tester la navigation sur un appareil mobile réel pour détecter les ruptures de crawl mobile-first