Bon, parlons peu et parlons bien : l’optimisation des images, ce n’est pas juste « compresser un JPEG et remplir la balise alt ». Si vous lisez ça, c’est que vous avez probablement déjà fait le tour des articles génériques qui vous conseillent de passer en WebP et d’utiliser des noms de fichiers descriptifs. Tout ça, c’est bien. Mais c’est le minimum vital, le B.A.-BA.
Moi, ce qui m’intéresse ici, c’est ce qui se passe après. Quand votre site fait 10 000 pages, que vos images sont servies par un CDN et que Google Images commence à représenter 15 % de votre trafic organique. C’est là que le bât blesse, et c’est là que vous allez vraiment gagner — ou perdre — des positions. Un audit que j’ai mené l’an dernier sur un site e-commerce de 4 000 fiches produits a révélé que 62 % de leurs images n’étaient même pas indexées correctement. Pas à cause des alt, mais à cause de la gestion des doublons d’URL et du lazy-loading mal configuré.
Alors oui, on va parler des bases. Mais on va surtout parler de ce que Google ne vous dit pas dans sa doc Search Central, et de ce que j’ai appris en bidouillant des scripts d’audit pour mes propres clients.
Points clés à retenir
- L’optimisation des images ne se limite pas au poids du fichier : l’indexation et la pertinence contextuelle priment.
- La gestion des images dupliquées ou quasi-identiques est un facteur de cannibalisation souvent ignoré.
- Le lazy-loading, s’il est mal configuré, peut enterrer vos images hors de portée du crawler.
- Les données structurées
imageObjectapportent un contexte que la balise alt ne fournit pas. - Un audit ne se fait pas au hasard : il faut un script pour prioriser les actions à fort impact.
- Google Lens et la recherche visuelle changent la donne : le contexte de la page devient l’élément clé.
L’optimisation des images en 2026 : ce qui a vraiment changé
J’ai commencé à m’intéresser sérieusement au référencement technique il y a environ six ans, sur un blog qui tirait péniblement 300 visites par mois. À l’époque, la recette était simple : un bon alt, un nom de fichier propre, et une compression raisonnable. Ça suffisait presque toujours.
Aujourd’hui, la donne est différente. Google ne se contente plus de regarder l’image dans son coin. Il l’analyse, il la compare, il la situe dans un contexte. Et surtout, l’essor de la recherche visuelle via Google Lens fait que l’image elle-même devient une requête.
Une chose m’a frappé lors d’un projet récent : un client dans le tourisme avait des centaines de photos de paysages, toutes magnifiques, mais presque aucune n’était servie en format adapté aux miniatures de Google Images. Résultat : des impressions, mais un taux de clic famélique. Pourquoi ? Parce que Google affiche des versions recadrées et compressées de vos images dans ses résultats, et si la version originale n’est pas assez nette ou est trop lourde, l’algorithme préfère montrer celle du concurrent.
Le vrai pivot, ce n’est plus le format. C’est la pertinence contextuelle. Et ça, aucune compression ne peut le faire à votre place.Le mythe du format unique : JPEG vs WebP vs AVIF
On me demande souvent : « Quel est le meilleur format ? » Franchement, cette question est devenue presque secondaire, surtout si vous utilisez un bon CDN qui négocie automatiquement le format en fonction du navigateur via la négociation de contenu.
Petit retour d’expérience : sur un site vitrine que j’ai migré en AVIF pour les photos, le gain de poids a été spectaculaire. On est passé de 180 Ko par image en JPEG à 45 Ko en AVIF pour une qualité visuelle identique à l’œil nu. Sur une page avec 12 images, ça change la donne pour le LCP.
Mais attention, il y a un piège. Le support d’AVIF est universel en 2026, certes, mais l’encodage est plus lent et plus gourmand en ressources serveur. Si vous générez des miniatures à la volée, ça peut coûter cher en CPU. Et si vous êtes sur un petit serveur mutualisé, ça peut même ralentir vos autres requêtes.
- JPEG : toujours pertinent pour les photos complexes avec beaucoup de dégradés
- WebP : le bon compromis, supporté partout, bon ratio compression/qualité
- AVIF : le plus léger, mais attention aux coûts d’encodage temps réel
Mon conseil si vous hésitez : laissez le CDN gérer. La plupart des bons CDN offrent une transformation d’image automatique qui sert le bon format au bon navigateur. C’est un investissement qui se rentabilise en quelques semaines.
Alt, nom de fichier, contexte : le trio qui indexe
Si vous en avez marre de lire que la balise alt doit être descriptive, tant mieux. Parce que ce n’est plus le seul critère. Depuis quelques années, j’ai remarqué que Google accorde une importance croissante à la cohérence entre le texte alternatif et le contenu environnant.
Prenons un exemple concret. Vous vendez des chaussures de randonnée. Vous avez une photo du produit sur fond blanc. La balise alt dit « chaussures de randonnée femme bleues ». Le nom de fichier dit aussi « chaussures-randonnee-femme-bleues.jpg ». Bien.
Mais quel est le titre de la page ? Quel est le texte autour de l’image ? Si l’image est noyée dans un paragraphe qui parle de la fabrication des chaussures, Google va avoir du mal à comprendre que c’est LE produit principal. Résultat : l’image perd en pertinence pour la requête « chaussures randonnée femme ».
Le contexte de la page est devenu le facteur de différenciation numéro un. Une image isolée, même parfaitement nommée, ne vaut rien sans un environnement textuel riche qui la relie au sujet de la page.L’erreur classique du lazy-loading
Ah, le lazy-loading. En théorie, c’est génial : on ne charge les images que lorsqu’elles arrivent dans le viewport. En pratique, c’est un champ de mines.
Sur un site d’actualités que j’auditais, les images des articles n’étaient pas indexées. J’ai creusé, creusé, et finalement, le coupable était le plugin de lazy-loading. Il utilisait une technique de « placeholder » avec un script JavaScript qui insérait l’URL réelle dans la balise `src` seulement après le scroll. Googlebot, lui, ne scrolle pas comme un humain. Il utilise un viewport fixe, et tout ce qui est en dessous n’est jamais chargé si le rendu est défaillant.
La solution n’est pas de supprimer le lazy-loading, mais de le configurer correctement. Les navigateurs modernes supportent le chargement natif paresseux via l’attribut `loading="lazy"`, et Googlebot comprend ça très bien. Assurez-vous que votre solution utilise bien ce mécanisme natif, ou qu’elle n’affecte pas l’attribut `src` de manière trop agressive.
Le problème silencieux : les images dupliquées et la cannibalisation
Voilà un angle dont personne ne parle, et qui m’a coûté des mois de travail sur un gros projet. J’ai un client qui vend des meubles. Chaque produit a une photo principale, mais aussi des variantes : la même chaise en hêtre, en chêne, en noyer. Et chaque variante a sa propre page avec la même photo de base, juste retouchée pour changer la teinte.
Résultat : vingt, trente, parfois quarante images quasi identiques sur le même domaine. Google ne sait plus laquelle est la version canonique. Il indexe les unes, ignore les autres, et dilue la pertinence dans un océan de doublons visuels.
J’ai passé un après-midi à extraire toutes les URLs d’images via la Search Console et à les comparer avec un script maison qui calculait un hash perceptuel. Le verdict était sans appel : 34 % des images étaient des duplicatas visuels.
Que faire ? Deux choses.
La déduplication stratégique
D’abord, identifiez les vraies doublures exactes. Pour les variantes de couleur, la bonne pratique est de ne servir qu’une seule image représentative sur la page principale, et de masquer les autres derrière des onglets qui ne sont pas crawlables facilement. Ou, mieux, d’utiliser des données structurées pour indiquer à Google quelle est l’image principale.
Ensuite, pour les images très similaires mais pas identiques, le contexte est roi. Si vous devez garder des images proches, assurez-vous qu’elles sont dans des contextes radicalement différents. D’un point de vue technique, si vous servez des images avec des paramètres de requête différents pour les redimensionner (ex : `?w=800`), Google peut les considérer comme des URLs distinctes. Utilisez des dimensions fixes et des noms de fichiers uniques pour éviter l’inflation.
Audit technique : comment prioriser sans se noyer
Sur un site existant à grande échelle, impossible de traiter chaque image manuellement. Il faut un audit automatisé. J’ai mis au point une méthode simple en trois étapes que j’utilise pour tous mes audits SEO.
- Le poids de la page et le nombre d’images
- La présence d’attributs `alt` (et leur longueur)
- La présence d’attributs `width` et `height` (crucial pour éviter le CLS)
- Le type de fichier et sa taille en octets
Un chiffre qui m’a marqué : sur un projet, j’ai diminué de 40 % le poids total des pages d’une catégorie en ne touchant qu’aux 12 images en tête de page. Le LCP est passé de 3,8 secondes à 2,1 secondes. Et le trafic organique vers ces pages a augmenté de 17 % sur deux mois. Rien que ça.
Script maison : le hash perceptuel
Si vous êtes un peu technique, je vous conseille d’écrire un petit script qui calcule le hash perceptuel de vos images (dHash ou pHash). C’est un outil redoutable pour repérer les doublons visuels. J’ai utilisé cette technique sur un site de presse qui recyclait les mêmes photos d’archives pour différents articles. En quelques minutes, j’avais une liste de toutes les images dupliquées, et j’ai pu recommander des stratégies de suppression ou de consolidation.
Le renouveau de la recherche visuelle : préparer l’après-alt
C’est mon coup de gueule personnel. Tout le monde parle de Google Lens comme d’une révolution, mais peu de gens adaptent leur stratégie d’images en conséquence. La recherche visuelle ne se fait plus sur le nom de fichier. Elle se fait sur la forme, la couleur, la composition de l’image.
Que pouvez-vous faire concrètement ?
D’abord, intégrez les données structurées `imageObject` dans vos pages. Ça permet de donner un titre et une description à l’image, distincts de la page elle-même. C’est une couche d’information supplémentaire que Google peut utiliser pour comprendre ce que représente l’image.
Ensuite, pensez à la qualité intrinsèque de l’image. Google Lens va détecter des éléments dans vos photos. Si vos photos sont floues, mal éclairées, ou si le produit est trop petit dans le cadre, la recherche visuelle ne pourra pas les associer correctement.
Enfin, et c’est peut-être le plus important : le texte autour de l’image. Google utilise le contenu de la page pour comprendre ce qui est sur la photo. Une légende descriptive, un paragraphe qui nomme précisément les éléments visibles, vont aider l’algorithme à faire le lien. Sur un site de recettes que j’ai optimisé, l’ajout de légendes détaillées sous chaque étape en photo a fait grimper le trafic depuis Google Images de 22 % en trois mois.
Le cas particulier des images servies par CDN
Beaucoup d’entre vous utilisent des CDN qui optimisent les images automatiquement. C’est très bien, mais il y a un piège : les URLs. Si votre CDN génère des URLs avec des paramètres dynamiques pour chaque transformation (ex : `?auto=compress&fit=clip&w=1200`), vous vous retrouvez avec des dizaines de versions de la même image.
Googlebot est malin, mais il n’est pas magicien. Il peut interpréter ces URLs comme des ressources distinctes, ce qui dilue la valeur et crée du contenu dupliqué aux yeux de l’algorithme.
Ma recommandation : utilisez des URLs stables et propres pour vos images principales. Si vous avez besoin de différentes tailles, servez-les via des chemins prédéfinis (`/images/produit-large.jpg`, `/images/produit-thumb.jpg`) plutôt que des paramètres de requête. Ça simplifie la vie de Google, et ça simplifie la vôtre lors des audits.
Conclusion : l’image, un actif à part entière
Voilà où je veux en venir. L’optimisation des images pour le SEO technique a cessé d’être une simple question de compression. C’est devenu une question de gestion d’actifs numériques. Chaque image est une entité qui doit avoir une identité claire, un contexte riche, et une version propre et stable sur le plan technique.
La prochaine fois que vous ajoutez une image à votre site, posez-vous trois questions : est-ce que cette image apporte une information unique ? Est-ce que le contexte autour d’elle est suffisant pour que Google la comprenne ? Est-ce qu’elle existe sous une seule forme d’URL principale ?
Si vous répondez oui à ces trois questions, vous avez fait 80 % du travail. Le reste, c’est de la technique pure, et la technique, ça se règle.
Je suis curieux de savoir : avez-vous déjà audité vos images dupliquées ? Ou est-ce que le lazy-loading vous a déjà joué des tours ? C’est souvent dans ces recoins sombres que se cachent les plus belles victoires.