Pourquoi Googlebot ignore-t-il vos images en lazy loading sous le pli ?

Googlebot scrolle-t-il pour indexer vos images ?

La réponse est non, catégoriquement. Googlebot charge la page, analyse le DOM initial, et s'arrête là. Il ne simule pas de scroll utilisateur pour déclencher le chargement progressif d'images en lazy loading situées sous le premier viewport.

Cette limitation technique impacte directement l'indexation dans Google Images. Si une image n'apparaît pas au premier chargement, elle n'existe tout simplement pas pour le crawler. Le lazy loading natif (loading="lazy") ou via JavaScript produit le même effet : invisibilité.

Pourquoi cette restriction technique existe-t-elle ?

Le crawl budget explique une partie du problème. Simuler des interactions utilisateur (scroll, clic, hover) multiplierait le temps et les ressources nécessaires pour crawler chaque page. Google a fait un arbitrage technique : indexer massivement plutôt que profondément.

Le rendu JavaScript moderne complique encore la donne. Googlebot exécute JavaScript, mais dans une fenêtre de temps limitée. Les événements onscroll ou Intersection Observer ne se déclenchent pas sans interaction réelle, donc les images conditionnelles restent en attente perpétuelle.

Comment Google différencie-t-il les images prioritaires ?

Pour Google, seule compte la présence effective dans le HTML initial ou le DOM post-rendu immédiat. Une balise IMG avec attribut src rempli = indexable. Un data-src attendant un scroll = ignoré.

Cette logique binaire ne tient pas compte de l'importance sémantique ou éditoriale de l'image. Une illustration clé placée à 1200px de scroll subit le même traitement qu'une image décorative : aucune indexation.

• Googlebot ne scrolle pas : les images lazy-loadées hors premier viewport restent invisibles
• Seul le DOM initial compte : attribut src présent au chargement = indexation garantie
• Pas de distinction sémantique : Google ignore l'importance éditoriale, seule la position technique importe
• Alternative landing page : créer des pages dédiées aux images stratégiques comme Wikipedia
• Arbitrage performance vs visibilité : le lazy loading améliore le LCP mais détruit l'indexation image

Cette déclaration reflète-t-elle vraiment le comportement terrain observé ?

Oui, et les tests le confirment depuis des années. Des audits sur des sites e-commerce montrent que 60 à 80% des images produit en lazy loading sous le pli n'apparaissent jamais dans Google Images. Cette déclaration officialise simplement ce que les praticiens constatent quotidiennement.

La nuance importante : Googlebot exécute le JavaScript initial, donc une image chargée via JS au premier rendu (sans nécessiter de scroll) sera indexée. Le problème concerne spécifiquement les déclencheurs conditionnels liés à l'interaction utilisateur.

Quelles contradictions apparaissent avec les recommandations Core Web Vitals ?

Google recommande officiellement le lazy loading pour optimiser le LCP et réduire le poids initial. Mais cette même optimisation sacrifie l'indexation image. Le paradoxe est brutal : améliorer vos Core Web Vitals peut détruire votre visibilité dans Google Images.

Pour les sites dont le trafic Images représente 15-30% du total (mode, déco, voyage), ce conflit devient stratégique. Aucune consigne claire de Google sur l'arbitrage à faire. [A vérifier] : Google affirme que l'impact ranking global compense la perte Images, mais aucune donnée publique ne l'étaye.

Dans quels cas cette règle s'applique-t-elle différemment ?

Les sites avec architecture JavaScript côté client (React, Vue, Angular) subissent un double effet. Si le framework charge les images après hydratation, même en haut de page, l'indexation reste aléatoire. Le timing de rendu devient critique.

Cas particulier des AMP et pages mobiles : AMP impose son propre système de lazy loading (amp-img). Googlebot AMP applique les mêmes règles, mais le viewport initial mobile étant plus petit, encore moins d'images passent le filtre. Une galerie produit mobile peut perdre 90% de ses images indexables.

Que faut-il faire concrètement pour préserver l'indexation image ?

Désactiver le lazy loading sur les images stratégiques reste la solution la plus directe. Identifiez les 3-5 images clés par page (hero, produit principal, visuels éditoriaux prioritaires) et forcez loading="eager" ou retirez l'attribut loading. Ces images doivent avoir un src classique, pas de data-src.

Pour les sites e-commerce avec centaines de références, créez des landing pages image dédiées comme Wikipedia. Une page légère par produit, optimisée pour l'indexation image, avec métadonnées structurées (ImageObject schema). Cette approche double votre surface indexable sans pénaliser la performance des pages transactionnelles.

Comment vérifier que vos images passent le filtre Googlebot ?

Utilisez l'outil Inspection d'URL dans Search Console et regardez la capture d'écran rendue. Toute image absente de cette capture ne sera pas indexée. Comparez avec votre page réelle scrollée : l'écart révèle les pertes.

Testez aussi avec Mobile-Friendly Test en mode mobile. Le viewport initial mobile étant plus petit (généralement 375-414px de large), vous verrez combien d'images disparaissent. Un slider produit qui affiche 4 images desktop peut n'en montrer qu'une seule mobile à Googlebot.

Quelles erreurs critiques éviter absolument ?

Ne comptez pas sur JavaScript pour "contourner" cette limitation. Des développeurs tentent de charger toutes les images via JS puis de les masquer visuellement avec CSS. Googlebot détecte ces manipulations et peut appliquer des pénalités pour cloaking si l'écart DOM/rendu visuel est trop important.

Évitez aussi le piège du "lazy loading conditionnel" basé sur User-Agent. Désactiver le lazy pour Googlebot uniquement crée une divergence expérience utilisateur/crawler que Google classe comme pratique trompeuse. Les sanctions peuvent aller au-delà de la simple non-indexation des images.

• Auditer les images actuellement indexées via Google Images avec site:votredomaine.com
• Identifier les images stratégiques (conversions, trafic, backlinks potentiels) et leur position viewport
• Désactiver loading="lazy" sur toute image au-dessus de 800px de scroll
• Implémenter des landing pages dédiées pour les images à fort potentiel SEO
• Tester systématiquement avec Search Console Inspection avant déploiement
• Monitorer l'évolution du trafic Google Images après modifications (attendre 4-6 semaines)