Une page d'article avec cinq images qui pèsent 2,4 Mo au total, ça vous parle ? Moi si. C'était mon propre blog, il y a quelques années, et je trouvais ça normal : « les photos doivent être belles, donc lourdes ». Jusqu'au jour où j'ai regardé ma fiche PageSpeed et vu un LCP à 4,8 secondes sur mobile. Quatre secondes et demie pour afficher une image de couverture. Google n'avait même pas besoin de me pénaliser : mes visiteurs partaient avant.
Le pire, c'est que je passais des heures sur mes balises title et mes maillages internes, en laissant tranquille le poste qui pesait le plus lourd dans la balance. Optimiser ses images pour le référencement naturel, ce n'est pas un chapitre annexe du SEO. C'est souvent le premier chantier à ouvrir, et celui qui rapporte le plus vite.
Points clés à retenir
- Une image pèse en moyenne plusieurs centaines de Ko quand 100 à 200 Ko suffisent largement pour un visuel d'article.
- Le nom du fichier et la balise alt restent les deux signaux les plus simples à corriger, et les plus souvent bâclés.
- Le lazy loading mal placé peut empêcher l'image principale d'être chargée assez tôt, donc indexée moins vite.
- Les formats WebP et AVIF divisent le poids par deux à quatre par rapport au JPEG, à qualité visuelle comparable.
- Un balisage schema.org bien posé change la donne sur Google Images et dans les résultats enrichis.
Pourquoi vos images pèsent plus lourd dans votre SEO que vous ne le pensez
Je vais être direct : la majorité des sites que j'ai audités depuis deux ans ont le même profil. Le HTML est propre, le contenu correct, et pourtant la page met trois secondes à s'afficher. Dans neuf cas sur dix, le coupable est du côté des médias. Une photo prise au téléphone sort à 4 000 pixels de large et 3 Mo. Personne n'a besoin de ça dans un article.
Le lien direct entre poids des images et Core Web Vitals
Google mesure la vitesse d'affichage via ce qu'on appelle le LCP (Largest Contentful Paint) : le temps que met le plus gros élément visible à s'afficher. Sur un blog, cet élément est très souvent une image. Si elle met quatre secondes à arriver, votre LCP est mauvais, point. Et un mauvais LCP sur mobile, ça se traduit par des positions qui glissent doucement vers le bas.
Sur mon propre site, passer mes images de 2,4 Mo à 620 Ko au total m'a fait gagner 2,1 secondes de LCP sur mobile. Aucune autre modification. Même hébergement, même thème.
Le trafic Google Images, ce flux qu'on oublie de compter
Une part non négligeable des recherches affiche des vignettes images en plus des liens classiques. Pour certains sujets (recettes, bricolage, décoration, tutoriels), c'est même le point d'entrée principal. Et un visiteur qui arrive par une image n'est pas un visiteur au rabais : il a trouvé exactement le visuel qu'il cherchait.
Le problème ? Les robots ne voient pas votre photo. Ils lisent son nom de fichier, son attribut alt, le texte qui l'entoure, sa légende. Tout ce que vous ne leur donnez pas, ils l'inventent mal ou l'ignorent.
Nom de fichier et balise alt : les deux fondations
Avouons-le, on a tous déjà exporté une image qui s'appelait IMG_20260412_183244.jpg. Moi le premier, pendant des mois. Sauf que ce nom ne dit rien à personne, et surtout pas au moteur.
Comment nommer correctement un fichier image
La règle est bête : décrivez ce qu'on voit, en minuscules, avec des tirets. Pas d'accents, pas d'espaces, pas de majuscules.
optimisation-images-seo.webp— correctIMG_20260412_183244.jpg— inutilephoto-site-web-1.jpg— trop vague, le « 1 » ne veut rien direcapture-ecran-pagespeed-mobile-lcp.png— long, mais précis, et c'est très bien
Un détail que personne ne mentionne : si vous changez le nom d'une image déjà indexée, l'ancienne URL peut rester dans l'index un moment. Prévoyez une redirection 301 vers la nouvelle adresse, sinon vous perdez le bénéfice.
Rédiger une balise alt qui sert vraiment
La balise alt a deux publics : les lecteurs d'écran pour les personnes malvoyantes, et les robots. Le piège, c'est de vouloir caser le mot-clé coûte que coûte. Une alt du type « optimisation images SEO optimisation images référencement » est une faute professionnelle. Ça ne décrit rien et ça sent la manipulation à plein nez.
Ma méthode : j'écris la phrase que je dirais à quelqu'un au téléphone pour décrire l'image. « Capture d'écran de PageSpeed Insights montrant un LCP de 4,8 secondes sur mobile. » Voilà. Le mot-clé vient naturellement si le sujet est là.
Et n'oubliez pas : une image purement décorative (une icône de séparateur, un motif de fond) doit avoir un alt vide (alt=""), pas un alt bourré de mots. Un alt vide indique au lecteur d'écran de l'ignorer, ce qui est exactement l'effet voulu.
Formats et compression : les seuils concrets à viser
Ici, je vais être plus précis que ce qu'on lit d'habitude, parce que « compressez vos images » ne veut rien dire en pratique.
Quel format choisir en 2026
Le JPEG reste utile pour les photos, mais il n'est plus le meilleur choix par défaut. Le WebP est supporté partout depuis des années et pèse 25 à 35 % de moins qu'un JPEG équivalent. L'AVIF va encore plus loin sur les photos, mais l'encodage est plus lent, donc à réserver aux visuels où le gain compte.
| Format | Idéal pour | Poids relatif | Transparence |
|---|---|---|---|
| JPEG | Photos, compatibilité maximale | Référence | Non |
| WebP | La plupart des visuels web | −30 % environ | Oui |
| AVIF | Photos haute qualité | −50 % environ | Oui |
| PNG | Captures d'écran nettes, logos | Souvent très lourd | Oui |
| SVG | Icônes, illustrations vectorielles | Quelques Ko | Oui |
Le poids cible par image
Voici mes repères, ceux que j'applique sur mes propres pages :
- Vignette ou icône : sous 30 Ko
- Image d'illustration dans un article : 100 à 150 Ko
- Image de couverture pleine largeur : jusqu'à 200 Ko, guère plus
- Photo de produit en galerie : 80 à 120 Ko par visuel
Au-delà de 250 Ko pour une image de contenu, posez-vous la question. Et pour les dimensions, inutile d'exporter en 3 000 px de large une image qui s'affichera sur 800 px. Redimensionnez avant de compresser, pas l'inverse.
srcset et sizes : servir la bonne résolution à chaque appareil
Personne n'en parle dans les articles classiques, et c'est dommage. Un mobile n'a pas besoin de la même résolution qu'un écran 4K. Les attributs srcset et sizes permettent au navigateur de choisir la meilleure version selon la taille de l'écran.
Sur un de mes projets, ajouter simplement trois déclinaisons (400, 800 et 1600 px) avec srcset a fait chuter le poids transféré sur mobile de 38 %. Sans toucher à la qualité perçue.
Le lazy loading et son piège
Le loading="lazy" est devenu réflexe. On le colle sur toutes les images et on se dit que c'est réglé. Sauf que mal placé, il fait plus de dégâts que de bien.
Quand ne surtout pas activer le lazy loading
L'image principale en haut de page — celle qu'on voit sans scroller — ne doit jamais être en lazy loading. Pourquoi ? Parce que le navigateur attend de savoir si elle entre dans le viewport pour commencer à la charger. Sur une connexion lente, ça retarde son affichage. Résultat : un LCP qui s'envole, et parfois une image que le robot met plus de temps à repérer.
Ma règle simple : lazy loading uniquement sous la ligne de flottaison. Au-dessus, chargement immédiat, et si possible avec fetchpriority="high" sur l'image de tête pour dire au navigateur « celle-là d'abord ».
Comment vérifier que vos images sont bien indexées
Deux réflexes, tous les deux gratuits. D'abord la recherche par image dans Google : tapez site:votredomaine.com dans l'onglet Images, vous verrez ce qui est indexé. Ensuite, la Search Console, section « Indexation des pages » : filtrez sur les URL qui se terminent par .jpg, .webp ou .png. Celles qui ressortent en « Explorée, non indexée » méritent un coup d'œil.
J'ai découvert comme ça que mon sitemap ne listait aucune image. Un plugin mal configuré depuis des mois.
Balisage structuré et sitemap images : le levier que presque personne n'active
Voilà la partie qui manque à presque tous les articles sur le sujet, et c'est pourtant là qu'il y a du terrain à prendre.
Le balisage ImageObject
Les données structurées schema.org permettent de décrire précisément une image : son URL, ses dimensions, son auteur, son crédit. Le type ImageObject se déclare en JSON-LD dans la page. L'intérêt est double : une meilleure compréhension par le moteur, et des chances accrues d'apparaître dans les résultats enrichis.
Pour une recette, un produit ou un article avec une image forte, déclarer explicitement l'image dans le schéma correspondant (Recipe, Product, Article) est un vrai plus. C'est technique, oui. Mais c'est dix minutes de travail pour un bénéfice durable.
Ajouter les images au sitemap
Un sitemap XML classique liste des pages, pas des images. Pourtant, la norme prévoit une extension image:image avec image:loc pour déclarer chaque visuel. Le faire accélère la découverte des images, surtout sur un site récent ou peu crawlé.
Mon conseil : vérifiez votre sitemap généré. S'il ne contient aucune balise image, corrigez votre plugin ou votre générateur. Ensuite seulement, soumettez-le à nouveau dans la Search Console.
Le contexte textuel : ce que les robots lisent autour de votre image
Une image isolée, sans texte adjacent, c'est une photo muette. Le moteur s'appuie sur ce qui l'entoure pour comprendre de quoi elle parle. Le titre juste au-dessus, le paragraphe voisin, la légende en dessous : tout compte.
Concrètement, une image de plat cuisiné placée dans un paragraphe qui parle de « tarte au citron meringuée » sera mieux comprise qu'une même image perdue en bas de page. La légende, souvent oubliée, est un signal utile et lisible : « Tarte au citron meringuée, cuisson 35 minutes à 180 °C » vaut mieux qu'un simple « photo 3 ».
Dernier point : nommez vos liens vers les images de façon descriptive quand c'est pertinent. Un lien « voir le tutoriel complet » reste préférable à un lien « cliquez ici », et ça vaut aussi pour les liens qui pointent vers un visuel.
La checklist que j'applique à chaque audit
Bon, un peu d'ordre pour finir, parce que tout ça mis bout à bout devient vite flou.
- Lister toutes les images d'une page représentative avec leurs dimensions et leur poids (outil : onglet Réseau du navigateur, filtre Img).
- Repérer celles qui dépassent 200 Ko, et les traiter en priorité.
- Vérifier les noms de fichiers : au moins une bonne moitié est à renommer, en général.
- Relire chaque balise alt, en la testant à voix haute — si elle sonne bizarre, elle l'est.
- Contrôler le lazy loading : rien au-dessus de la ligne de flottaison.
- Convertir les JPEG en WebP, mesurer le gain, garder le JPEG d'origine en solution de repli si votre audience est ancienne.
- Déclarer les images dans le sitemap et vérifier leur indexation via la Search Console.
Sur les cinq derniers sites que j'ai repris, cette séquence a produit un gain de vitesse visible sur mobile en moins d'une semaine de travail, à chaque fois. Sans jamais toucher au contenu.
Ce qui me frappe, c'est à quel point on sous-estime encore cette partie du métier. On passe des heures à peaufiner une méta-description de 150 caractères, et on laisse passer des images qui pèsent dix fois trop lourd. La prochaine fois que vous ouvrirez la Search Console, jetez un œil à l'onglet Images. Vous y trouverez peut-être une conversation que vous n'aviez jamais eue avec votre propre site.
