Liens JavaScript : lesquels Google suit et lesquels il ignore ?

Un élément sur lequel on clique et qui change la page ressemble à un lien pour un visiteur, sans en être un pour un robot. Cette distinction, invisible à l'usage, détermine si des pans entiers d'un site sont découverts ou restent invisibles. Google exécute désormais le JavaScript avant d'analyser une page, ce qui a beaucoup réduit le problème sans le supprimer : il reste des constructions qu'aucun moteur ne suit, pour des raisons qui n'ont rien d'arbitraire. Savoir lesquelles, et vérifier ce que voit réellement un robot sur son propre site, évite de découvrir six mois plus tard qu'une section entière n'a jamais été explorée.

Ce qu'un moteur suit réellement

La règle tient en une phrase et ses exceptions occupent le reste de l'article : un moteur suit une balise de lien disposant d'un attribut d'adresse valide. Ce point conditionne directement la découverte des contenus, sujet que nous traitons dans notre article sur l'indexation Google et ses mécanismes.

La balise de lien avec adresse

Une balise d'ancrage portant un attribut d'adresse pointant vers une ressource du site est suivie sans condition, qu'elle ait été écrite par le serveur ou ajoutée par un script après le chargement. C'est la seule construction dont on puisse être certain. Toute autre façon de rendre un élément cliquable relève du pari, et la question devient alors de savoir quel moteur, dans quelle version de son rendu, traitera le cas. Sur un site professionnel, ce pari n'a aucune raison d'être pris. La contrainte est si faible, une balise correcte au lieu d'un élément quelconque, qu'aucun argument technique ne la justifie sérieusement. Les équipes qui s'en écartent le font par habitude plutôt que par choix raisonné.

Le rendu du JavaScript

Le moteur charge la page, exécute les scripts et analyse le résultat obtenu, en deux temps : une première analyse du code source, puis un rendu complet placé dans une file d'attente. Ce second passage peut intervenir quelques secondes ou plusieurs jours après le premier, selon les ressources disponibles et l'importance accordée au site. Un lien qui n'existe qu'après exécution est donc découvert plus tard, ce qui suffit à ralentir sensiblement l'indexation sur un site publiant régulièrement. Sur un média quotidien, ce décalage se paie directement en visibilité sur les sujets d'actualité. Sur un site institutionnel mis à jour trimestriellement, il passe inaperçu, ce qui explique que le même défaut soit tantôt critique tantôt anecdotique.

Ce qui n'est jamais suivi

Un élément portant un gestionnaire d'événement qui appelle une fonction de navigation, sans balise de lien ni attribut d'adresse, n'est pas suivi. Un bouton déclenchant un changement d'affichage sans modifier l'adresse ne l'est pas davantage. Une adresse construite au moment du clic, à partir de valeurs calculées, échappe entièrement à l'analyse puisqu'elle n'existe nulle part dans le document. Ces trois constructions sont fréquentes et elles rendent invisibles les contenus qu'elles desservent. Elles ont en commun de ne laisser aucune trace exploitable dans le document, ce qui les rend indétectables par une simple lecture du code rendu. Seule une revue du comportement au clic permet de les identifier.

Les adresses sans chemin réel

Un lien pointant vers un identifiant interne, une adresse vide ou un protocole JavaScript ne mène nulle part du point de vue du robot. Ces constructions servent souvent à obtenir l'apparence d'un lien tout en confiant le comportement à un script, pratique qui a longtemps été employée pour des raisons de style. Elle produit exactement le résultat inverse de celui recherché : un élément qui ressemble à un lien, se comporte comme un lien pour le visiteur, et n'en est pas un pour le moteur. Le style pouvant aujourd'hui s'appliquer à n'importe quel élément, y compris une balise de lien correctement formée, la raison historique de cette pratique a entièrement disparu. Elle ne survit que dans des composants anciens que personne n'a repris.

Le cas des fragments

Les adresses comportant un fragment, après le signe dièse, désignent une position dans la page courante et non une ressource distincte. Un moteur les traite comme la même page, ce qui est correct. Le problème apparaît lorsqu'une application emploie ces fragments pour naviguer entre des vues différentes, construction ancienne qui rend l'ensemble du site invisible puisque tout se trouve à la même adresse. Cette technique appartient au passé et se rencontre encore sur des applications non refondues. Le remplacement par une gestion de l'historique du navigateur, qui produit de véritables adresses, est aujourd'hui standard dans tous les cadres applicatifs. La migration demande du travail mais elle ne présente aucune difficulté conceptuelle.

Ce que le budget de rendu change

L'exécution du JavaScript coûte des ressources considérables au moteur, bien plus que la simple lecture d'un document. Sur un site à faible autorité ou très volumineux, ce coût conduit à un rendu moins fréquent et parfois partiel. Un site dont l'intégralité de la navigation dépend d'une exécution réussie est donc structurellement désavantagé, et cette désavantage croît avec la taille du site, exactement à l'inverse de ce dont on aurait besoin. Un catalogue de cinquante mille références construit intégralement côté navigateur cumule ainsi le volume et la dépendance au rendu, combinaison qui se traduit par une indexation partielle durable. Le diagnostic est alors simple à poser et long à corriger.

Les constructions à risque

Plusieurs pratiques courantes produisent des liens que les moteurs ne voient pas, et elles se rencontrent sur la majorité des sites récents.

La pagination par bouton

Un bouton chargeant les éléments suivants sans modifier l'adresse rend inaccessible tout ce qui se trouve au delà de la première page. Sur un catalogue, cela signifie que seuls les premiers produits sont découverts. C'est le cas le plus fréquent et le plus coûteux, et il se corrige en doublant le bouton d'un lien réel vers la page suivante, solution qui préserve l'expérience tout en rendant le contenu explorable. Le lien peut rester discret visuellement, il suffit qu'il existe dans le document avec une adresse valide. Cette correction se déploie en une intervention et produit ses effets dès l'exploration suivante.

Le défilement infini

Le chargement automatique au défilement pose exactement le même problème, aggravé par le fait qu'aucun élément cliquable n'existe. Un robot ne fait pas défiler la page et ne verra donc jamais que le premier lot. La correction consiste à conserver une pagination classique en parallèle, accessible depuis le pied de page ou depuis un plan dédié, ce qui rejoint la question de l'accessibilité des contenus profonds traitée dans notre article sur la manière d'analyser la profondeur de clic réelle d'un site.

Les menus construits au clic

Un menu dont le contenu n'est ajouté au document qu'au moment où l'utilisateur l'ouvre n'existe pas pour un robot qui ne clique nulle part. Cette construction, adoptée pour des raisons de performance, rend invisible l'ensemble de la navigation principale. Le contenu du menu doit donc être présent dans le document, éventuellement masqué par une règle de style, ce qui ne pose aucun problème dès lors que le masquage n'est pas employé pour dissimuler du texte. Un menu replié dont le balisage est présent dès le chargement est une pratique parfaitement admise et largement répandue. Le gain de performance espéré par le chargement différé se révèle d'ailleurs souvent négligeable au regard du volume concerné.

Les filtres qui ne changent pas l'adresse

Une navigation à facettes modifiant l'affichage sans modifier l'adresse rend impossible tout partage de lien et empêche toute exploration. Cette construction est parfois délibérée, pour éviter l'explosion combinatoire, et elle constitue alors une décision cohérente. Elle devient un problème lorsque certaines combinaisons méritaient d'être explorables, sujet développé dans notre article sur les combinaisons de facettes à laisser explorer.

Les onglets qui chargent à la demande

Un contenu réparti en onglets, chacun chargé au clic, laisse le moteur ne voir que le premier. Si les autres onglets contiennent des informations qui participent au référencement de la page, description détaillée, caractéristiques, avis, cette information est perdue. La solution consiste à charger tous les contenus dans le document et à n'en masquer que l'affichage, ce qui coûte quelques kilooctets et règle définitivement la question. Sur une fiche produit, la différence de poids se mesure en dizaines de kilooctets, quantité sans effet mesurable sur le temps d'affichage. L'arbitrage penche donc franchement du côté de la présence dans le document.

Les liens dans les composants clients

Un composant écrit dans un cadre applicatif moderne produit ses liens correctement lorsqu'il emploie le composant de navigation fourni, qui génère de vraies balises avec adresse. Le problème apparaît lorsqu'un développeur intercepte le clic sur un élément quelconque pour déclencher une navigation programmatique. Cette pratique, plus rapide à écrire, casse l'exploration et l'ouverture dans un nouvel onglet, deux fonctions que les utilisateurs emploient constamment. Une revue de code attentive repère facilement ces interceptions, qui se signalent par la présence d'un gestionnaire de clic sur un élément non interactif. Inscrire ce point dans la liste de contrôle des relectures suffit généralement à les faire disparaître.

Vérifier ce que voit un robot

Toutes ces questions se tranchent par l'observation plutôt que par le raisonnement, et les outils nécessaires sont gratuits.

Lire le code source

L'affichage du code source montre le document tel que le serveur l'a envoyé, avant toute exécution. Chercher une adresse connue d'une page profonde dans ce code répond immédiatement à la question : si elle s'y trouve, le lien est visible dès la première analyse. Ce contrôle prend dix secondes et il est le plus direct de tous, à condition de ne pas le confondre avec l'inspection du document, qui montre l'état après exécution. Cette confusion est la source d'erreur la plus fréquente lors des audits menés rapidement. Les deux vues se ressemblent à l'écran et ne disent absolument pas la même chose.

Explorer sans exécution

Un outil d'exploration configuré pour ne pas exécuter le JavaScript donne la liste des adresses accessibles à la première analyse. La comparer avec la liste obtenue en exécutant le code montre exactement quels contenus dépendent du rendu. Un écart important signale une architecture fragile, et l'ampleur de cet écart constitue le meilleur indicateur du risque encouru. Un écart de quelques pour cent traduit une dépendance marginale, tolérable sur un site de taille moyenne. Un écart dépassant la moitié des adresses signale que l'exploration repose entièrement sur un rendu dont rien ne garantit la régularité.

Employer l'outil d'inspection d'adresse

Les outils pour webmasters proposent une inspection montrant le document tel que le moteur l'a rendu, avec la liste des ressources qu'il n'a pas pu charger. C'est la source la plus autorisée et elle règle les discussions. Les ressources bloquées y apparaissent explicitement, et un script essentiel bloqué par une directive d'exploration figure parmi les causes classiques d'un rendu incomplet. L'outil indique alors précisément quel fichier n'a pas pu être chargé, ce qui ramène le diagnostic à une simple lecture. Cette information vaut à elle seule le détour par l'interface, même lorsque l'on croit connaître sa configuration.

Vérifier les ressources bloquées

Un fichier JavaScript interdit à l'exploration ne sera pas exécuté, et le rendu sera donc incomplet. Cette situation résulte souvent d'une directive héritée d'une ancienne configuration, où l'on bloquait les répertoires techniques par principe. La correction consiste à autoriser l'exploration des ressources nécessaires au rendu, recommandation officielle depuis longtemps et pourtant régulièrement ignorée sur les sites anciens. La vérification prend quelques minutes et porte sur un fichier unique, généralement resté en l'état depuis la mise en ligne initiale. Le gain, lui, peut porter sur l'intégralité du site.

Tester avec un navigateur sans script

Désactiver le JavaScript dans un navigateur et parcourir le site donne une approximation utile de ce que voit un robot avant rendu. Si la navigation devient impossible, le site dépend entièrement de l'exécution. Cette méthode est moins précise que les précédentes, puisque les moteurs exécutent réellement le code, et elle donne une bonne intuition en quelques minutes, notamment sur les menus et la pagination. Elle a par ailleurs le mérite de pouvoir être menée par une personne non technique, ce qui la rend utile lors d'un premier échange avec un client. Les constats obtenus servent ensuite de point de départ à une analyse plus rigoureuse.

Croiser avec les journaux

Les journaux du serveur montrent quelles adresses le robot a réellement demandées. Une section entière absente de ces journaux, alors qu'elle est liée depuis le site, confirme qu'elle n'est pas découverte. C'est la vérification la plus concluante de toutes, puisqu'elle porte sur le comportement observé et non sur une simulation, et elle demande simplement de disposer de quelques semaines de journaux. Beaucoup d'hébergements les conservent par défaut sans que personne ne les consulte jamais. Un extrait filtré sur l'agent du robot suffit à répondre à la question posée.

Corriger sans tout réécrire

Les corrections sont généralement légères et ne remettent pas en cause l'architecture retenue, contrairement à ce que l'on craint souvent.

Ajouter une vraie adresse

La correction la plus universelle consiste à conserver le comportement existant tout en ajoutant une balise de lien avec une adresse réelle. Le script intercepte le clic et empêche la navigation par défaut, le robot suit l'adresse. Les deux publics sont servis, et cette modification tient en quelques lignes dans le composant concerné. C'est l'approche à privilégier dans la quasi totalité des cas. Elle a l'avantage de ne rien changer au comportement observé par les visiteurs, ce qui évite tout arbitrage avec les équipes chargées de l'expérience. Le déploiement peut donc se faire sans phase de validation prolongée.

Doubler la navigation

Lorsqu'un mécanisme ne peut pas porter de lien, un chemin parallèle doit exister : pagination classique en plus du défilement infini, plan de site en plus du menu dynamique, liste de catégories dans le pied de page. Ce doublement paraît redondant pour un visiteur et il est indispensable pour l'exploration. Il sert d'ailleurs aussi les visiteurs naviguant au clavier ou avec une technologie d'assistance. Les deux exigences se recouvrent largement, au point qu'un site correctement accessible pose rarement des difficultés d'exploration. Traiter les deux sujets ensemble économise donc du travail.

Rendre côté serveur

Sur une application construite entièrement côté navigateur, le rendu côté serveur des pages principales supprime le problème à la racine. Cette évolution représente un chantier réel et elle apporte simultanément un gain de vitesse d'affichage, ce qui la rend rentable au delà de la seule question de l'exploration. Les cadres applicatifs modernes la proposent nativement, ce qui réduit considérablement son coût par rapport à ce qu'elle représentait il y a quelques années. Le choix se pose surtout pour les applications existantes, où la migration touche à l'architecture. Pour un nouveau projet, la question est tranchée d'avance par les outils disponibles.

Prévoir un plan de site complet

Un plan de site XML listant l'ensemble des adresses permet la découverte même lorsque le maillage est déficient. C'est un filet de sécurité et non une solution : les pages découvertes par cette voie reçoivent peu de valeur interne et sont explorées moins souvent. Il vaut donc mieux le considérer comme un complément pendant la correction du maillage que comme une réponse au problème. Un plan de site parfaitement tenu sur un site dont le maillage interne est défaillant produit des pages connues mais peu visitées par le robot. La découverte n'est que la première étape, la fréquence d'exploration suit la valeur reçue par les liens.

Vérifier après correction

La même comparaison entre exploration avec et sans exécution, refaite après intervention, confirme que les liens sont désormais visibles. Ce contrôle prend dix minutes et il évite de croire à une correction qui n'a pas fonctionné, cas fréquent lorsque le composant modifié n'était pas celui employé sur toutes les pages. Le suivi des journaux dans les semaines suivantes complète cette vérification. L'apparition progressive des adresses concernées dans les demandes du robot constitue la preuve définitive que la correction a porté. Ce délai se compte en jours sur un site actif et en semaines sur un site peu mis à jour.

Poser la règle pour la suite

Une règle simple, écrite dans les conventions du projet, évite que le problème ne réapparaisse : tout élément menant à une autre page doit être une balise de lien avec une adresse. Cette phrase tient en une ligne et elle se vérifie en relecture de code. Son absence explique pourquoi le même chantier se refait tous les deux ans sur les projets où plusieurs développeurs se succèdent sans convention partagée.