Comment optimiser les images de son site pour le référencement

Optimiser les images de son site : le levier SEO que 90 % des gens ratent

Un client m'appelle un mardi matin, paniqué. Son site de mobilier artisanal stagne en page 3 de Google depuis huit mois. Il a refait sa page d'accueil, réécrit ses meta descriptions, acheté un thème premium. Rien. Je me connecte, j'ouvre sa page d'accueil, je regarde le poids total. 14,2 Mo. Sans même charger la moitié des images de sa galerie produits. Voilà le problème. Il n'a jamais touché à ses images.

À chaque audit que je fais, c'est la même histoire. Les gens passent des heures sur leurs balises title, leurs liens internes, leurs mots-clés, et ils laissent des PNG de 4 Mo traîner au milieu de leurs articles. Franchement, ça me rend fou. Parce que l'optimisation des images, c'est le chantier SEO le plus rentable et le moins glamour qui existe. Ça ne se voit pas, ça ne se raconte pas en soirée, mais ça bouge des positions.

Pourquoi vos images pèsent plus lourd que vous ne le pensez sur votre référencement

Le HTML d'une page de blog standard fait entre 30 et 60 Ko. Une seule photo prise au smartphone pèse 3 à 5 Mo. Faites le rapport.

Google mesure la vitesse de rendu de votre page via trois indicateurs regroupés sous le nom de Core Web Vitals. L'un d'eux, le LCP (Largest Contentful Paint), mesure le temps qu'il faut pour afficher le plus gros élément visible. Sur un site vitrine classique, cet élément est presque toujours une image : la bannière d'accueil, la photo produit principale, l'illustration d'en-tête. Multipliez ça par un mobile en 4G moyenne, et vous comprenez pourquoi votre beau site met six secondes à s'afficher. Google n'aime pas les sites lents. Et depuis que le LCP compte comme signal de classement, vos images sont directement dans l'équation.

L'impact mesurable, concrètement

Sur le site de ce client en mobilier, j'ai repris ses 40 photos produits principales. Conversion en WebP, redimensionnement aux dimensions réelles d'affichage, compression à qualité 78. Le poids total de la page est passé de 14,2 Mo à 1,8 Mo. Le LCP est tombé de 5,1 secondes à 1,4 seconde. Sur les six semaines suivantes, son trafic organique a augmenté de 22 % sur les requêtes produit. Une seule intervention, aucun nouveau contenu.

Je ne vous sors pas ça pour flexer. Je le sors parce que personne ne vous dit que levier SEO numéro un sur la majorité des sites que je croise, c'est celui-là. Pas les backlinks. Pas la stratégie de contenu. Les images.

Formats et compression : les bons réflexes, sans se tromper

Ici, la règle est simple. Mais les gens compliquent toujours.

Quel format choisir selon le type d'image ?

Vous avez cinq formats qui comptent vraiment en 2026 : JPEG, PNG, WebP, AVIF et SVG. Chacun a sa place. Mal utilisé, il vous coûte de la performance.

Format	Quand l'utiliser	Quand l'éviter	Poids relatif
JPEG	Photos, images avec dégradés, tout ce qui n'a pas besoin de transparence	Logos, icônes, captures d'écran avec texte	Référence
PNG	Logos, icônes, illustrations à aplats de couleur, transparence nécessaire	Photographies	2 à 4× plus lourd qu'un JPEG
WebP	Remplace presque tout : photos, illustrations, éléments d'interface	Rien, sauf cas très précis d'anciens navigateurs	25 à 35 % plus léger qu'un JPEG
AVIF	Compression maximale, sites à fort volume d'images	Si vous ne pouvez pas générer de fallback	Jusqu'à 50 % plus léger qu'un JPEG
SVG	Logos, icônes vectorielles, illustrations géométriques	Photos, textures complexes	Quelques Ko en général

Le piège classique : garder un logo en PNG 2000 px de large alors qu'il s'affiche à 120 px dans le header. J'ai vu ça sur au moins un tiers des sites que j'audite. Un logo, ça devrait peser 3 à 8 Ko en SVG. Pas 180 Ko.

Quel poids viser, concrètement ?

Voici mes repères personnels, après avoir optimisé plusieurs centaines d'images :

• Photo d'article : 60 à 120 Ko après compression, 800 à 1200 px de large maximum.
• Bannière hero : 120 à 250 Ko max, 1600 à 1920 px de large.
• Miniature de galerie : 20 à 50 Ko, 400 à 600 px.
• Icône d'interface : moins de 5 Ko, format SVG de préférence.
• Logo d'en-tête : moins de 10 Ko.

Au-delà de ces seuils, vous perdez de la performance pour rien. La différence visuelle à l'œil nu entre une photo JPEG à qualité 90 et la même à qualité 75 est quasi nulle. Le gain de poids, lui, est énorme. Arrêtez d'exporter en qualité 100. C'est une erreur que j'ai faite pendant mes six premiers mois de blogging. Chaque image que je publiais pesait 2,5 Mo parce que je voulais "la meilleure qualité possible". J'ignorais que Lightroom me sortait déjà des fichiers pré-compressés inutiles.

Balises alt et noms de fichiers : les deux signaux que Google lit vraiment

Il y a une confusion massive sur ce sujet. Je vais être direct.

À quoi sert vraiment la balise alt ?

La balise alt sert à décrire une image pour les personnes qui ne peuvent pas la voir. Point. C'est une exigence d'accessibilité, une obligation légale dans plusieurs contextes, et une bonne pratique humaine. Que Google utilise ce texte pour comprendre le contenu de l'image, c'est vrai. Mais si vous rédigez votre alt en pensant "mot-clé", vous passez à côté.

Ce que ça donne, concrètement :

• Mauvais : alt="chaise pas cher mobilier design boutique meuble"
• Bon : alt="Chaise en chêne massif avec dossier incurvé, finition huilée naturelle"

Le premier est du bourrage de mots-clés. Google sait le reconnaître, ça ne vous apportera rien, et ça dégrade l'expérience pour les utilisateurs de lecteurs d'écran. Le second décrit réellement l'image, et contient naturellement les termes pertinents. La différence est dans l'intention.

Le nom de fichier : le signal que tout le monde oublie

Quand vous exportez une image, votre appareil photo ou votre logiciel lui donne un nom du genre IMG_7734.jpg. Google lit ce nom. Il l'utilise comme signal pour comprendre le contenu de l'image. C'est un des rares endroits où vous pouvez influencer le classement dans Google Images sans ambiguïté.

Renommez systématiquement. En minuscules, avec des tirets, en français si votre audience est francophone : table-basse-acier-noir-industriel.webp. Ça prend dix secondes par image. Sur un site de 200 images, ça fait une demi-journée. Le retour sur investissement est réel : sur un blog cuisine que j'accompagne, le trafic issu de Google Images est passé de 4 % à 17 % du trafic total en quatre mois, uniquement avec cette méthode sur les images de recettes.

Responsive, lazy loading et sitemap images : la mécanique technique

Trois choses à mettre en place pour que tout tienne. Le reste, c'est du détail.

Images responsive : servir la bonne taille au bon appareil

Une image affichée à 400 px sur mobile n'a aucune raison d'être servie en 1600 px de large. srcset et sizes permettent au navigateur de choisir la version adaptée. Vous générez plusieurs résolutions de la même image, vous les déclarez, le navigateur fait le tri.

En pratique, sur un site WordPress, des extensions le font pour vous quand vous téléversez. Sur un site sur mesure, il faut le coder. Mais l'effet est massif : sur mobile, vous divisez souvent le poids par trois ou quatre sans rien changer visuellement.

Lazy loading : oui, mais pas n'importe où

loading="lazy" sur une balise <img> indique au navigateur de ne charger l'image que quand elle approche de la zone visible. Excellent pour les images situées en bas de page.

Le piège : ne jamais l'appliquer à l'image principale de votre page (celle du haut). Si vous lazy-loadez votre bannière hero, le navigateur attend que l'utilisateur fasse défiler pour commencer à la charger. Résultat : votre LCP explose, votre score Core Web Vitals plonge, et vous vous demandez pourquoi votre site est "lent" alors que vous avez fait "tout bien". J'ai mis trois semaines à comprendre ça sur mon propre blog. Trois semaines à chercher d'où venait la régression de performance, avant de tomber sur la ligne de code coupable.

La règle : loading="lazy" sur toutes les images sauf la première visible de chaque page. Pour celle-là, on peut même ajouter fetchpriority="high" pour accélérer encore.

Le sitemap d'images : la déclaration propre à Google

Vous pouvez créer un sitemap spécifique qui liste vos images avec leurs métadonnées : URL, légende, titre, texte alt. Il se déclare en XML avec des balises <image:image> et se soumet à la Search Console comme un sitemap classique. C'est un signal supplémentaire, pas une baguette magique, mais sur des sites e-commerce à forte composante visuelle, ça aide Google à indexer correctement des centaines d'images produit.

Faut-il passer par un plugin ou une agence pour ça ?

Non.

Je vais être clair, parce que c'est une question qu'on me pose sans arrêt. Optimiser les images de son site, c'est un chantier manuel au départ, puis une routine. Vous compressez, vous convertissez, vous renommez, vous remplissez vos balises. Une fois que c'est fait une fois, vous adoptez le réflexe à chaque nouveau contenu.

Les plugins existent et font le travail. Ils compressent à la volée, convertissent en WebP, génèrent les variantes responsive. Si vous êtes sur WordPress et que vous gérez seul, prenez-en un. C'est gratuit pour la majorité des cas, et ça vous évite d'apprendre à coder. Mais sachez qu'un plugin ne remplacera jamais deux choses : le nom de vos fichiers et la pertinence de vos balises alt. Ça, ça reste humain, et c'est précisément là que se joue la différence entre un site qui gagne des places et un site qui stagne.

L'agence, elle, se justifie si vous avez 5000 références produit et zéro temps à y consacrer. Sinon, fournissez de la méthode. Pas de budget.

Les erreurs que je vois le plus souvent (et que j'ai faites aussi)

• Exporter en qualité 100. Aucun intérêt visuel, poids multiplié par deux ou trois.
• Oublier le redimensionnement. Une photo de 4000 px de large affichée en 600 px, c'est du gaspillage pur.
• Bourrer la balise alt de mots-clés. Contre-productif et pénalisant à long terme.
• Laisser les noms par défaut. DSC_0291.jpg ne dit rien à personne. À Google non plus.
• Lazy-loader la bannière. La faute que j'ai mis trois semaines à identifier sur mon propre site.
• Garder de vieux PNG lourds sur des pages qu'on ne met plus à jour mais qui rankent encore.

Chacune de ces erreurs, je l'ai commise au moins une fois. La dernière surtout. Aujourd'hui, j'audite systématiquement le poids des images avant de toucher à quoi que ce soit d'autre sur un site. Dans 80 % des cas, c'est là que se cache le vrai problème. Pas dans les balises. Pas dans la stratégie éditoriale. Dans des fichiers mal préparés qui plombent silencieusement tout le reste.

La prochaine fois que vous vous demandez pourquoi un concurrent moins bon que vous se classe mieux, ouvrez l'inspecteur, regardez la taille de ses images. Vous serez peut-être surpris. Ou pas. Ça dépend de ce que vous allez faire de cette information.