Faut-il vraiment utiliser picture et srcset pour optimiser les images en responsive ?

Pourquoi Google insiste-t-il sur picture et srcset ?

Ces deux mécanismes HTML permettent de servir différentes versions d'une image selon le contexte : taille d'écran, résolution, format supporté. Le navigateur fait le tri et charge l'image la plus pertinente. Google pousse cette approche car elle améliore la performance (moins de data gaspillée) et l'expérience utilisateur.

Mais voilà le twist : Google n'indexe pas toutes les variantes. Il se rabat sur l'image de fallback, celle définie dans l'attribut src de l'élément <img> ou dans la source par défaut de <picture>. C'est cette image qui apparaîtra dans Google Images, pas les déclinaisons responsive.

Quelle différence entre picture et srcset ?

srcset fonctionne sur l'élément <img> : on liste plusieurs URLs avec leurs descripteurs (largeur en w ou densité de pixels en x). Le navigateur choisit selon la taille de viewport et la densité d'écran. Syntaxe simple, mais limitée aux images au même ratio.

picture offre plus de contrôle : on définit des <source> avec des media queries, permettant de changer complètement l'image (cadrage différent, format WebP vs JPEG). L'élément <img> à l'intérieur sert de fallback. Plus puissant, mais plus verbeux.

Que se passe-t-il si je ne mets pas de fallback clair ?

Google risque de ne pas indexer l'image du tout, ou de tomber sur une version sous-optimale. Le fallback est votre seul point de contact avec le moteur. Si vous placez une miniature 300px en fallback et les vraies images en srcset, Google ne verra que la miniature.

• picture et srcset sont la méthode officielle pour le responsive, pas les media queries CSS ou le lazy loading bricolé
• Le navigateur choisit l'image, Google indexe le fallback uniquement
• Le fallback doit être une version de qualité suffisante pour l'indexation (pas une miniature ou un placeholder)
• Les formats WebP/AVIF peuvent être servis via <source>, avec un JPEG/PNG en fallback pour la compatibilité

Cette déclaration reflète-t-elle vraiment le comportement de Googlebot ?

Oui, et c'est confirmé par les observations terrain. Googlebot Desktop se comporte comme Chrome : il interprète srcset et picture, mais pour l'indexation dans Google Images, c'est bien l'URL du fallback qui remonte. Les variantes srcset ne sont pas explorées individuellement, elles ne génèrent pas de résultats distincts dans la recherche d'images.

Par contre — et c'est rarement dit — Googlebot analyse parfois les dimensions des images déclarées dans srcset pour enrichir les métadonnées. Mais ça reste accessoire. L'essentiel : votre image de référence SEO, c'est le fallback.

Quelles erreurs courantes découlent de cette logique ?

Beaucoup de devs placent une image 1x (basse résolution) en fallback et réservent les images 2x/3x au srcset. Résultat : Google indexe une image floue. Autre piège : utiliser un SVG ou un placeholder base64 comme fallback "universel", en pensant que les sources picture prennent le relais. Google ne voit que le placeholder.

Certains oublient aussi que le fallback doit pointer vers une URL absolue et crawlable. Si votre fallback est en data-URI ou renvoie une 404, vous perdez l'indexation de l'image.

Dans quels cas srcset ou picture posent-ils problème ?

Quand le CMS génère automatiquement des srcset avec des URLs aléatoires ou dynamiques (paramètres de resize, tokens éphémères). Google peut alors indexer une URL de fallback qui ne correspond à aucune image pérenne, ou qui change à chaque génération de page.

Autre cas : les sites qui utilisent picture pour de l'art direction (image différente selon le viewport). Le fallback peut être une version desktop, alors que la majorité du trafic vient du mobile avec une composition totalement différente. Google indexe le desktop, l'utilisateur mobile voit autre chose. [À vérifier] si Google commence à crawler les variantes mobiles de picture séparément avec le mobile-first indexing — rien d'officiel là-dessus pour l'instant.

Comment implémenter picture et srcset sans perdre le contrôle SEO ?

Première règle : choisissez votre fallback comme si c'était votre seule image. Résolution correcte (au minimum 1200px de large pour les images principales), poids optimisé, nom de fichier descriptif, attribut alt renseigné. Cette image sera celle que Google indexe, celle qui apparaîtra dans les résultats de recherche d'images.

Ensuite, ajoutez vos variantes srcset pour les écrans Retina (2x, 3x) ou les largeurs différentes (sizes attribute). Utilisez picture si vous avez besoin de servir du WebP/AVIF avec un fallback JPEG, ou si vous faites de l'art direction (images différentes selon le contexte).

Testez avec l'outil d'inspection d'URL de la Search Console : vérifiez que Google détecte bien l'image, que l'URL indexée correspond au fallback, et que les dimensions remontées sont cohérentes. Si l'image n'apparaît pas, c'est souvent un problème de fallback invisible ou inaccessible.

Quelles erreurs techniques éviter absolument ?

Ne mettez jamais de lazy loading sur l'image de fallback si elle est above the fold ou stratégique pour le SEO. Google peut la manquer lors du premier crawl. Si vous lazy-loadez, assurez-vous que le fallback est chargé en priorité (attribut loading="eager" ou absence de lazy).

Évitez les fallbacks en data-URI ou SVG générique. Google les ignore ou les considère comme non pertinents. Même problème avec les placeholders flous (blur-up technique) si le vrai fallback n'est pas une URL valide.

Attention aux redirections sur les URLs d'images. Si votre fallback redirige (301/302), Google peut perdre le fil ou indexer l'URL intermédiaire. Les images doivent répondre en 200 direct.

Que faut-il vérifier sur un site existant ?

• Audit des balises <img>, <picture> et attributs srcset : le fallback est-il toujours présent et de qualité ?
• Comparaison entre ce que voit le navigateur (DevTools) et ce que voit Googlebot (Search Console, outil d'inspection)
• Test de l'indexation dans Google Images : les images stratégiques apparaissent-elles avec la bonne URL et les bonnes dimensions ?
• Vérification des logs serveur : les images de fallback sont-elles bien crawlées régulièrement par Googlebot-Image ?
• Analyse de la performance : les variantes srcset réduisent-elles réellement le poids de page sur mobile sans dégrader l'indexation ?