DOMContentLoaded vs load : quel événement Googlebot attend-il réellement pour indexer votre contenu ?

Pourquoi cette distinction entre DOMContentLoaded et load est-elle cruciale en SEO ?

Googlebot analyse les pages en plusieurs étapes, et le timing de chargement détermine ce qui sera visible lors du premier rendu. DOMContentLoaded signale que la structure HTML a été entièrement parsée : le DOM est prêt, les scripts synchrones et defer ont été exécutés, mais les images, les iframes et les ressources externes ne sont pas encore chargées.

L'événement load, lui, indique que toutes les ressources référencées dans le DOM initial (images, feuilles de style, scripts async) ont été téléchargées. C'est le moment où la page est théoriquement complète — mais uniquement pour ce qui était présent dans le HTML de départ. Tout contenu injecté après cet événement (via setTimeout, fetch asynchrone, lazy-loading déclenché par scroll) n'est pas garanti d'être capturé.

Que se passe-t-il avec le contenu ajouté après load ?

Martin Splitt est clair : load ne tient pas compte du contenu ajouté ultérieurement par JavaScript. Si votre script injecte du texte, des liens ou des produits après cet événement — par exemple via un setTimeout(function() { renderProducts(); }, 2000) — Googlebot peut très bien ne pas attendre.

En pratique, Google dispose d'un budget de rendu limité : il n'attend pas indéfiniment que tous vos scripts asynchrones se terminent. Si le contenu critique arrive trop tard, il risque de ne pas être indexé lors du premier passage. C'est particulièrement problématique pour les sites e-commerce ou les SPA (Single Page Applications) qui chargent le catalogue côté client.

Comment Googlebot décide-t-il d'attendre ou non le contenu JavaScript ?

Google n'a jamais publié de seuil précis, mais les observations terrain montrent que Googlebot attend généralement jusqu'à l'événement load, puis patiente quelques secondes supplémentaires pour laisser les scripts s'exécuter. Passé ce délai, le premier rendu est figé.

Le moteur peut revenir plus tard pour un second rendu, mais rien ne garantit que ce second passage indexera le contenu manquant. D'où l'importance de charger le contenu critique avant load, idéalement avant DOMContentLoaded si vous voulez maximiser vos chances d'indexation immédiate.

• DOMContentLoaded : DOM parsé, scripts defer exécutés, ressources externes non encore chargées
• load : toutes les ressources du DOM initial téléchargées, mais contenu JavaScript ultérieur non pris en compte
• Risque SEO : tout contenu injecté après load (setTimeout, fetch différé, lazy-load sans SSR) peut être ignoré au premier rendu
• Budget de rendu : Googlebot n'attend pas indéfiniment — prioriser le contenu critique avant load est essentiel
• Second rendu : possible mais non garanti, ne comptez pas dessus pour indexer du contenu vital

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

Oui, et c'est même l'une des confirmations les plus nettes de Martin Splitt sur le timing de rendu. Les tests de rendering via Search Console ou des outils comme Oncrawl montrent régulièrement que Googlebot fige le premier rendu quelques secondes après load. Les contenus injectés tardivement (lazy-loading agressif, modales différées, produits chargés au scroll) sont souvent absents du HTML rendu.

Cela rejoint les recommandations de Google sur le rendu côté serveur (SSR) ou l'hydratation progressive : si vous voulez garantir l'indexation, le contenu doit être présent dans le DOM avant que Googlebot ne « prenne la photo ». Les frameworks modernes (Next.js, Nuxt) ont intégré cette logique en proposant du SSR ou du SSG par défaut — pas par hasard.

Quelles nuances faut-il apporter à cette affirmation ?

Premier point : Google peut effectuer un second rendu quelques jours ou semaines après le premier passage, notamment pour les pages à fort trafic ou régulièrement mises à jour. Mais ce second rendu n'est ni systématique ni rapide. Compter dessus pour indexer votre catalogue produit est un pari risqué.

Deuxième nuance : le délai d'attente après load n'est pas documenté officiellement. Les observations empiriques suggèrent entre 2 et 5 secondes supplémentaires, mais cela varie selon le crawl budget, la réputation du domaine, et la complexité de la page. [À vérifier] : aucune donnée officielle ne confirme ce délai — c'est une extrapolation basée sur des tests in the wild.

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

Sur des sites à très forte autorité et crawl budget élevé (ex: Amazon, Wikipedia), Google peut se permettre de revenir fréquemment et d'attendre plus longtemps. Le moteur dispose de ressources quasi illimitées pour ces domaines et peut déclencher plusieurs rendus successifs.

Autre exception : les pages AMP ou les contenus servis via un CDN optimisé avec prerendering côté edge. Dans ces cas, le HTML est déjà rendu avant même que Googlebot ne le demande, donc la question de DOMContentLoaded/load devient caduque. Le contenu est immédiatement visible, sans attente JavaScript.

Que faut-il faire concrètement pour garantir l'indexation du contenu JavaScript ?

Premier réflexe : injecter le contenu critique avant DOMContentLoaded, idéalement via du Server-Side Rendering (SSR) ou du Static Site Generation (SSG). Si votre framework le permet (Next.js, Nuxt, SvelteKit), activez le rendu côté serveur pour les pages stratégiques : fiches produit, catégories, landing pages SEO.

Si le SSR n'est pas une option, assurez-vous que vos scripts critiques sont en defer, pas en async. Les scripts defer s'exécutent dans l'ordre et avant DOMContentLoaded, ce qui garantit que le contenu sera présent au moment du premier événement de timing clé. Les scripts async, eux, s'exécutent dès qu'ils sont téléchargés, sans garantie de séquence — dangereux pour du contenu dépendant d'autres ressources.

Quelles erreurs éviter absolument ?

Ne comptez jamais sur un setTimeout() pour charger du contenu indexable. C'est le piège classique des SPA mal configurées : le HTML initial est vide, et un script déclenche le rendu 1 ou 2 secondes après load. Googlebot peut très bien partir avant. Si vous devez différer le chargement, utilisez plutôt un IntersectionObserver avec un fallback SSR pour le contenu above-the-fold.

Autre erreur fréquente : lazy-loader les images critiques (hero, logo, première image produit) sans attribut loading="eager". Les images en lazy-loading ne se chargent qu'au scroll ou à l'apparition dans le viewport — si Googlebot ne les voit pas au premier rendu, elles n'existent pas pour lui. Réservez le lazy-loading aux images below-the-fold, jamais au contenu visible immédiatement.

Comment vérifier que mon site respecte ces contraintes de timing ?

Utilisez l'outil d'inspection d'URL de Google Search Console : il vous montre le HTML rendu tel que Googlebot le voit. Comparez-le avec votre DOM côté client (inspecter l'élément dans Chrome). Si du contenu manque dans la version Search Console, c'est qu'il arrive trop tard.

Complétez avec WebPageTest en mode « First View » et filmstrip activé : vous verrez exactement quand DOMContentLoaded et load se déclenchent, et si votre contenu est visible à ces moments-là. Si vos produits apparaissent 3 secondes après load, vous avez un problème. Enfin, testez avec Screaming Frog en mode rendu JavaScript : l'outil simule Googlebot et vous indique ce qui est capturé au premier passage.

• Activer le SSR ou SSG pour les pages stratégiques (fiches produit, catégories, landing pages)
• Utiliser defer pour les scripts critiques, jamais async si le contenu dépend d'un ordre d'exécution
• Éviter setTimeout() pour charger du contenu indexable — privilégier l'injection immédiate ou l'hydratation progressive
• Réserver le lazy-loading aux ressources below-the-fold, jamais au contenu above-the-fold ou critique
• Vérifier le HTML rendu via Search Console (outil d'inspection d'URL) et le comparer au DOM client
• Tester le timing de chargement avec WebPageTest (filmstrip) et Screaming Frog (mode JS activé)