Référencement des images : le guide complet

Le référencement des images ne se limite pas à remplir un attribut alt avec des mots-clés. Deux leviers concrets sont en jeu : la visibilité dans Google Images, qui envoie du trafic réel sur des requêtes visuelles — recettes, mode, décoration, produits, tutoriels bricolage — et le poids des images elles-mêmes, qui reste la cause la plus fréquente de mauvais scores sur les Core Web Vitals. Une page qui charge lentement à cause d'une bannière de plusieurs mégaoctets perd sur les deux tableaux à la fois.

Ce guide couvre les leviers qui font réellement la différence : l'attribut alt utilisé correctement, le nom de fichier et l'URL, les formats modernes et la compression, les images responsives, le lazy loading et son piège le plus courant, le contexte textuel autour de l'image, puis le sitemap d'images, les données structurées et les questions de droits. La plupart des sites ratent plusieurs de ces points à la fois, souvent parce que la partie technique a été confiée à quelqu'un qui ne savait pas qu'elle avait un impact SEO.

Pourquoi les images comptent pour le référencement

Une image bien référencée peut apparaître directement dans Google Images, un onglet que les internautes utilisent comme moteur de recherche à part entière pour certaines intentions : trouver un modèle de vêtement, comparer des coupes de cheveux, repérer une idée de rangement de cuisine, identifier une plante. Pour un site e-commerce, un blog cuisine ou un site de décoration, ce trafic n'est pas anecdotique : il arrive sur la fiche produit ou l'article via un canal que le contenu texte seul n'atteint pas.

L'autre raison est moins visible mais plus fréquente en audit : les images sont, sur la grande majorité des sites, le poste le plus lourd de la page. Quand une page échoue sur le Largest Contentful Paint ou traîne un mauvais score de performance, la cause est presque toujours une image mal dimensionnée ou mal compressée plutôt qu'un excès de JavaScript. Corriger ce point ne demande pas une refonte : quelques heures de travail sur les formats et les dimensions produisent souvent un gain de performance qu'un chantier de contenu de plusieurs mois n'égalerait pas sur le même indicateur.

L'attribut alt : l'accessibilité d'abord, jamais un tiroir à mots-clés

L'attribut alt existe d'abord pour l'accessibilité, pas pour le SEO. Un lecteur d'écran le lit à voix haute à une personne malvoyante à la place de l'image ; un navigateur l'affiche aussi quand l'image ne charge pas, sur une connexion lente ou un fichier cassé. Un bon alt décrit ce que montre l'image, dans le contexte de la page où elle apparaît — pas une liste de mots-clés qu'on espère faire remonter.

La même photo de chaussures n'a pas le même alt selon l'endroit où elle se trouve. Sur une fiche produit : « chaussures de randonnée imperméables modèle Atlas, coloris marron, vue de profil ». Dans un article sur la préparation d'une randonnée en montagne : « chaussures de randonnée adaptées aux sentiers rocailleux ». Le mauvais réflexe, très répandu, ressemble à « chaussures randonnée pas cher meilleur prix achat en ligne » répété sur les douze photos d'une même galerie — cela n'aide ni l'accessibilité ni le classement, et cela ressemble à du bourrage de mots-clés parce que c'en est.

Pour une image purement décorative — une texture de fond, un séparateur visuel, une icône redondante à côté d'un lien qui porte déjà le même texte — un alt vide (attribut présent, valeur vide) est le bon choix. Un lecteur d'écran passe proprement sur un alt vide. En revanche, un attribut alt absent, ou rempli avec un texte générique comme « image » ou « photo1 », force souvent le lecteur d'écran à annoncer le nom du fichier à la place, ce qui est pire que le silence. La question à se poser avant chaque image : si je la retirais, le lecteur perdrait-il une information ? Si oui, décrire précisément. Si non, alt vide.

Nom de fichier et URL : la description que Google lit avant même l'alt

Avant même de lire l'attribut alt, un moteur de recherche a déjà vu l'URL du fichier. IMG_20250612_143022.jpg ou DSC_0294.jpg, exports bruts d'un appareil photo ou d'un smartphone, ne disent rien du contenu. Renommer le fichier en chaussures-randonnee-atlas-marron.jpg avant l'envoi donne un signal supplémentaire, gratuit, que la plupart des sites laissent sur la table.

En français, mieux vaut rester en minuscules, sans accents, avec des tirets plutôt que des espaces ou des underscores. Ce n'est pas une question de goût : un caractère accentué dans une URL est encodé (é devient %C3%A9), ce qui produit une adresse illisible et parfois mal gérée par un CDN ou une couche de cache. « chaussures-randonnee » reste plus sûr que « chaussures-randonnée », même si le mot-clé visé porte l'accent dans le texte visible de la page.

Deux règles pratiques : un nom de fichier distinct par image distincte — éviter le générique image1.jpg réutilisé sur dix pages, qui devient ambigu pour Google Images et complique le suivi des fichiers orphelins — et une arborescence de dossiers cohérente si le site publie beaucoup de galeries, ce qui facilite ensuite la génération du sitemap d'images.

Formats modernes, compression et dimensions : le poids qui casse tout

WebP et AVIF offrent, à qualité visuelle égale, des fichiers nettement plus légers qu'un JPEG classique. AVIF va plus loin en compression mais coûte plus cher à encoder et, sur certains appareils plus anciens, à décoder — WebP reste donc le choix par défaut le plus sûr en compatibilité large, avec AVIF servi en priorité aux navigateurs qui le gèrent via la négociation de format de l'élément picture. Le PNG doit rester réservé aux besoins réels de transparence ou d'aplats de couleur — logo, icône, capture d'écran avec du texte — jamais à une photographie, où il produit un fichier plusieurs fois plus lourd qu'un JPEG ou un WebP bien compressé, pour un gain visuel nul.

La compression avec perte, réglée à une qualité raisonnable et non maximale, reste invisible à l'œil à une taille d'affichage normale tout en réduisant fortement le poids du fichier. Un export en qualité 100 gaspille presque toujours des octets que personne ne verra.

Le point le plus courant en audit, et le moins cher à corriger, reste le dimensionnement. Une photo de 4000 pixels de large importée telle quelle puis rétrécie à 400 pixels par la mise en page force le navigateur à télécharger dix fois plus de pixels qu'il n'en affichera jamais. La bonne pratique est de redimensionner le fichier source à la taille réellement affichée, en comptant large pour les écrans à haute densité — environ deux fois la taille d'affichage, rarement plus. Une image à la fois mal formatée et mal dimensionnée peut à elle seule peser plus lourd que tout le reste de la page.

Images responsives : servir la bonne taille à chaque écran

srcset et sizes permettent au navigateur de choisir lui-même le fichier adapté à son écran et à sa densité de pixels, plutôt que de recevoir la même image pour un téléphone et pour un moniteur 4K. En pratique, srcset liste plusieurs versions du même visuel avec leur largeur, et sizes indique au navigateur la largeur d'affichage attendue selon la mise en page — le navigateur combine les deux informations pour ne télécharger que le fichier suffisant, jamais plus.

L'élément picture va plus loin que le simple redimensionnement : il permet un vrai changement de cadrage selon l'écran — un cadrage portrait serré sur mobile, un cadrage large sur desktop pour la même image d'illustration — ou une bascule de format, en proposant l'AVIF puis le WebP puis le JPEG en repli, dans l'ordre que le navigateur accepte.

• Sans srcset : le site sert la version desktop de la bannière à un visiteur mobile en 4G, l'inverse de ce qu'exige une indexation pensée mobile d'abord.
• Avec srcset et sizes : le même fichier source, décliné en plusieurs largeurs, sert chaque appareil avec le strict nécessaire, sans intervention manuelle page par page.

Lazy loading : la bonne pratique et le piège de l'image visible au chargement

loading="lazy" retarde le chargement des images situées hors de l'écran au moment du chargement de la page, pour ne pas consommer de bande passante sur des images que le visiteur ne verra peut-être jamais. C'est la bonne pratique pour tout ce qui se trouve sous la ligne de flottaison.

Le piège, très répandu, consiste à appliquer ce même attribut — ou une bibliothèque JavaScript de lazy loading — à l'image visible dès le chargement, celle qui constitue justement l'élément du Largest Contentful Paint. Retarder son chargement retarde mécaniquement la métrique la plus regardée : le navigateur attend que le script s'exécute avant même de découvrir qu'il doit récupérer ce fichier, alors qu'il aurait pu commencer le téléchargement dès l'analyse du HTML.

La règle est simple : la première image visible sans défilement, en particulier si c'est la plus grande, doit charger normalement — loading="eager", qui est d'ailleurs le comportement par défaut si l'attribut n'est pas posé — et peut recevoir fetchpriority="high" pour indiquer explicitement au navigateur de la prioriser. Seules les images situées plus bas doivent porter loading="lazy". Ce seul réglage inversé — un plugin de lazy loading appliqué sans distinction à toutes les balises img, hero compris — explique une bonne partie des mauvais scores de performance observés sur des sites par ailleurs légers en JavaScript.

Légendes et texte de contexte : le signal que l'alt seul ne donne pas

Google lit aussi le texte physiquement proche d'une image — la légende, le paragraphe qui l'entoure, le titre de la section — comme signal complémentaire à l'attribut alt pour comprendre ce qu'elle représente. Une photo de produit posée dans un paragraphe qui ne nomme jamais ce produit, sur une page au titre générique, donne beaucoup moins de matière que la même photo accompagnée d'une légende et d'un texte qui en parlent réellement.

Les légendes ont aussi une valeur qui dépasse le référencement : c'est l'un des éléments de texte les plus lus d'une page, souvent davantage que le corps du texte pour un lecteur qui parcourt rapidement. Sur une page de galerie ou de portfolio, mieux vaut ne pas compter uniquement sur l'attribut alt pour différencier les images — une légende d'une ligne sous chaque photo sert à la fois le lecteur qui scanne la page et le moteur qui cherche du contexte.

Sitemap d'images, données structurées, licences et hotlinking

Un sitemap d'images — via l'extension image:image du sitemap XML standard, ou un fichier dédié — liste chaque image avec la page où elle apparaît. Il aide surtout dans deux cas : les images chargées en JavaScript qu'un robot risque de ne pas exécuter, et les images hébergées sur un sous-domaine ou un CDN séparé, sans autre lien direct dans le sitemap principal. Les données structurées vont plus loin en désignant l'image représentative d'une entité précise : la propriété image d'un schéma Product, Recipe ou Article indique quelle photo représente réellement le produit, la recette ou l'article, ce qui compte pour la façon dont Google la sélectionne dans les résultats enrichis et dans Google Images. Ce n'est pas nécessaire sur chaque image du site — seulement là où existe une relation claire entre une image précise et l'entité qu'elle représente, pas sur les visuels décoratifs ou de galerie secondaire.

Deux sujets de droits reviennent régulièrement. D'abord la licence : une image utilisée sans droit d'usage clair — banque d'images sans licence valide, capture d'écran d'un tiers, photo trouvée sur un moteur de recherche — expose à un retrait ou une réclamation, indépendamment de tout enjeu SEO. Ensuite le hotlinking : quand un autre site affiche une image en pointant directement vers le fichier hébergé chez vous, au lieu de l'héberger lui-même, c'est votre bande passante qui est consommée à chaque affichage chez lui, sans aucun trafic en retour. La protection habituelle consiste à bloquer, au niveau du serveur ou du CDN, les requêtes d'images dont l'en-tête referer provient d'un domaine externe non autorisé, tout en laissant passer les moteurs de recherche et les navigateurs sans referer.