Comment optimiser une image pour le SEO : alt, format, poids et chargement

Optimiser une image pour le SEOSearch Engine Optimization. Ensemble des techniques visant à améliorer le positionnement d'un site web dans les résultats naturels des moteurs de recherche., c'est régler trois choses. Google doit la trouver (une balise <img> dans le HTML, un format qu'il accepte), la comprendre (le texte autour, un attribut altAttribut HTML décrivant le contenu d'une image pour les moteurs de recherche et l'accessibilité. descriptif, un nom de fichier parlant) et la charger sans ralentir la page (bonnes dimensions, WebP ou AVIF, aucun lazy loadingTechnique chargeant les images et médias uniquement lorsqu'ils deviennent visibles à l'écran. sur l'image du haut de page).

Ce guide s'adresse aux équipes qui publient des images en volume : fiches produits, articles, pages magasins. Il suit la documentation de Google sur les images et les recommandations de performance de web.dev. Il tranche aussi ce qui reste facultatif : le sitemapFichier XML listant toutes les URLs d'un site pour faciliter leur découverte par les moteurs de recherche. d'images et les métadonnées de licence servent surtout aux sites dont les images apportent du trafic, et le sitemap aux images que Google risque de ne pas trouver seul.

Une image que Google trouve dans le HTML

Google trouve une image quand elle figure dans l'attribut src d'un élément <img>, y compris à l'intérieur d'un <picture>. Une image posée en background-image dans le CSS n'est pas indexée. Gardez ce procédé pour les fonds et les motifs décoratifs.

<!-- Indexable par Google -->
<img src="/images/canape-velours-vert-3-places.webp" alt="Canapé trois places en velours vert, pieds en chêne">

<!-- Non indexée : image de fond CSS -->
<div style="background-image:url(/images/canape-velours-vert-3-places.webp)"></div>

Côté formats, la recherche Google accepte en src les fichiers BMP, GIF, JPEG, PNG, WebP, SVG et AVIF. Elle recommande aussi que l'extension du nom de fichier corresponde au type de fichier : un .webp pour du WebP, un .jpg pour du JPEG.

Trois règles complètent la base :

• Une URL de repli. Avec srcset ou <picture>, gardez toujours une URL dans l'attribut src de l'<img>. Ces attributs ne sont pas reconnus par tous les navigateurs et robots d'exploration.
• Une URL stable. Une image reprise sur plusieurs pages (logo, pictos de réassurance, visuel de gamme) garde la même URL partout. Google peut alors la mettre en cache et la réutiliser sans la redemander, ce qui ménage le budget de crawl d'un gros site.
• Un chargement sans action. Une image ajoutée par JavaScriptLangage de programmation web. Son mauvais usage peut bloquer l'indexation par les moteurs de recherche. ou chargée en différé doit arriver dans la page dès qu'elle entre dans la fenêtre d'affichage, sans clic ni défilement : Google n'interagit pas avec la page.

Pour savoir si Google voit une image chargée par script, ouvrez l'outil d'inspection d'URLUniform Resource Locator. Adresse unique d'une page web. Une URL optimisée est courte, descriptive et contient le mot-clé. de la Search ConsoleOutil gratuit Google pour surveiller et optimiser la présence d'un site dans les résultats de recherche.. Si l'URL de l'image figure dans l'attribut src du HTML affiché, la configuration fonctionne. Les autres pièges du rendu côté client sont dans le guide JavaScript et SEO, et ceux d'une application React dans le guide React SEO.

Le texte alternatif : décrire l'image en une phrase

L'attribut alt est, pour Google, l'attribut le plus important quand il s'agit de fournir des métadonnées sur une image. Google le combine au contenu de la page et à ses algorithmesProgramme informatique utilisé par les moteurs de recherche pour classer les pages web. Google utilise plus de 200 facteurs de ranking. de vision par ordinateur pour déterminer le sujet de l'image. Quand l'image sert de lien, l'alt peut aussi servir de texte d'ancrage. Il profite enfin aux personnes qui utilisent un lecteur d'écran ou une connexion lente.

La règle de rédaction tient en une question : que doit savoir une personne qui ne voit pas l'image ? Répondez en une phrase, avec le mot-clé seulement s'il décrit vraiment l'image. Google classe lui-même les variantes dans sa documentation :

Transposé à une fiche produitPage dédiée à un produit, devant être optimisée avec description unique, images et données structurées., « Canapé trois places en velours vert, pieds en chêne » dit ce que montre la photo. « canapé velours canapé vert pas cher livraison gratuite » relève de l'accumulation de mots-clés, qui selon Google nuit à l'expérience et peut faire passer le site pour du spamTechniques manipulatrices visant à tromper les moteurs de recherche..

Deux cas changent la règle. Une image qui sert de lien ou de bouton décrit l'action, d'après le W3C : « Imprimer cette page » pour une icône d'imprimante. Une image purement décorative (séparateur, motif, icône doublée par son libellé) prend un alt vide, alt="", pour que les lecteurs d'écran l'ignorent. Supprimer l'attribut ne règle rien : sans lui, certains lecteurs d'écran annoncent le nom du fichier.

Évitez aussi le point médian dans un alt : une synthèse vocale doit deviner comment le prononcer, et une description au vocabulaire neutre fait le même travail (voir écriture inclusive et SEO, zone par zone). Pour un SVG intégré directement dans le code de la page, l'équivalent de l'alt est son élément <title>, relié par aria-labelledby.

Nom de fichier, légende, attribut title : des signaux secondaires

Le nom de fichier ne donne à Google que des indices très légers sur le sujet de l'image, d'après sa documentation. Il reste utile et ne coûte rien : canape-velours-vert-3-places.webp plutôt que IMG00023.JPG.

Visez un nom court, avec des traits d'union entre les mots, que Google recommande dans les URL à la place des traits de soulignement. Sur un catalogue de milliers d'images, automatisez le nommage, comme le suggère Google. Construisez le nom depuis les champs du produit (modèle, couleur, vue), et traduisez-le sur un site multilingue.

La légende et le texte voisin comptent aussi. Google utilise le contenu de la page, légendes et titres des images compris, pour déterminer le sujet d'une image, et demande de placer l'image, dans la mesure du possible, près du texte qui en parle, sur une page dont le sujet correspond. Une photo de gamme placée sous le paragraphe qui la décrit, avec une légende qui ajoute une information (modèle, dimensions, contexte), suit cette consigne à la lettre.

L'attribut title d'une image affiche une infobulle au survol de la souris. MDN le juge très problématique pour l'accessibilité : les personnes sur écran tactile, au clavier ou avec un lecteur d'écran n'y ont pas accès de façon fiable. Mettez l'information utile dans l'alt ou la légende. Ne le confondez pas avec la balise title de la page, qui nourrit le lien de titre dans les résultats de Google.

Poids, dimensions, format : servir l'image à sa taille d'affichage

Une image légère est servie à la taille où elle s'affiche, dans un format moderne, compressée, avec ses dimensions déclarées. Google le rappelle : les images sont souvent volumineuses, ce qui peut ralentir le chargement des pages et faire fuir les visiteurs. La méthode, dans l'ordre :

1. Redimensionner à la taille affichée. Une page ne devrait jamais servir une image plus grande que la version affichée à l'écran : le surplus est du poids perdu, selon la documentation de Chrome. Prenons une vignette affichée sur 400 pixels de large, sur un écran de densité 2 : un fichier de 800 x 600 pixels suffit. La photo de 4 000 x 3 000 pixels sortie de l'appareil compte 12 millions de pixels, 25 fois plus que les 480 000 pixels utiles.
2. Proposer plusieurs tailles. Les attributs srcset et sizes laissent le navigateur choisir la version adaptée à l'écran, avec l'URL de repli dans src.
3. Choisir le format selon le contenu de l'image (tableau ci-dessous).
4. Compresser le fichier. Réglez le niveau de compression avec Squoosh, ImageOptim ou Imagemin, les outils cités par Chrome. L'insight « Improve image delivery » de LighthouseOutil open-source Google auditant performance, accessibilité, SEO et bonnes pratiques d'une page. (libellé de l'interface anglaise) signale ensuite les images trop lourdes, à partir de 4 Kio d'économie estimée.
5. Déclarer width et height. Le navigateur réserve la place de l'image avant son téléchargement et la page ne saute pas. Les images sans dimensions figurent parmi les causes courantes de décalage de mise en page (CLSCumulative Layout Shift. Mesure la stabilité visuelle de la page. Idéalement < 0,1.) listées par Chrome.

Le flux Merchant Center fait exception : il n'accepte pas d'URL d'image en AVIF. Ses formats recommandés sont JPEG et WebP.

AVIF est pris en charge par la dernière version de tous les grands navigateurs, et WebP par tous. Les appareils Apple pas à jour font exception : sur iPhone, Safari lit WebP depuis iOS 14 et AVIF depuis iOS 16 ; sur iPad et sur Mac, la prise en charge d'AVIF dépend aussi de la version du système et de Safari. L'élément <picture> règle le cas des appareils plus anciens en proposant AVIF, puis WebP, puis JPEG :

<picture>
  <source type="image/avif" srcset="canape-vert-800.avif 800w, canape-vert-1600.avif 1600w" sizes="(max-width: 600px) 100vw, 50vw">
  <source type="image/webp" srcset="canape-vert-800.webp 800w, canape-vert-1600.webp 1600w" sizes="(max-width: 600px) 100vw, 50vw">
  <img src="canape-vert-800.jpg" alt="Canapé trois places en velours vert, pieds en chêne" width="800" height="600">
</picture>

Si votre CMS e-commerce génère déjà ces variantes à l'envoi, vérifiez le résultat sur une vraie page plutôt que dans la fiche technique : taille servie, format reçu, dimensions présentes. PageSpeed InsightsOutil Google analysant la performance d'une page et fournissant des recommandations d'optimisation., l'outil que Google recommande pour mesurer la vitesse, fait ce contrôle.

L'image du haut de page : chargement normal et priorité haute

L'image visible à l'ouverture de la page se charge sans loading="lazy" et avec fetchpriority="high". Le lazy loading sert aux images situées plus bas.

Elle est souvent l'élément mesuré par le LCP (Largest Contentful PaintLargest Contentful Paint. Mesure le temps de chargement du plus grand élément visible. Idéalement < 2,5 secondes.), le temps d'affichage de la plus grande image ou du plus grand bloc de texte de la fenêtre. web.dev fixe un bon LCP à 2,5 secondes ou moins pour au moins 75 % des visites. Quand le LCP dépend d'une ressource, c'est une image ou une police web.

L'attribut loading="lazy" diffère le téléchargement d'une image jusqu'à ce qu'elle approche de la fenêtre d'affichage. Sur l'image du haut, ce report retarde l'affichage. web.dev demande de ne jamais charger en différé l'image LCP, et Google demande de ne pas différer un contenu visible dès l'ouverture de la page.

Le cas a été mesuré. WordPress appliquait le lazy loading aux images, y compris à celles du haut de page. Le test A/B de web.dev sur un site WordPress de démonstration a montré un LCP dégradé sur les pages d'archive, avec un effet faible sur les pages d'article. En ne différant que les images situées sous la ligne de flottaison, la régression s'est inversée.

<!-- Image du haut de page : chargement normal, priorité haute -->
<img src="canape-vert-1600.webp" alt="Canapé trois places en velours vert, pieds en chêne" width="1600" height="1200" fetchpriority="high">

<!-- Images plus bas dans la page : chargement différé -->
<img src="canape-vert-detail-pieds.webp" alt="Pied en chêne massif du canapé, vue rapprochée" width="800" height="600" loading="lazy">

Réservez fetchpriority="high" à une image, deux au plus : au-delà, web.dev note que l'attribut n'aide plus à réduire le LCP. Dans un carrousel, les diapositives masquées au démarrage peuvent à l'inverse passer en fetchpriority="low".

Pour vérifier, lancez PageSpeed Insights sur la page. L'insight « LCP request discovery » (libellé de l'interface anglaise) contrôle trois points sur l'image LCP : fetchpriority=high posé, image découvrable dans le HTML initial ou préchargée, aucun loading=lazy.

Sitemap d'images et données structurées : seulement si vos images le justifient

Un sitemap d'images et les métadonnées de licence sont facultatifs. Ils servent quand vos images sont un canal de trafic (catalogue, immobilier, recettes, photos de presse) ou quand Google risque de ne pas les trouver seul.

Google présente le sitemap d'images comme un moyen de lui signaler des images qu'il n'aurait peut-être pas trouvées autrement, par exemple celles que la page charge par JavaScript. Il accepte des URL d'images hébergées sur un autre domaine, pratique avec un CDNContent Delivery Network. Réseau de serveurs distribuant le contenu depuis le serveur le plus proche de l'utilisateur., à condition de valider ce domaine dans la Search Console. Deux balises suffisent, <image:image> et <image:loc>, avec jusqu'à 1 000 images par URL de page :

<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
        xmlns:image="http://www.google.com/schemas/sitemap-image/1.1">
  <url>
    <loc>httpsProtocole sécurisé de transfert de données. Facteur de ranking depuis 2014.://www.exemple.fr/canape-velours-vert-3-places</loc>
    <image:image>
      <image:loc>https://cdn.exemple.fr/canape-velours-vert-3-places.webp</image:loc>
    </image:image>
  </url>
</urlset>

Google a retiré de sa documentation les balises <image:caption>, <image:title>, <image:geo_location> et <image:license> : un générateur qui les écrit encore date. Le guide du sitemap XML réserve de son côté le sitemap d'images aux sites dont les images génèrent du trafic ou de la conversionAction souhaitée accomplie par un visiteur (achat, inscription, contact). Objectif ultime du SEO.. Sur un blog B2B illustré de schémas, des balises <img> propres suffisent.

Les données structuréesCode ajouté au HTML pour aider les moteurs à comprendre le contenu et générer des rich snippets. jouent sur l'affichage : avec elles, vos images peuvent apparaître dans certains résultats enrichis, avec un badge sur Google Images. Chaque type de données structurées demande alors de renseigner sa propriété image. Pour un produit, le balisage Product et les règles d'image du flux Merchant Center sont détaillés dans les guides fiche produit SEO et Google Shopping SEO.

Les métadonnées de licence s'adressent aux photographes, médias et banques d'images. Déclarées en données structurées ou en métadonnées IPTC intégrées au fichier, elles rendent l'image éligible au badge « Sous licence » de Google Images, avec un lien vers la licence. Les champs utiles : licence, page d'acquisition de la licence, crédit, créateur, mention de copyright. Si les deux sources se contredisent, Google retient les données structurées, et il ne garantit pas l'affichage.

L'image que Google affiche dans ses résultats et dans Discover

Google choisit seul l'image d'aperçu d'une page, mais vous l'orientez avec la balise og:image ou les propriétés schema.orgVocabulaire standardisé de balisage structuré reconnu par Google, Bing et Yahoo.. La directive max-image-preview fixe la taille d'aperçu autorisée.

Trois sources de métadonnées orientent ce choix : la propriété primaryImageOfPage d'une WebPage, la propriété image de l'entité principale de la page, ou la balise og:image. Google pose quatre règles pour l'image désignée :

• une image pertinente et représentative de la page ;
• ni logo du site, ni image contenant du texte ;
• pas de format extrême, trop étroit ou trop large ;
• une haute résolution si possible.

<meta name="robots" content="max-image-preview:large">
<meta property="og:image" content="https://www.exemple.fr/images/canape-velours-vert-1600x900.jpg">

La directive max-image-preview accepte none, standard ou large. Sans directive, Google peut afficher un aperçu de taille par défaut ; large autorise un aperçu sur toute la largeur de l'écran. Pour Discover, Google recommande davantage : des images d'au moins 1 200 px de large, de plus de 300 000 pixels au total, au format 16:9, autorisées par max-image-preview:large. Le guide Google Discover détaille ces réglages, et la balise og:image sert aussi aux aperçus de partage décrits dans l'article sur la balise OG.

Si une page n'affiche aucune vignette dans Google, cherchez dans cet ordre :

1. L'image est-elle dans une balise <img>, présente dans le HTML affiché ? Une image de fond CSS ou chargée au clic reste invisible.
2. Est-elle exclue ? Dans le robots.txtFichier texte à la racine d'un site indiquant aux robots quelles pages explorer ou ignorer., une règle Disallow sur l'URL de l'image l'exclut de Google Images si elle vise Googlebot-Image, et de toute la recherche Google si elle vise GooglebotRobot d'exploration de Google qui parcourt le web pour découvrir et indexer les pages.. La directive noimageindex exclut les images de la page.
3. L'aperçu est-il bridé ? max-image-preview:none interdit tout aperçu d'image.
4. L'image désignée suit-elle les règles ? Logo, image contenant du texte et format extrême sont ceux que Google déconseille.

La sélection reste automatisée : ces contrôles lèvent les blocages, aucun ne garantit une vignette.

Auditer les images d'une page en dix minutes

Trois contrôles couvrent l'essentiel : PageSpeed Insights pour la performance, le HTML pour les balises, les en-têtes HTTP pour le fichier lui-même.

1. PageSpeed Insights. Repérez l'élément LCP, puis lisez trois insights (libellés de l'interface anglaise) : « LCP request discovery » pour le chargement de l'image du haut, « Improve image delivery » pour le poids, « Layout shift culprits » pour les images sans dimensions.

2. Les balises dans le HTML. Cette commande remet le HTML renvoyé par le serveur sur une seule ligne, pour attraper aussi les balises écrites sur plusieurs lignes, puis affiche les quinze premières balises <img> :

curl -sL -A "Mozilla/5.0" https://www.exemple.fr/ma-page | tr -s '\n\t ' ' ' | grep -o '<img[^>]*>' | head -15

Repérez la balise de l'image du haut de page : avatars, logo et pictos de l'en-tête passent souvent avant elle. Sur un site bien réglé, elle porte loading="eager" ou aucun attribut loading, souvent fetchpriority="high", et les images plus bas loading="lazy". La casse de l'attribut peut varier, par exemple fetchPriority. Vérifiez au passage la présence d'un alt et des attributs width et height.

Deux lectures demandent de la prudence. Une image insérée par JavaScript n'apparaît pas dans cette sortie : l'inspection d'URL de la Search Console montre le HTML affiché, où elle doit figurer. Une image de fond CSS n'apparaît nulle part en balise <img>, et c'est justement le problème : Google ne l'indexe pas.

Un site protégé contre les robots peut aussi renvoyer une page de blocage à la place de la vôtre. La commande ne sort alors aucune image de la page : soit rien, soit les deux ou trois balises de la page de blocage (logo, pictogrammes en data:image). Cette commande affiche le code renvoyé à la même requête :

curl -sL -o /dev/null -w "%{http_code}\n" -A "Mozilla/5.0" https://www.exemple.fr/ma-page

Tout code autre que 200 signale que curl n'a pas reçu votre page : 403 ou 503 le plus souvent, 202 ou 405 pour les défis d'AWS WAF (amazon.fr a répondu 202 à curl en octobre 2026).

Un 200 n'écarte pas le blocage, car certaines pages de défi répondent 200. Comparez alors avec le code source de la page dans votre navigateur (Ctrl+U, ou Cmd+Option+U dans Chrome sur Mac) : s'il contient des balises <img> que curl ne voit pas, curl a été bloqué, et le navigateur, PageSpeed Insights ou l'inspection d'URL donnent la réponse.

3. Les en-têtes de l'image. Copiez l'URL d'une image et lancez :

curl -sIL -A "Mozilla/5.0" https://www.exemple.fr/images/canape-velours-vert-3-places.webp | grep -iE "^(HTTP|content-type|cache-control|set-cookie)"

Si l'URL redirige, la sortie montre chaque étape, puis la réponse finale, la seule qui compte. Si cette réponse finale n'est pas un 200, avec un content-type: text/html par exemple, curl a reçu une page de blocage ou d'erreur à la place de l'image : ses lignes ne disent rien du fichier.

La ligne content-type doit correspondre à l'extension (image/webp pour un .webp, image/jpeg pour un .jpg). La ligne cache-control donne la durée de cache : Lighthouse signale les durées trop courtes dans l'insight « Use efficient cache lifetimes » (libellé de l'interface anglaise).

Une ligne set-cookie envoyée par votre serveur sur une image n'apporte rien, et Cloudflare, par exemple, ne met pas en cache par défaut une réponse qui en porte une (offres Free, Pro et Business). Les cookies __cf_bm et _cfuvid relèvent d'un autre cas : Cloudflare les pose lui-même, indépendamment de votre application, le premier pour ses outils anti-robots, le second pour ses règles de limitation de débit.

Le vieux conseil de servir les images depuis un domaine sans cookies va contre la recommandation actuelle de web.dev : une connexion à un domaine tiers a un coût, et la meilleure option est de servir les images depuis la même origine que la page.

Sur un catalogue de plusieurs milliers de fiches, ces contrôles se passent sur un échantillon par gabarit (fiche, catégorie, article), puisque le gabarit décide des balises de toutes ses pages. Une agence SEO peut industrialiser cet audit sur tout le site.

Questions fréquentes

Sources

• Bonnes pratiques de SEO pour Google Images (Google Search Central, mise à jour du 03/03/2026)
• Corriger le contenu au chargement différé (Google Search Central)
• Functional Images (W3C WAI)
• Decorative Images (W3C WAI)
• Bonnes pratiques concernant la structure des URL (Google Search Central)
• title, HTML global attribute (MDN)
• Improve image delivery (Chrome for Developers) : developer.chrome.com/docs/performance/insights/image-delivery
• Layout shift culprits (Chrome for Developers) : developer.chrome.com/docs/performance/insights/cls-culprit
• Browser-level image lazy loading for the web (web.dev)
• Image formats: WebP (web.dev)
• Optimize Largest Contentful Paint (web.dev)
• The performance effects of too much lazy loading (web.dev)
• LCP request discovery (Chrome for Developers) : developer.chrome.com/docs/performance/insights/lcp-discovery
• Sitemaps pour images (Google Search Central)
• Métadonnées d'image dans Google Images (Google Search Central)
• Balises meta robots, data-nosnippet et X-Robots-Tag (Google Search Central)
• Google Discover et votre site Web (Google Search Central)
• Empêcher les images de votre site d'apparaître dans les résultats de recherche (Google Search Central)
• Spécifications des données produit (aide Merchant Center), Aide Google Merchant CenterPlateforme Google pour gérer les flux produits et apparaître dans Google Shopping.
• Use efficient cache lifetimes (Chrome for Developers) : developer.chrome.com/docs/performance/insights/cache
• Default cache behavior (Cloudflare Docs) : developers.cloudflare.com/cache/concepts/default-cache-behavior/
• Cloudflare Cookies (Cloudflare Docs) : developers.cloudflare.com/fundamentals/reference/policies-compliances/cloudflare-cookies/
• New WebKit Features in Safari 14 (WebKit) : webkit.org/blog/11340/new-webkit-features-in-safari-14/
• WebKit Features in Safari 16.0 (WebKit) : webkit.org/blog/13152/webkit-features-in-safari-16-0/
• Lien image (image_link) (aide Merchant Center), Aide Google Merchant Center
• WebKit Features in Safari 16.4 (WebKit) : webkit.org/blog/13966/webkit-features-in-safari-16-4/
• CAPTCHA and Challenge in AWS WAF (AWS Docs) : docs.aws.amazon.com/waf/latest/developerguide/waf-captcha-and-challenge-actions.html