On publie un article, on y ajoute trois visuels non compressés avec des noms de fichier du type « IMG_4732.jpg », et on passe à autre chose. Deux mois plus tard, la page stagne en page trois. Le problème ne vient pas toujours du texte : les images mal préparées freinent le chargement, privent Google de contexte sémantique et font perdre un canal de trafic entier via Google Images.
Optimiser ses images pour le référencement naturel, c’est agir sur un levier que la majorité des rédacteurs web négligent encore.
A lire en complément : Comment remonter un référencement Google ?
Quand Google génère ses propres images : ce que change AI Overviews pour le SEO
Depuis 2024, Google intègre progressivement la génération d’images directement dans ses AI Overviews. Concrètement, pour certaines requêtes, Google produit lui-même un visuel au lieu de le récupérer sur le web. On observe ce comportement surtout sur des requêtes informationnelles génériques, où un schéma ou une illustration synthétique suffit à répondre.
Pour un site éditorial, la conséquence est directe : si vos images n’apportent rien de plus qu’un visuel décoratif, elles risquent d’être remplacées par une image générée. L’enjeu n’est plus seulement d’indexer une image, mais de la rendre irremplaçable par une IA.
A voir aussi : Quel est le facteur le plus important dans le référencement ?
En pratique, ça veut dire privilégier les visuels à valeur documentaire : captures d’écran annotées, photos de terrain, infographies avec des données propres au site. Un visuel générique de banque d’images n’a aucun avantage compétitif face à une image que Google peut fabriquer tout seul.
Balise alt et nom de fichier : au-delà des conseils de base
Renommer ses fichiers et remplir la balise alt, tout le monde connaît le principe. Ce qui manque souvent, c’est la méthode pour que ces éléments servent réellement le positionnement.
Nom de fichier : un signal d’indexation, pas un exercice de style
Google utilise le nom de fichier comme indice de contenu. Un fichier nommé « capture-erreur-404-search-console.jpg » donne un contexte immédiat. Un fichier « screenshot-final-v2.png » ne dit rien. On renomme avant l’upload, avec des mots-clés descriptifs séparés par des tirets.
Attribut alt : décrire pour les moteurs et pour l’accessibilité
L’attribut alt remplit deux fonctions simultanées : il décrit l’image aux lecteurs d’écran et fournit du texte exploitable par les robots d’indexation. Une bonne balise alt est une phrase courte qui décrit littéralement ce que montre l’image, en intégrant un mot-clé si c’est naturel.
- Mauvais : alt= »image » ou alt= » » sur une image porteuse de sens
- Correct : alt= »tableau comparatif des formats WebP et AVIF pour le web »
- Correct : alt= »capture d’écran du rapport Core Web Vitals dans PageSpeed Insights »
Un alt vide se justifie uniquement pour les images purement décoratives (séparateurs, arrière-plans). Toute image qui illustre le propos de l’article mérite une description.
Format WebP, AVIF et poids des images : impact concret sur le référencement
Le poids d’une image affecte directement le Largest Contentful Paint (LCP), l’un des trois Core Web Vitals que Google utilise comme signal de classement. Une image de plusieurs mégaoctets en JPEG non compressé peut à elle seule faire basculer une page dans la zone rouge.
Le format WebP offre un bon compromis entre qualité visuelle et poids réduit. Google le supporte depuis longtemps dans sa recherche d’images. Depuis 2024, Google accepte aussi le format AVIF, qui comprime encore davantage à qualité comparable. Pour un site éditorial qui publie plusieurs articles par semaine avec des visuels, passer au WebP ou à l’AVIF réduit sensiblement le temps de chargement.
Les retours varient selon les CMS et les configurations serveur, mais sur WordPress par exemple, des extensions comme ShortPixel ou Imagify convertissent automatiquement les uploads en WebP. Pour l’AVIF, le support côté navigateur est désormais large, même si quelques anciens navigateurs ne le gèrent pas.
Métadonnées structurées et signaux pour contrôler l’image affichée dans Google
Google ne choisit pas au hasard l’image qu’il affiche dans les résultats de recherche. Sa documentation récente met en avant deux signaux pour indiquer une image préférée : la propriété de données structurées primaryImageOfPage et la balise Open Graph og:image.
En pratique, on utilise primaryImageOfPage dans le balisage Schema.org de la page pour désigner explicitement l’image à la une. La balise og:image, initialement prévue pour les réseaux sociaux, est aussi lue par Google comme indication de l’image représentative.
Sans ces signaux, Google sélectionne l’image selon sa propre logique (taille, position dans le code, pertinence estimée). Résultat : il peut afficher un logo de sidebar ou une icône au lieu de votre visuel principal. Ajouter ces métadonnées prend quelques minutes et donne un contrôle réel sur l’aperçu de la page dans les résultats.
Sitemap d’images : utile pour les gros volumes
Pour un blog avec quelques articles par mois, un sitemap d’images n’est pas une priorité. En revanche, pour un site qui publie des dizaines de pages illustrées, un sitemap dédié aux images facilite leur découverte par Googlebot. On y référence chaque URL d’image avec son contexte de page. La plupart des extensions SEO pour WordPress génèrent ce sitemap automatiquement.
Lazy loading et images responsives : deux réglages qui pèsent sur les Core Web Vitals
Le lazy loading (chargement différé) retarde le téléchargement des images situées hors de l’écran visible. C’est un gain direct sur le temps de chargement initial. L’attribut HTML natif loading= »lazy » suffit dans la majorité des cas, sans script supplémentaire.
Un piège fréquent : appliquer le lazy loading à l’image de la une, celle qui apparaît en haut de page. L’image visible au premier écran ne doit jamais être en lazy loading, sinon elle retarde le LCP au lieu de l’améliorer.
Les images responsives (via l’attribut srcset) permettent au navigateur de charger une version adaptée à la taille de l’écran. Un visiteur sur mobile n’a pas besoin d’une image de 2400 pixels de large. Servir la bonne taille au bon appareil réduit le poids transféré sans toucher à la qualité perçue.
- Utiliser srcset avec plusieurs tailles (480w, 800w, 1200w minimum) pour couvrir mobile, tablette et desktop
- Définir l’attribut sizes pour indiquer au navigateur la largeur d’affichage prévue
- Tester le rendu via l’onglet réseau des outils développeur pour vérifier quelle version est effectivement chargée
L’optimisation des images pour le référencement naturel ne se limite plus à compresser et renommer. Avec l’arrivée de l’AVIF, les métadonnées comme primaryImageOfPage et la concurrence directe des images générées par Google dans AI Overviews, chaque visuel publié doit justifier sa place par sa valeur documentaire et sa configuration technique. Un article bien illustré et correctement balisé capte du trafic sur deux fronts : la recherche classique et Google Images.
