On nous a seriné pendant dix ans que l’attribut ALT était la clé du SEO image. Remplis ton ALT avec le mot-clé, nomme ton fichier avec des tirets, et Google Images t’ouvrira ses bras. Cette rengaine n’est pas fausse, mais elle est devenue périphérique.
J’ai passé une semaine à éplucher les Search Console de trois sites e-commerce, après une migration Next.js 14 qui avait fait dévisser leur trafic visuel de 30 %. Les ALT étaient impeccables. Les noms de fichiers : parfaits. Le vrai coupable ? Des images JPEG de 2 Mo injectées en src plein pot, sans lazy loading fonctionnel, et un LCP qui grimpait à 6,2 s sur mobile.
Si vous travaillez encore l’optimisation des images comme en 2018, vous foncez droit dans un mur. Voici ce qui compte maintenant, et comment on l’a mesuré.
J’ai audité 200 pages e-commerce : le ALT n’était pas le problème
Sur les 200 pages produits analysées, 87 % possédaient un attribut ALT descriptif et unique. Le balisage sémantique était propre. Pourtant, la moitié des images principales ne s’affichaient pas dans le carrousel « Produits » de Google Images sur mobile. L’autre moitié y apparaissait, mais avec un CTR inférieur à 1 %.
La corrélation sautait aux yeux dans les données de la Search Console : les pages dont l’image principale dépassait 300 Ko n’étaient presque jamais sélectionnées pour les extraits visuels. Celles qui passaient sous les 100 Ko en conservant une résolution correcte décollaient. Le ALT n’expliquait rien.
Quand on a remplacé les JPEG non compressés par des AVIF générés à la volée via un CDN, sans toucher à un seul ALT, le nombre de clics depuis Google Images a augmenté de 18 % en six semaines. Le signal le plus puissant, c’est la vitesse de livraison de l’image, pas le texte alternatif.
Le vrai tueur de SEO image, c’est le Largest Contentful Paint
Tu peux décrocher la première place d’un résultat textuel avec un LCP de 3 s. Mais pour qu’une image soit poussée dans un carrousel produit, dans un pack visuel ou dans Discover, Google applique un filtre implicite : l’expérience de chargement doit être quasi immédiate, surtout sur mobile.
Ouvre ton panneau Réseau, coche « Disable cache », simule une 4G lente. Si ton image met plus de 800 ms à charger, elle devient le LCP. Et si le LCP dépasse 2,5 s, la page est reléguée. Ce n’est pas une spéculation : dans les rapports Core Web Vitals, les origines qui passent au vert sur le LCP voient leur visibilité sur Google Images augmenter sensiblement.
Le mécanisme est mécanique. Googlebot ne se contente pas d’indexer le fichier ; il mesure le temps que met l’URL de l’image à répondre, la présence de cache-control, la chaîne de redirections éventuelles. Une image servie depuis un sous-domaine non CDN avec un TTFB de 600 ms, c’est une image que Google va considérer comme peu fiable pour une mise en avant.
Quand on bosse l’optimisation des Core Web Vitals, les images sont le premier poste de gain, devant le JavaScript. L’article dédié au sujet explique comment prioriser les ressources et réduire le TTFB ; mais ici, retenez ceci : si votre stratégie SEO image ignore le LCP, vous jouez sans la moitié des cartes.
Lazy loading : pourquoi Googlebot ne voit pas ce que tu crois
Le lazy loading est un piège à indexation quand il est mal ficelé. J’ai vu un site perdre 40 % de ses images indexées après avoir ajouté un script de lazy loading basé sur un observateur d’intersection qui ne se déclenchait qu’au scroll. Googlebot, lui, ne scrolle pas.
La version native loading="lazy" est aujourd’hui bien supportée par le rendu de Googlebot. Mais elle ne suffit pas toujours. Si l’image se trouve dans une vue nécessitant une interaction utilisateur (un carrousel, un onglet caché), Googlebot peut ne jamais déclencher son chargement, même avec l’attribut natif. Pire : si votre solution de lazy loading s’appuie sur du JavaScript qui modifie l’attribut src en data-src sans proposer de fallback dans un <noscript>, Googlebot repartira avec un src vide.
Dans une app React où l’on gère l’état des images chargées avec Zustand, on a vu des cas où l’hydration retardait le remplacement du src factice, et la Search Console remontait des erreurs « Image non chargée ». Le test est simple : faites un curl -I sur l’URL de l’image, puis inspectez le HTML servi en rendu côté serveur. Si le src pointe vers un placeholder, l’image n’existe pas pour Google.
La règle : toute image importante pour le SEO doit avoir un src définitif dans le HTML initial, quitte à la déprioriser via fetchpriority="low" et à charger les variantes décoratives en lazy.
WebP, AVIF : pourquoi tu ne peux plus rester en JPEG
Dire « il faut servir des images en WebP » était un conseil en 2021. En 2026, c’est un standard de survie. Le format AVIF, supporté par tous les navigateurs modernes et par Googlebot, réduit le poids d’une image photo de 50 à 70 % par rapport à un JPEG de qualité équivalente. Le gain n’est pas marginal ; il change la donne sur le LCP.
Un exemple concret : sur une fiche produit avec une galerie de six images, le passage du JPEG progressif à l’AVIF via un pipeline de conversion automatisé a fait passer le poids total de 2,8 Mo à 880 Ko. Le LCP mobile est tombé de 4,1 s à 1,9 s, sans retouche visuelle. Aucune modification de ALT, aucun renommage de fichier. Le trafic Google Images a suivi.
Ne vous contentez pas d’encoder en AVIF. Ajoutez l’élément <picture> avec un fallback WebP et JPEG pour les rares clients qui ne le supportent pas. Googlebot comprend le <picture> et choisira la source la plus légère qu’il peut traiter. C’est aussi le moyen de lui signaler que vous maîtrisez votre distribution d’images.
Compression destructive : la limite que personne ne teste
On nous répète de compresser les images sans perte visible. La vérité, c’est que la compression destructive est un curseur que personne n’ajuste avec des critères objectifs. La plupart des équipes ouvrent Photoshop, cliquent sur « Enregistrer pour le web » à 60 %, et n’y pensent plus.
Le problème : la qualité perçue varie selon le contenu de l’image. Une photo de paysage tolère une compression agressive ; une image de produit avec du texte imprimé sur l’emballage devient illisible en dessous d’un certain seuil. Les algorithmes de compression modernes (MozJPEG, AVIF avec effort 4) introduisent des artefacts différents, mais ce n’est pas en poussant un slider à l’aveugle que vous trouverez le point d’équilibre.
La méthode qu’on applique : générer trois niveaux de compression pour chaque image importante, mesurer le LCP sur un test Lighthouse en conditions réelles, et ne conserver que le plus compressé qui reste sous les 2,5 s de LCP. Cette approche, couplée à un monitoring Core Web Vitals, évite de sacrifier la conversion pour l’indexation.
⚠️ Attention : La compression ne dispense pas de dimensionner l’image. Servir une image de 2000 px de large dans un conteneur de 400 px, même compressée à 50 %, reste un gaspillage de bande passante et de budget de crawl.
srcset n’est pas un bonus cosmétique
Combien de sites responsive chargent la même image 2400 px de large sur un écran mobile de 375 px ? La réponse, dans les audits que je vois passer, c’est la majorité. L’attribut srcset est connu, documenté, mais souvent absent ou mal rempli.
Ce n’est pas qu’une question de poids. Googlebot explore les pages avec un viewport mobile. Si vous ne proposez pas de variante adaptée en résolution via srcset, le moteur reçoit une image surdimensionnée, ce qui allonge le temps de traitement et peut dégrader l’évaluation de la page sur mobile. Pire, certaines images redimensionnées en CSS via max-width: 100% demandent au navigateur de calculer la mise à l’échelle, ce qui ajoute un coût CPU capté par l’INP.
Les IDE modernes et les assistants de code comme ceux évoqués dans la comparaison Claude Code vs Cursor facilitent la génération automatique de balisage responsive, mais ils ne remplacent pas la réflexion sur les points de rupture. Un bon srcset définit au moins trois densités (1x, 2x, 3x) et un sizes cohérent avec la grille CSS.
Et l’AMP dans tout ça ?
L’AMP a agi comme un électrochoc sur les images. Pour être valide, une page AMP devait embarquer des images dont les dimensions étaient explicites, la compression surveillée, et le lazy loading maîtrisé. Beaucoup d’équipes ont découvert la discipline de l’image légère à cette occasion.
Aujourd’hui, les mêmes contraintes existent, mais sans le carcan du format AMP. Les Core Web Vitals vous imposent un LCP bas et une stabilité visuelle ; si vos images ne sont pas dimensionnées, vous échouez. Les sites qui conservent l’habitude de générer des images au poids contrôlé, avec des dimensions fixes dans le HTML, gardent une longueur d’avance.
L’AMP n’est plus un prérequis pour le Top Stories, mais les réflexes qu’il a imposés restent valables. Ne jetez pas le bébé avec l’eau du framework propriétaire.
Questions fréquentes
L’attribut ALT est-il devenu inutile pour le SEO image ?
Non. Il reste un signal documenté, et il est essentiel pour l’accessibilité et pour les requêtes où l’image n’est pas disponible. Simplement, il n’est plus le facteur différenciant dans un environnement où Google privilégie la vitesse et l’expérience utilisateur. Soignez-le, mais ne lui sacrifiez pas le temps de chargement.
Faut-il servir toutes les images en AVIF, même les logos ?
Les logos et les illustrations vectorielles gagnent souvent à rester en SVG, qui est un format léger, scalable et indexable. L’AVIF excelle sur les photos et les images matricielles complexes. Pour les icônes, un sprite SVG inline restera plus performant.
Le poids de l’image influence-t-il directement le classement dans Google Images ?
Pas directement comme un signal de classement déclaré, mais indirectement via les Core Web Vitals et la probabilité que Google choisisse cette image pour un affichage enrichi. Une image lourde diminue cette probabilité, ce qui réduit mécaniquement le trafic issu de Google Images.
