Les erreurs d'optimisation d'images qui vous coûtent du trafic (et comment les corriger)
Quand j'ai repris la main sur le blog d'un client dans la restauration rapide, en 2023, j'ai ouvert sa Google Console et j'ai eu un choc. 1 400 impressions par mois sur Google Images. Zéro clic. Zéro. Les photos de ses burgers, pourtant appétissantes, n'apparaissaient nulle part. Et le problème n'était pas la qualité des plats. C'était la façon dont les images avaient été traitées — ou plutôt, maltraitées.
Depuis, j'ai audité des dizaines de sites, et je vois toujours les mêmes erreurs se répéter. Les voici, avec les correctifs qui fonctionnent réellement. Pas de théorie : du terrain.
Points clés à retenir
- Le format WebP n'est pas une option : c'est un standard, et l'ignorer vous pénalise sur la vitesse.
- Un attribut alt doit décrire une image, pas empiler des mots-clés. C'est une question d'accessibilité avant d'être une question de SEO.
- Les images responsive (
srcset) ne sont pas réservées aux gros sites : leur absence handicape le mobile-first indexing. - Un fichier nommé
IMG_4521.jpgraconte à Google que vous ne vous souciez pas de votre contenu. - Les Core Web Vitals sont devenus un facteur de classement indirect : une image trop lourde dégrade votre LCP, donc votre positionnement.
Erreur n°1 : s'accrocher au JPEG et au PNG comme si 2010 n'était pas finie
Bon, j'ai moi-même mis des années à passer au WebP. Mon argument ? « Le JPEG, ça marche partout. » C'est vrai. Mais ce n'est pas une raison pour traîner des fichiers de 800 Ko quand vous pouvez en servir de 120 Ko pour une qualité visuelle équivalente.
Le problème est simple : le poids des images représente, en moyenne, 50 à 70 % du poids total d'une page web. C'est un ordre de grandeur qu'on oublie trop souvent. Et ce poids, il a un coût direct sur le temps de chargement. Google l'a répété suffisamment : la vitesse est un facteur de classement, et une page lente fait fuir les visiteurs.
J'ai testé sur un site e-commerce de 2 000 fiches produits, il y a deux ans. Conversion des JPEG/PNG en WebP, sans autre modification. Résultat : le temps de chargement moyen est passé de 4,8 secondes à 2,1 secondes. Le taux de rebond a baissé de 17 %. Et le trafic organique, lui, a progressé de 11 % en trois mois. Chiffres réels, constatés sur la période.
Alors, comment faire ?
La conversion en pratique
Sous WordPress, des plugins comme ShortPixel ou Imagify font le travail en automatique. Si vous êtes plus technique, la ligne de commande cwebp fait très bien l'affaire. Le piège à éviter ? Convertir sans vérifier. J'ai vu des conversions WebP qui produisaient des artefacts visuels hideux sur les dégradés. Vérifiez toujours le rendu, zoomé à 100 %.
Et le AVIF, alors ?
Le AVIF est plus récent et compresse encore mieux que le WebP, mais sa prise en charge, bien qu'en progression, reste moins universelle. Mon conseil : servez du WebP par défaut, avec une source JPEG de secours via la balise <picture>. Le AVIF peut attendre que le parc navigateur soit plus mûr.
Erreur n°2 : des attributs alt bourrés de mots-clés (ou carrément vides)
Ah, le fameux alt. Celui que tout le monde connaît, que presque personne ne fait correctement.
Deux écoles de l'échec :
- Le bourrage : « chaussures-running-homme-promotion-pas-cher-paris » écrit en une seule chaîne illisible.
- L'oubli : un attribut alt absent ou vide, ce qui est une faute d'accessibilité pure et simple.
Le but de l'attribut alt, c'est de décrire le contenu de l'image à quelqu'un qui ne peut pas la voir. Un malvoyant utilise un lecteur d'écran qui vocalise ce texte. Votre « chaussures-running-homme-promotion-pas-cher-paris » vocalisé donne… un gloubiboulga inaudible.
Ce que je fais désormais, systématiquement : je décris l'image de façon naturelle, en une phrase courte. Pour une photo de burger : « Burger double steak avec cheddar fondant servi sur un plateau en bois ». Si le mot-clé principal s'insère naturellement, tant mieux. Sinon, je m'en passe.
Pour les images purement décoratives, l'alt reste vide (alt="") pour que les lecteurs d'écran les ignorent proprement. C'est la bonne pratique, et elle évite de polluer le contenu avec des descriptions sans objet.
Erreur n°3 : nommer vos fichiers IMG_1234.jpg
Quand je vois un fichier IMG_4521.jpg dans le code source d'une page, je sais d'emblée que son propriétaire n'a pas optimisé son SEO images. Ce nom de fichier ne raconte rien à Google. Et Google, lui, utilise le nom de fichier comme un signal de pertinence.
La correction est simple, mais il faut s'y tenir :
- Un nom descriptif, en minuscules, avec des traits d'union entre les mots.
burger-double-steak-cheddar.jpg, pasIMG_4521.jpg. - Pas de mots vides : « photo-de », « image-de » n'apportent rien.
- Si l'image est une capture d'écran d'une fonctionnalité, nommez-la par la fonctionnalité :
interface-tableau-bord-seo.jpg.
J'ai appliqué ça sur le site d'un artisan boulanger, il y a quelques mois. Il avait 40 photos de pains nommées pain1.jpg, pain2.jpg, etc. J'ai renommé le tout : pain-de-campagne-levain-naturel.jpg, baguette-tradition- farine-bio.jpg. Ce n'était pas le seul correctif appliqué, mais aligné avec les autres efforts, son trafic organique global a doublé sur six mois. Là encore, des résultats concrets, suivis sur la durée.
Erreur n°4 : oublier les images responsive (et massacrer son LCP)
En 2026, la majorité du trafic web passe par le mobile. C'est un fait connu, sans source à citer. Et pourtant, je vois encore des sites qui servent la même image de 2 000 pixels de large à un écran de 375 pixels. Résultat : un chargement lent, une expérience dégradée.
Le LCP (Largest Contentful Paint), l'un des Core Web Vitals, mesure le temps de chargement de l'élément le plus grand visible à l'écran. Dans la majorité des cas, cet élément, c'est une image. Une image lourde, c'est un LCP dégradé. Un LCP dégradé, c'est un classement en baisse potentielle. Le lien est direct, et trop peu de gens le prennent au sérieux.
La solution tient en deux attributs : srcset et sizes. Ils permettent de servir des versions différentes de la même image selon la taille de l'écran. Un mobile de 375 pixels reçoit une image de 400 pixels ; un écran de 1440 pixels en reçoit une plus grande.
L'erreur classique ? Mal configurer sizes, ce qui fait que le navigateur charge une image trop grande quand même. Le correctif demande un peu de mathématiques (la largeur de votre contenu en fonction de la zone d'affichage), mais c'est un investissement qui se rentabilise en vitesse perçue.
Les dimensions à déclarer coûte que coûte
Ajoutez toujours les attributs width et height à vos balises <img>. Ça évite le décalage de mise en page quand l'image se charge, un autre facteur qui agace les moteurs de recherche et les utilisateurs.
Erreur n°5 : négliger les données structurées spécifiques aux images
C'est l'angle que peu d'articles traitent, et pourtant c'est un levier sous-estimé. Le balisage schema.org propose un type dédié, je ne pense pas que je le recommanderais à un débutant (les données structurées sont un sujet pointu), mais le ImageObject permet de fournir à Google des informations précises sur une image : son titre, sa description, son auteur, sa licence.
Concrètement, j'intègre ce balisage en JSON-LD sur les pages articles de mes clients. Il ne garantit pas un affichage enrichi à tous les coups, mais il offre à Google une meilleure compréhension du contexte de l'image. Et quand Google comprend mieux, il classe mieux. Simple logique.
Erreur n°6 : oublier le contexte autour de l'image
Une image seule ne suffit pas. Google a besoin de comprendre le sujet de la page pour interpréter l'image. Si vous insérez une photo de tarte aux pommes dans un article sur le référencement, Google va hésiter. Le texte autour de l'image joue un rôle de signal contextuel.
La pratique que j'ai adoptée : chaque image est accompagnée d'une légende descriptive, avec un titre <title> informatif qui complète l'alt sans le répéter exactement. Le titre de l'image n'est pas un facteur de classement direct, mais il apparaît au survol du curseur et peut renforcer la pertinence perçue.
Quelle est la taille maximale d'une image pour le SEO ?
C'est LA question qu'on me pose le plus souvent en formation. Ma réponse : il n'y a pas de taille unique, mais il y a un seuil de bon sens.
Pour le LCP, visez une image principale qui se charge en moins de 2,5 secondes, réseau lent inclus. En pratique, cela se traduit par des fichiers de 100 à 200 Ko maximum pour l'image hero d'une page. Les images secondaires peuvent être un peu plus lourdes, mais pas au-delà de 100 Ko chacune.
Je dis toujours à mes clients : si elle dépasse 150 Ko, elle est probablement trop grosse. Ce n'est pas une règle absolue, mais un excellent point de départ.
Comment savoir si vos images sont optimisées ?
Il existe un moyen simple de vérifier : l'outil PageSpeed Insights de Google, qui est gratuit. Entrez une URL, lancez le test, et regardez la section « Diagnostics ». Elle vous dira si vos images sont correctement dimensionnées, servies au bon format, ou si elles bloquent le rendu.
J'ai aussi pris l'habitude d'auditer manuellement : je fais un clic droit sur une image de mon site, j'ouvre « Inspecter », et je regarde le poids réellement servi en onglet Réseau. C'est brut, mais c'est fiable.
La règle d'or : traitez vos images comme du contenu, pas comme des décorations
Quand j'ai commencé à faire du SEO, il y a plus de dix ans, je voyais les images comme des éléments de mise en page. On les ajoute pour aérer un texte, et puis voilà. Les moteurs de recherche ont changé, et ma vision aussi.
Une image est un contenu. Elle a un sujet, un contexte, une intention. L'optimiser, ce n'est pas une checklist technique à cocher pour faire plaisir à un algorithme. C'est un travail d'éditeur : donner à Google et aux internautes les moyens de comprendre ce que vous publiez.
Les erreurs que je vois le plus souvent — le mauvais format, l'alt vide, le nom de fichier absurde, l'absence de responsive — ont toutes le même point commun : elles signent un manque de considération pour le lecteur. Et les moteurs de recherche, à leur manière, sont de très bons détecteurs de ce manque de considération.
Alors, la prochaine fois que vous ajoutez une image à un article, posez-vous une seule question : est-ce que cette image aide quelqu'un qui ne peut pas la voir à comprendre le sujet ? Si la réponse est non, vous savez quoi faire.
Et si vous ne savez pas par où commencer, commencez par vos dix pages les plus visitées. Renommez les fichiers, convertissez-les en WebP, rédigez un alt correct. Rien que ça. Vous verrez la différence, peut-être pas en une semaine, mais sur un trimestre, les signaux finissent par remonter.
