JavaScript, rendu et contenu que le moteur ne voit pas

Un moteur traite une page en deux temps. Il récupère d'abord le code HTML servi par le serveur, et en extrait ce qu'il peut. Il place ensuite la page dans une file d'attente pour l'exécution du JavaScript, et revient plus tard.

Pourquoi la seconde passe pose problème

Elle est coûteuse. Exécuter les scripts d'une page demande beaucoup plus de ressources que lire du HTML, et le moteur arbitre à l'échelle du web entier.

Elle est différée. Le délai va de quelques secondes à plusieurs jours selon le site. Pour un contenu d'actualité, c'est rédhibitoire.

Elle n'est pas garantie. Si un script échoue, si une ressource est bloquée, si le rendu dépasse un délai, la page reste dans l'état de la première passe.

Ce qui casse concrètement

Les liens sans href. Un élément cliquable qui déclenche une navigation par script, sans attribut href dans une balise <a>, n'est pas suivi. C'est la cause la plus fréquente de pages inaccessibles.

Le contenu chargé après interaction. Un texte qui n'apparaît qu'après un clic sur « voir plus » n'est pas vu, parce que le moteur ne clique pas.

Le défilement infini sans URL. Ce qui se charge au défilement n'existe pas, sauf à proposer une pagination avec de vraies adresses en parallèle.

Les ressources bloquées. Un robots.txt qui interdit le dossier des scripts empêche le rendu. Le moteur voit alors une page vide.

Les métadonnées injectées tardivement. Un titre ou une canonique posés par script après le chargement sont pris en compte au mieux à la seconde passe, et parfois pas du tout.

Les quatre stratégies de rendu

Rendu côté serveur. Le serveur renvoie le HTML complet, le JavaScript ne sert qu'à enrichir l'interaction. C'est la solution la plus robuste, et la seule qui fonctionne pour tous les robots.

Génération statique. Les pages sont produites une fois à la compilation. Idéal pour un contenu qui change peu, imbattable en performance.

Rendu dynamique. Le serveur détecte les robots et leur sert une version pré-rendue. Google l'a longtemps toléré et le décrit maintenant comme une solution de contournement. Fonctionne, demande de l'entretien.

Rendu côté client seul. Tout est construit dans le navigateur. À réserver aux applications derrière authentification, qui n'ont pas vocation à être indexées.

Vérifier ce que le moteur voit

Trois gestes, du plus rapide au plus complet.

Affichez le code source de la page, celui que renvoie le serveur, pas l'inspecteur du navigateur qui montre le résultat après exécution. Cherchez-y votre texte principal, vos titres, vos liens. Ce qui n'y figure pas dépend de la seconde passe.

Désactivez JavaScript dans le navigateur et rechargez. Ce qui reste est ce qu'un robot sans rendu obtient, et c'est exactement la vue de la plupart des robots d'IA.

Utilisez l'inspection d'URL de la Search Console, qui affiche le HTML rendu par Google après exécution. C'est la référence pour Google, et elle seule.

Le cas des cadres d'application modernes

Les principaux cadres proposent aujourd'hui un rendu côté serveur ou une génération statique en option. Le problème n'est presque jamais l'outil, c'est le mode retenu au démarrage du projet, souvent choisi pour la rapidité de développement et jamais rediscuté.

La question à poser à une équipe technique tient en une phrase : que contient le HTML renvoyé par le serveur avant toute exécution de script. Si la réponse est « une balise div vide », il y a un chantier.