Le lazy loading condamne-t-il vos images à l'invisibilité sur Google ?

Pourquoi Googlebot rate-t-il certaines images en lazy loading ?

Le lazy loading diffère le chargement d'une image jusqu'à ce qu'elle soit proche du viewport utilisateur. Cette technique booste les Core Web Vitals en réduisant le poids initial de la page.

Googlebot ne simule pas toujours un scroll infini lors du crawl. Quand une image dépend d'un événement JavaScript de scroll ou d'intersection observer, le bot peut quitter la page avant que le script ne déclenche le chargement. Résultat : l'URL de l'image n'apparaît jamais dans le DOM analysé par le crawler, et l'image n'est jamais indexée.

Que signifie concrètement la balise noscript dans ce contexte ?

Une balise <noscript> contient une version fallback de l'<img> qui s'affiche uniquement si JavaScript est désactivé. Googlebot, même s'il exécute JavaScript, peut parser le HTML brut avant l'exécution JS.

En plaçant une image dans <noscript>, tu garantis que Googlebot voit l'URL même si le JS lazy-load échoue. Mais attention : cela crée une duplication dans le DOM côté client, avec un risque de charger deux fois la même ressource si l'implémentation est bâclée. Certains frameworks modernes ignorent complètement <noscript> côté client, ce qui complique la mise en œuvre.

Les données structurées sont-elles une vraie alternative ?

Mueller évoque les données structurées pour référencer les images directement dans le JSON-LD. Un schema.org de type Product, Article ou ImageObject peut lister explicitement les URLs d'images dans les propriétés image ou contentUrl.

Cette approche fonctionne parce que Googlebot parse le JSON-LD indépendamment du rendu visuel de la page. Même si l'image n'apparaît jamais dans le DOM visible, Google sait qu'elle existe et peut l'indexer pour Google Images. Le problème ? Ça demande de maintenir un mapping strict entre les images affichées et celles déclarées dans le schema, avec un risque de décalage lors des mises à jour éditoriales.

• Googlebot n'exécute pas toujours le scroll nécessaire pour déclencher les images lazy-loadées via JavaScript.
• La balise <noscript> fournit une URL de secours parsable dans le HTML brut, mais peut créer des doublons côté client.
• Les données structurées JSON-LD permettent de déclarer les images hors du DOM visible, mais exigent une maintenance rigoureuse.
• Le lazy loading natif HTML (loading="lazy") est mieux supporté par Googlebot que les solutions JS tierces.
• Les sites très visuels (e-commerce, édition, galeries) doivent arbitrer entre performance LCP et indexation Google Images.

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

Oui, partiellement. Les tests montrent que Googlebot indexe correctement les images avec l'attribut HTML5 loading="lazy" depuis fin 2020. Le problème se concentre sur les bibliothèques JS legacy (lozad.js, lazysizes, etc.) et les implémentations custom avec IntersectionObserver.

Certains audits Search Console révèlent des chutes brutales de trafic Google Images après migration vers un framework JS mal configuré. Mais dans d'autres cas, des milliers d'images lazy-loadées en JS pur sont indexées sans problème. La variable clé ? Le timing d'exécution JS lors du crawl. Si ton serveur répond lentement ou si Googlebot alloue peu de budget de rendu à ta page, le lazy load peut rater.

Quelles nuances faut-il apporter à cette déclaration ?

[A vérifier] La recommandation de Mueller date de plusieurs années. Depuis, Googlebot a progressé dans l'exécution JS et supporte nativement loading="lazy". Pourtant, Mueller continue de conseiller <noscript>, ce qui suggère que Google n'a pas totalement résolu le problème côté crawler.

Le vrai souci : Google ne garantit rien. Même avec loading="lazy" natif, certaines images peuvent ne jamais apparaître dans Google Images si le crawl est interrompu trop tôt. Les sites avec des milliers d'images produit ne peuvent pas se permettre ce risque. Résultat : beaucoup reviennent à un chargement eager pour les images critiques (hero, premières fiches produit) et ne lazy-loadent que le bas de page.

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

Si tu te fiches de Google Images comme source de trafic, cette déclaration est hors sujet. Pour un site SaaS B2B avec peu de contenu visuel, l'indexation des images n'est pas une priorité. Le lazy loading peut être poussé à fond sans arrière-pensée SEO.

Autre cas : les images décoratives, UI, ou purement fonctionnelles (icônes, boutons) n'ont aucune valeur SEO. Elles peuvent être lazy-loadées sans <noscript>. En revanche, pour un média éditorial qui tire 30 % de son trafic de Google Images, chaque photo doit être indexable, ce qui impose une stratégie beaucoup plus conservatrice.

Que faut-il faire concrètement pour sécuriser l'indexation ?

Commence par un audit des images critiques : produits, visuels éditoriaux, infographies. Si elles génèrent du trafic organique, elles doivent être indexables sans friction. Privilégie loading="lazy" natif HTML5 plutôt qu'une bibliothèque JS, sauf besoin avancé.

Pour les images déjà en JS lazy-load, ajoute une balise <noscript> avec un <img src="..." /> complet. Place-la juste après l'élément lazy-loadé. Teste le rendu côté client pour éviter que l'image ne se charge deux fois (certains navigateurs ignorent <noscript> même avec JS actif, d'autres non).

Les données structurées suffisent-elles à remplacer noscript ?

Oui, pour les images clés que tu veux absolument voir indexées. Un schema Product avec "image": ["url1.jpg", "url2.jpg"] déclare explicitement les visuels produit. Google peut les indexer même si elles n'apparaissent jamais dans le DOM visible.

Mais cette approche a ses limites. Si tu as 50 images dans un article de blog, les lister toutes dans un schema Article alourdit le JSON-LD sans garantir qu'elles seront toutes indexées. Réserve cette méthode aux images à forte valeur ajoutée : vignettes produit, images featured, visuels de catégories.

Comment vérifier que mes images sont bien indexées ?

Utilise une recherche site:tondomaine.com dans Google Images et filtre par page spécifique. Si une image critique n'apparaît pas après plusieurs semaines, c'est un signal d'alarme. Vérifie aussi le rapport Performance dans Search Console avec le filtre "Type de recherche : Image".

Crawl ton site avec Screaming Frog en mode JavaScript rendu activé. Compare les URLs d'images détectées en mode JS vs mode HTML brut. Si des images disparaissent en mode HTML, Googlebot risque de les manquer aussi, surtout si ton crawl budget est limité.

• Utilise loading="lazy" natif pour les images non critiques (below the fold)
• Ajoute une balise <noscript> avec <img> complet pour les visuels à forte valeur SEO
• Déclare les images produit/hero dans les données structurées JSON-LD (Product, Article, ImageObject)
• Vérifie l'indexation réelle via site: dans Google Images, pas seulement via l'outil d'inspection
• Crawle ton site en mode JS activé ET désactivé pour détecter les écarts de détection d'images
• Priorise le chargement eager pour les images above the fold ou génératrices de trafic organique