Pourquoi Google ignore-t-il vos images si elles sont dans data-src au lieu de src ?

Quelle est la différence technique entre src et data-src pour Google ?

L'attribut src est le standard HTML qui indique au navigateur — et à Googlebot — où charger une ressource image. C'est ce que le crawler lit directement dans le DOM. L'attribut data-src, en revanche, est un attribut personnalisé (data-* attribute) couramment utilisé dans les solutions de lazy loading : l'image n'est pas chargée immédiatement, mais seulement quand elle devient visible dans le viewport.

Le problème ? Google ne lit pas data-src nativement. Si votre JavaScript ne bascule jamais l'URL de data-src vers src, ou si le rendu JavaScript échoue, Googlebot voit un élément <img data-src="..." src=""> avec un src vide ou absent. Résultat : aucune image indexée, aucune chance d'apparaître dans Google Images, et une perte sèche de trafic SEO.

Pourquoi tant de sites se plantent encore sur ce point ?

Parce que les bibliothèques de lazy loading (LazyLoad, Lozad, etc.) et certains CMS (Wordpress avec plugins mal configurés, Shopify avec thèmes tiers) injectent data-src par défaut sans toujours garantir le passage à src. Les développeurs testent en mode desktop avec JavaScript activé, tout fonctionne visuellement, mais ils ne vérifient jamais le rendu côté Googlebot.

Or Googlebot exécute bien JavaScript, mais avec des limitations : timeout de 5 secondes pour le rendu, pas de scroll simulé (donc pas de déclenchement des événements IntersectionObserver pour certaines images), et des ressources bloquées qui peuvent empêcher le JS de s'exécuter correctement. Si votre script ne passe pas data-src en src dans ce délai, l'image est perdue.

Google Search Console permet-il de détecter ce problème ?

Oui, mais pas directement. L'outil Inspection d'URL affiche le rendu HTML final tel que vu par Google. Si vous inspectez une page et que les balises <img> n'ont pas de src renseigné, c'est le signal. Vous pouvez aussi croiser avec le rapport Couverture > Images : si des pages avec beaucoup d'images affichent 0 ou très peu d'images indexées, c'est probablement data-src qui coince.

Le problème, c'est que GSC ne fait pas de détection automatique ni d'alerte spécifique « images en data-src non indexées ». Il faut auditer manuellement, URL par URL, ou passer par un crawler tiers (Screaming Frog, OnCrawl, Botify) qui simule le rendu JavaScript et compare les attributs src/data-src.

• src est l'attribut standard que Google suit pour indexer les images
• data-src est invisible pour Googlebot si aucun JavaScript ne le bascule vers src
• Le lazy loading natif (loading="lazy") fonctionne avec src, pas avec data-src
• Google Search Console permet de vérifier le rendu final, mais ne détecte pas automatiquement ce problème
• Un audit technique avec crawler JS est indispensable pour cartographier les images perdues

Cette déclaration est-elle cohérente avec les pratiques observées sur le terrain ?

Totalement. On observe depuis des années que les sites qui implémentent du lazy loading via data-src sans fallback perdent l'indexation de leurs images. Les tests en production confirment : un site e-commerce avec 10 000 fiches produits et lazy loading mal configuré peut avoir 80 % de ses images absentes de Google Images. Ce n'est pas une subtilité théorique, c'est un gouffre de trafic.

Ce qui est moins dit, c'est que le lazy loading natif (attribut loading="lazy") résout ce problème : il fonctionne avec src, Google l'interprète correctement, et aucune manipulation JavaScript n'est nécessaire. Depuis 2019, c'est supporté par Chrome, Firefox, Edge, Safari — et surtout par Googlebot. Si vous utilisez encore des scripts tiers pour du lazy loading, c'est le moment de migrer vers le standard HTML.

Quelles nuances faut-il apporter à cette affirmation de Google ?

Première nuance : Google peut indexer une image dont l'URL apparaît ailleurs dans le code (CSS background, script JSON-LD, balise <link rel="preload">), mais c'est marginal et non garanti. La seule méthode fiable reste src dans <img>. Ne comptez pas sur des détours.

Deuxième nuance : même si votre JavaScript bascule correctement data-src vers src, si ce script est bloqué par robots.txt, chargé en différé après le timeout de rendu, ou dépend d'une bibliothèque externe qui plante, Google verra le DOM initial avec data-src. Autrement dit, [À vérifier] que votre chaîne de rendu JavaScript est robuste et que tous les fichiers critiques sont crawlables.

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

Si vos images n'ont aucun intérêt SEO (icônes décoratives, sprites CSS, illustrations purement UX sans valeur de recherche), alors data-src ou même l'absence totale de balise <img> n'a pas d'impact. Google ne va pas chercher à indexer des PNG de flèches ou de boutons.

En revanche, pour tout contenu qui peut générer du trafic via Google Images — photos produits, infographies, visuels éditoriaux, portfolios, recettes, avant/après — la règle est absolue : src obligatoire, data-src interdit sans bascule garantie. Et là, c'est critique.

Que faut-il faire concrètement pour s'assurer que Google indexe vos images ?

D'abord, auditer l'existant. Crawlez votre site avec Screaming Frog en mode JavaScript activé (ou OnCrawl, Botify, Sitebulb) et extrayez toutes les balises <img>. Filtrez celles qui ont un data-src renseigné mais un src vide ou absent. C'est votre liste noire.

Ensuite, vérifiez le rendu réel côté Google : utilisez l'outil Inspection d'URL dans Search Console sur quelques pages types (fiche produit, article de blog, page galerie). Regardez le HTML rendu et cherchez les balises <img> : si src est vide, vous avez un problème. Croisez avec le rapport Images indexées : si le nombre d'images indexées est anormalement bas, c'est confirmé.

Quelles erreurs éviter lors de la mise en conformité ?

Erreur n°1 : ajouter src="" vide en pensant que c'est mieux que rien. Non. Un src vide déclenche une requête HTTP vers la page elle-même, ce qui pollue vos logs, augmente le crawl budget gaspillé, et n'indexe rien. Si vous ne pouvez pas renseigner src tout de suite, utilisez un placeholder bas poids (data:image SVG inline, ou image 1x1 px) en attendant le lazy load.

Erreur n°2 : bloquer les scripts de lazy loading dans robots.txt. Si votre JS est bloqué, Google ne peut pas l'exécuter, donc data-src ne bascule jamais vers src. Vérifiez que tous les fichiers .js critiques pour le rendu des images sont crawlables.

Comment vérifier que votre implémentation fonctionne après correction ?

Utilisez l'outil Test d'optimisation mobile ou PageSpeed Insights, qui exécutent JavaScript et affichent le DOM final. Inspectez les balises <img> dans la capture d'écran et le HTML rendu : src doit être renseigné avec l'URL finale de l'image. Si c'est bon, relancez une inspection d'URL dans GSC et demandez une réindexation.

Ensuite, surveillez le rapport Images indexées dans GSC sur 4-6 semaines. Vous devriez voir une courbe croissante du nombre d'images découvertes et indexées. Si ça stagne, c'est qu'il reste des pages non corrigées ou que votre sitemap d'images n'est pas soumis. Croisez avec Google Analytics / GA4 : le trafic provenant de Google Images (source/medium = google/organic, landing page = /images ou image search) doit augmenter.

• Crawler le site en mode JavaScript pour détecter les <img> avec data-src mais sans src
• Vérifier le rendu Google via Inspection d'URL (Search Console) sur des pages types
• Migrer vers le lazy loading natif loading="lazy" avec src renseigné
• Supprimer ou corriger les scripts tiers qui injectent data-src sans fallback
• S'assurer que les fichiers JavaScript critiques ne sont pas bloqués par robots.txt
• Soumettre un sitemap d'images avec les URL correctes (référençant les src, pas les data-src)