Les liens JavaScript retardent-ils vraiment la découverte par Google ?

Que se passe-t-il exactement quand Googlebot rencontre du JavaScript ?

Googlebot opère en deux temps : il récupère d'abord le HTML brut renvoyé par le serveur, scanne les liens présents, puis — après une phase de rendu JavaScript — revisite le contenu enrichi par le client. Ce second passage peut intervenir quelques heures plus tard, selon la file d'attente de rendu.

Si vos liens stratégiques n'apparaissent qu'après exécution JS (ex: menu généré via React, navigation en SPA), Google ne les détecte qu'au second passage. Le délai observé est qualifié de « légèrement retardé » par Martin Splitt — formulation floue qui mérite d'être challengée.

Pourquoi cette distinction entre HTML brut et rendu ?

Google privilégie la découverte rapide via le HTML brut parce que c'est moins coûteux en ressources serveur. Le rendu JavaScript mobilise CPU, mémoire, et une file d'attente dédiée — d'où le décalage temporel.

Pour un site e-commerce avec des fiches produits ajoutées chaque jour, ce délai peut signifier que de nouveaux produits restent invisibles plusieurs heures. À l'inverse, sur un site vitrine quasi statique, l'impact est négligeable : quelques heures ne changent rien au référencement global.

À partir de quel seuil de pages faut-il s'inquiéter ?

Splitt pose un seuil entre 1 et 10 millions de pages — une fourchette assez large pour être suspecte. En dessous, dit-il, « cela ne pose généralement aucun problème ». En dessus, silence radio.

Cette affirmation reste vague : quel impact réel au-delà de 10M de pages ? Un délai qui passe de quelques heures à quelques jours ? Une perte de crawl budget critique ? [À vérifier] — Google ne fournit ni chiffre précis ni étude de cas publique.

• Deux passages de crawl : HTML brut d'abord, puis rendu JavaScript quelques heures après.
• Délai déclaré : « quelques heures » — formulation imprécise qui ne permet pas d'anticiper finement.
• Seuil de risque : entre 1 et 10 millions de pages, mais aucune donnée chiffrée sur l'impact au-delà.
• Contexte déterminant : fréquence d'ajout de nouveaux contenus, architecture SPA ou hybride, budget crawl alloué.
• Crawl budget : un site massif avec liens en JS peut saturer sa file de rendu avant même que tous les liens soient découverts.

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

Oui et non. Sur des sites de taille moyenne, on constate effectivement que les liens JS finissent par être crawlés sans drame. Le délai de quelques heures correspond aux remontées terrain — à condition que le site n'ait pas de problème structurel (timeout JS, erreurs console, redirections en chaîne).

En revanche, sur des plateformes avec publication fréquente (actualité, e-commerce flash, agrégateurs), ce délai devient tangible. Un article publié à 9h du matin peut n'être découvert qu'à 14h — ce qui impacte directement la fenêtre de visibilité sur Google Discover ou Top Stories. [À vérifier] : Google ne précise jamais si ce délai est incompressible ou si un site bien optimisé peut l'accélérer.

Quelles nuances faut-il apporter à ce seuil de 1 à 10 millions de pages ?

Ce seuil pose plus de questions qu'il n'en résout. D'abord, il y a un facteur 10 entre les deux bornes — difficile d'en faire une règle actionnable. Ensuite, le volume de pages n'est qu'un indicateur : un site de 500 000 pages avec 80 % de contenu dupliqué ou thin aura plus de soucis qu'un site de 5 millions bien structuré.

Concrètement, le vrai critère n'est pas tant le nombre de pages que la fréquence de mise à jour et la densité de liens internes générés par JS. Un média avec 200 000 articles actualisés chaque heure via React sera plus impacté qu'un catalogue produit statique de 2 millions de fiches. Google ne le dit pas — mais c'est ce qu'on observe.

Quand cette règle ne s'applique-t-elle pas du tout ?

Soyons honnêtes : si votre navigation principale, votre fil d'Ariane ou vos liens de pagination sont exclusivement en JS, le délai devient un vrai problème. Googlebot peut certes finir par tout découvrir, mais il le fera avec un temps de latence qui pénalise l'indexation des nouvelles pages.

Autre cas critique : les sites en infinite scroll avec chargement Ajax des contenus suivants. Google ne scrolle pas — si le lien « page suivante » n'existe qu'en JS et que vous n'avez pas de fallback HTML, une partie de votre contenu reste invisible. Splitt ne mentionne rien à ce sujet, ce qui est curieux pour une déclaration censée rassurer.

Que faut-il faire concrètement pour limiter ce délai ?

Première règle : ne mettez pas tous vos œufs dans le même panier. Si vos liens de navigation, pagination ou maillage interne stratégique peuvent exister en HTML brut, faites-le. Un rendu côté serveur (SSR) ou une génération statique (SSG) garantit une découverte immédiate.

Deuxième réflexe : testez le HTML brut renvoyé par votre serveur. Faites un curl ou utilisez « Afficher la source de la page » (pas l'inspecteur, qui affiche le DOM final). Tous vos liens critiques sont-ils présents ? Si non, vous dépendez du rendu JS — et donc du délai évoqué par Splitt.

Quelles erreurs éviter absolument ?

Ne comptez pas sur la patience de Google. Même si Splitt dit que « ça ne pose généralement pas de problème », un site mal optimisé cumule les retards : délai de rendu, erreurs JS non catchées, timeouts, redirections client-side. Résultat : des pages qui mettent plusieurs jours à être découvertes, voire jamais crawlées si elles tombent hors budget.

Autre piège classique : croire qu'un sitemap XML suffit à compenser. Le sitemap accélère la découverte des URL, mais ne remplace pas un maillage interne solide en HTML. Si vos liens internes n'existent qu'en JS, le PageRank interne circule mal — et ça, aucun sitemap ne le corrige.

Comment vérifier que mon site est bien crawlé malgré le JS ?

Utilisez la Search Console : section « Couverture » pour repérer les pages découvertes mais non indexées, et « Inspection d'URL » pour visualiser le rendu final vu par Google. Comparez le HTML brut et le HTML rendu — si l'écart est énorme, vous êtes en zone de risque.

Parallèlement, surveillez les logs serveur : combien de temps entre la première requête Googlebot (HTML brut) et la seconde (rendu) ? Si ce délai dépasse régulièrement 24h, c'est que votre file de rendu est saturée ou que Google juge votre site peu prioritaire. Dans ce cas, optimisez : réduisez le poids JS, corrigez les erreurs console, passez en SSR partiel.

• Auditer le HTML brut renvoyé par le serveur pour vérifier la présence des liens stratégiques
• Privilégier le rendu côté serveur (SSR) ou la génération statique (SSG) pour les zones critiques
• Tester le rendu Google via l'outil « Inspection d'URL » de la Search Console
• Analyser les logs serveur pour mesurer le délai réel entre crawl HTML et crawl rendu
• Ne jamais compter uniquement sur le sitemap XML pour compenser un maillage interne faible
• Surveiller les erreurs JavaScript en production — un JS qui plante bloque la découverte