Le Googlebot crawle-t-il vos liens JavaScript avant même de rendre la page ?

Que signifie réellement cette séquence crawl/rendu ?

Martin Splitt décrit ici le pipeline en deux temps de Googlebot : d'abord la récupération de l'HTML brut, puis le rendu JavaScript différé. Cette architecture n'est pas nouvelle, mais Google explicite ici un détail crucial : les liens présents dans le HTML initial sont extraits immédiatement, avant même que le moteur de rendu ne traite le moindre script.

Cela signifie qu'un lien codé en dur dans votre source HTML (<a href="...">) entre dans la file de crawl sans délai. À l'inverse, un lien généré par React, Vue ou tout framework JS client-side devra attendre que Googlebot alloue des ressources de rendu à cette URL — ce qui peut prendre de quelques heures à plusieurs jours selon le crawl budget et la priorité perçue de la page.

Pourquoi Google sépare-t-il crawl et rendu ?

Le rendu JavaScript est coûteux en ressources. Exécuter des milliers de scripts par seconde pour chaque URL crawlée multiplierait les besoins en CPU et en mémoire par un facteur prohibitif. Google optimise donc son infrastructure en séparant la collecte rapide (HTML brut, détection de ressources) du traitement lourd (exécution JS, construction du DOM final).

Cette architecture explique pourquoi un site entièrement en JS sans SSR (Server-Side Rendering) ou pre-rendering subit souvent un délai d'indexation : Googlebot découvre la page, la met en file d'attente, puis doit revenir plus tard avec un budget de rendu pour en extraire le contenu réel. Entre-temps, vos concurrents avec du HTML statique sont déjà indexés.

Quelles ressources Googlebot détecte-t-il dans l'HTML initial ?

Martin Splitt mentionne CSS, JavaScript et images. Googlebot parse le HTML brut pour identifier les balises <link>, <script>, <img> et leurs attributs src, href. Ces ressources sont ajoutées à la file de téléchargement pour permettre un rendu complet ultérieur.

Mais attention : une image ou un script chargé dynamiquement via JS (document.createElement('img')) ne sera détecté qu'après le rendu. Si votre LCP (Largest Contentful Paint) dépend d'une ressource absente du HTML initial, Googlebot ne la verra pas immédiatement — et vos Core Web Vitals en pâtiront également côté utilisateur.

• Les liens en HTML brut sont crawlés instantanément, avant tout rendu JavaScript.
• Les ressources critiques (CSS, JS, images) doivent figurer dans le HTML initial pour être détectées rapidement.
• Le rendu JS est asynchrone : un délai variable sépare la découverte de la page et son indexation complète.
• Le crawl budget est consommé deux fois : une fois pour l'HTML, une fois pour le rendu différé.
• Les sites full-JS sans SSR/pre-rendering subissent systématiquement un handicap de vitesse d'indexation.

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

Oui, et c'est même l'un des rares cas où Google expose clairement une architecture technique vérifiable. Les tests terrain confirment depuis des années que les liens en HTML statique apparaissent dans Search Console bien avant ceux générés par JavaScript. Les crawls avec un user-agent Googlebot desktop montrent un HTML brut sans exécution JS — exactement ce que décrit Splitt.

En revanche, Google reste évasif sur les délais réels de rendu. « Plus tard » peut signifier 2 heures comme 2 semaines selon le site. Les sites à faible autorité ou mal optimisés pour le crawl budget constatent souvent que certaines pages JS ne sont jamais rendues. [A vérifier] : Google ne fournit aucune métrique officielle sur le pourcentage de pages JS effectivement rendues par Googlebot dans un délai raisonnable.

Quelles nuances faut-il apporter face à cette règle ?

Cette déclaration s'applique au crawl initial, mais ne couvre pas tous les scénarios. Par exemple, Googlebot peut re-crawler une page déjà rendue sans forcément la re-rendre — il récupère alors l'HTML brut, extrait les nouveaux liens, mais peut ignorer les changements de contenu JS si la page n'a pas changé côté serveur.

Autre point : les liens lazy-loaded via intersection observer ou scroll events. Même avec rendu JS, Googlebot ne scrolle pas automatiquement jusqu'au bas de page. Un lien qui n'apparaît qu'après un scroll utilisateur reste invisible pour le bot, sauf si votre implémentation le charge aussi au viewport initial ou via un mécanisme détectable. Google le reconnaît parfois, mais reste flou sur la profondeur de simulation des interactions.

Dans quels cas cette règle ne s'applique-t-elle pas pleinement ?

Les sites à très forte autorité (Wikipedia, Amazon, grands médias) bénéficient d'un crawl budget massif et d'un rendu quasi-instantané. Pour eux, la séparation crawl/rendu est transparente. À l'opposé, un site neuf ou peu linkés peut voir ses pages JS mises en queue pendant des jours, voire ignorées si Googlebot juge le rendu non prioritaire.

Les Progressive Web Apps (PWA) avec routing côté client posent aussi problème : si votre navigation repose sur history.pushState sans URLs serveur réelles, Googlebot ne découvrira jamais ces « pages » via le HTML initial. Vous devez alors fournir un sitemap XML ou un SSR pour exposer toutes les routes.

Que faut-il faire concrètement pour optimiser la découverte de vos liens ?

Placez vos liens critiques dans l'HTML initial. Si votre navigation principale, votre pagination ou vos liens internes stratégiques sont générés par React/Vue/Angular, implémentez un SSR (Next.js, Nuxt.js, Angular Universal) ou un pre-rendering (Prerender.io, Rendertron). Cela garantit que Googlebot extrait ces liens dès le crawl, sans attendre le rendu.

Pour les sites e-commerce ou éditoriaux à fort volume, ce choix architectural fait la différence entre une indexation fluide et un goulot d'étranglement permanent. Les pages profondes (catégories, fiches produit, articles anciens) doivent être accessibles via des liens HTML statiques pour ne pas dépendre du bon vouloir du rendu différé.

Quelles erreurs éviter lors de l'implémentation JavaScript ?

Ne comptez jamais sur le rendu JS pour exposer des liens de pagination ou de catégories. Un site qui affiche « Charger plus » via JS sans lien <a href> alternatif condamne ses pages profondes à l'invisibilité. Googlebot ne clique pas sur les boutons.

Évitez également de bloquer CSS ou JavaScript dans robots.txt « pour économiser le crawl budget ». Google a besoin de ces ressources pour le rendu — les bloquer retarde ou empêche l'indexation du contenu JS. Laissez Googlebot accéder à tous les fichiers nécessaires au rendu, et optimisez plutôt la vitesse de réponse serveur et la taille des bundles.

Comment vérifier que votre site respecte ces principes ?

Utilisez l'outil Inspect URL de Search Console et comparez la version « crawled » (HTML brut) à la version « rendered ». Si des liens critiques n'apparaissent que dans la version rendered, ils subissent le délai de rendu. Crawlez votre site avec Screaming Frog en mode « text only » (sans JS) : tous les liens absents de ce crawl sont invisibles au premier passage de Googlebot.

Auditez aussi vos Core Web Vitals : un LCP qui dépend d'une image chargée en JS pénalise à la fois l'expérience utilisateur et le rendu Googlebot. Injectez les ressources critiques dans le HTML initial via <link rel="preload"> ou un SSR complet.

• Implémenter SSR ou pre-rendering pour exposer navigation et liens internes en HTML brut
• Vérifier avec Screaming Frog (mode sans JS) que tous les liens critiques sont présents
• Comparer "crawled" vs "rendered" dans Search Console pour détecter les écarts
• Remplacer les boutons "Charger plus" par des liens HTML de pagination classiques
• Ne jamais bloquer CSS/JS dans robots.txt si votre contenu en dépend
• Précharger les ressources critiques (images LCP, fonts, CSS) dans le HTML initial