La plupart des conseils pour indexer une application JavaScript tournent autour du pré-rendu ou d’Angular Universal. Mais si votre application tourne déjà en production sans ces briques, vous avez besoin d’une méthode de diagnostic, pas d’une refonte. Vérifier que Google explore et indexe correctement vos pages impose de contrôler le fichier robots.txt, le contenu présent au moment de l’événement load et l’inspection d’URL dans la Search Console, car Google n’indexe que le HTML rendu en moins de cinq secondes. Voici les vérifications concrètes à mener.
Ce que Google fait avant d’indexer une page JavaScript
Qu’est-ce que l’indexation Google, au juste ? Google stocke une version du contenu rendu d’une page pour l’afficher dans les résultats de recherche. Pour une application JavaScript, le processus se déroule en trois temps : exploration, affichage, indexation.
Le robot découvre d’abord les URL, puis il charge la page comme un navigateur récent, enfin il enregistre le HTML généré si le rendu aboutit, ce qui suppose que les scripts s’exécutent dans un ordre précis et que les ressources bloquantes aient fini de charger. Si le JavaScript ne s’exécute pas ou trop lentement, la page indexée reste vide ou partielle.
Le point souvent oublié, c’est que l’indexation ne récupère pas le fichier JavaScript brut. Googlebot n’affiche pas le code des fichiers bloqués dans les résultats. Il traite ce que le navigateur a réellement rendu à l’écran, c’est-à-dire le DOM modifié par les scripts.
Du coup, si un script charge du contenu après coup, hors de l’événement load, ce contenu peut ne jamais apparaître dans l’index, car le robot a déjà pris sa décision sur la base d’un DOM figé qui ne bougera plus. C’est pour cette raison qu’une application en production demande un diagnostic précis, pas seulement un passage au pré-rendu.
Pour lever toute ambiguïté, l’indexation n’est pas la simple sauvegarde d’une URL dans une base. C’est le processus par lequel Google analyse le contenu rendu, le trie et le rend éligible à une requête. Si le rendu échoue, l’URL peut rester explorée mais jamais indexée. Cette distinction explique pourquoi une application JavaScript visible dans un navigateur humain peut rester invisible dans les résultats, même sans blocage robots.txt.
La vérification du fichier robots.txt
Avant même de penser au rendu JavaScript, il faut contrôler ce que le fichier robots.txt autorise. Googlebot commence par là : si l’URL y est marquée comme non autorisée, la requête HTTP ne part jamais et l’URL est ignorée.
Dans la Search Console, la recherche Google n’affichera pas le code JavaScript des fichiers ou des pages bloqués. Une seule ligne Disallow trop large peut donc faire disparaître des dizaines de routes de l’index, sans que le site émette la moindre erreur visible.
Les points de contrôle du fichier d’accès
- Ce que renvoie l’outil de test robots.txt de la Search Console pour l’URL concernée.
- Une directive Disallow qui bloque un répertoire de scripts critiques.
- Pourquoi la page d’accueil est autorisée mais pas la route de détail ?
- Le chemin exact de l’URL à tester, avec ses paramètres éventuels.
- Un ancien blocage de préproduction oublié dans le fichier.
Une fois ce contrôle passé, vous savez si Googlebot peut seulement envoyer une requête. Mais l’autorisation d’exploration ne dit rien de la qualité du rendu. Une page peut être parfaitement accessible et pourtant renvoyer un DOM vide si le JavaScript ne s’exécute pas au bon moment. C’est là que l’événement load entre en jeu.
Le contenu au moment de l’événement load
Posez-vous une question simple : que voit la page au moment précis où l’événement load se déclenche ? Makina Corpus indique que seul le contenu présent dans la page lors de cet événement est indexé. Sur ce point, voir aussi notre article sur dealbook.fr.
Autrement dit, si votre application charge des produits, des articles ou des commentaires via un appel asynchrone qui se termine après le load, Google risque de ne jamais voir ce texte. Ouvrez les outils de développement du navigateur, videz le cache et regardez l’onglet Network : le DOM final figé au moment du load est celui qui compte pour l’indexation.
Pour vérifier ce point, lancez un audit manuel avant d’ouvrir la Search Console. Le DOM final, celui qui résulte de l’exécution des scripts et des éventuels appels réseau terminés avant le load, doit être comparé au contenu que vous souhaitez.
Désactivez le cache, rechargez la page et capturez le code HTML généré dans l’onglet Elements, pas le code source initial. Voir indexé, car c’est exactement cette version que Googlebot va analyser pour décider si la page répond à une requête.
Le délai d’exécution et l’inspection d’URL dans la Search Console
Makina Corpus indique aussi que le JavaScript doit s’exécuter rapidement, en visant moins de cinq secondes. Cette contrainte n’est pas anodine pour une application lourde qui charge plusieurs bundles ou qui attend des API tierces avant d’afficher quoi que ce soit.
Si le rendu dépasse ce délai, Googlebot peut abandonner la page ou n’enregistrer qu’une version incomplète, en particulier lorsque des appels réseau lents retardent l’affichage du contenu principal au-delà de ce que le robot est prêt à attendre pendant cette phase de traitement. Dans la Search Console, l’outil d’inspection d’URL montre exactement le HTML rendu que Google a capté, ainsi qu’une capture d’écran de la page vue par le robot.
Pour croiser les données, lancez une inspection d’URL sur une page produit ou un article, pas seulement sur l’accueil. L’aperçu du rendu ne ment pas. Il peut révéler un écran vide, un loader qui ne se termine jamais ou un contenu tronqué.
Si vous voyez un message du type « Google n’a pas pu charger toutes les ressources », le problème vient souvent d’un fichier JavaScript bloqué ou d’un délai trop long. C’est à ce stade que les vérifications sur l’événement load prennent tout leur sens.
Pour suivre la fréquence de passage du robot et croiser ces informations avec les journaux de votre serveur, certains tableaux de bord comme mystpi.com rassemblent les données utiles sans exiger de refonte. Cela ne remplace pas l’inspection manuelle, mais ça aide à repérer les pages qui sortent de l’index après une mise en production.
Rappelons que la solution du pré-rendu n’est pas la seule issue. Angular Universal est intégré dans le cœur d’Angular 4 et nécessite un serveur NodeJS pour effectuer le rendu côté serveur. Mais pour une application déjà en production, l’objectif premier est de mesurer ce que Google voit réellement, pas de réécrire immédiatement la stack.
Garder le contrôle du rendu sans tout réécrire
Le diagnostic d’une application JavaScript sans pré-rendu passe par des gestes simples : contrôler le fichier robots.txt, observer le DOM au moment du load et recouper avec l’inspection d’URL. Ces vérifications prennent moins d’une heure et évitent de foncer vers une refonte coûteuse.
Une fois les blocages repérés, vous pouvez décider sereinement entre un pré-rendu partiel, une optimisation des scripts ou un passage à Angular Universal. Est-ce que votre prochaine mise en production inclura un contrôle systématique du rendu avant le déploiement ?
